Skip to content

Protect

Soak up floods at the edge, before they reach your origin

ArxLayer absorbs and sheds volumetric and application-layer traffic at the edge, so spikes break against the protection layer instead of your servers. Rate controls, IP reputation, and self-hosted challenges shed the noise and let real users through.

TrafficProtectedArxLayerDDoSProtectionVolumetric floodL7 floodSYN floodReal trafficOriginBlockedAllowed

The problem

Floods don't need a vulnerability to take you down

When requests arrive faster than your origin can answer, the service goes dark even though nothing was breached. Volumetric and application-layer floods exhaust the same limited resources.

Volumetric floods saturate

A flood of connections and requests can exhaust bandwidth and sockets long before your application logic ever runs.

L7 floods look like real traffic

Application-layer floods mimic legitimate requests to expensive endpoints, so naive volume counts miss them.

Blunt blocking takes users with it

Reacting to a spike by blocking broadly often sheds real customers along with the attack. Precision is the hard part.

What you get

Layered shedding that keeps good traffic flowing

Mitigation happens at the edge, before traffic reaches your origin. Each layer narrows the flood while letting verified, well-behaved clients through.

Edge absorption

Floods hit the distributed edge first, keeping pressure off your origin so it stays reachable.

Rate and connection controls

Per-client and per-route limits cap abusive request volume without throttling normal usage.

Reputation-based shedding

Clients with a history of abuse are dropped or challenged at the edge, on hashed identifiers, not raw IPs.

Proof-of-work challenges

Self-hosted JavaScript challenges raise the cost for automated floods and bar clients that don't execute the page.

Verified crawlers pass

Confirmed crawlers are verified by reverse-DNS and forward-confirm, so legitimate bots aren't caught in mitigation.

Tunable, reversible policy

Adjust thresholds per surface as a versioned policy you can review and roll back in seconds.

How it works

From spike to shed in three moves

Traffic is filtered in stages at the edge so the cheapest, most certain drops happen first.

Route through the edge

Point your domain at ArxLayer Edge so every request is screened at the edge before it can reach your origin.

Shed by reputation and rate

Known-bad and over-limit clients are dropped or slowed first, cutting the bulk of a flood with high confidence.

Challenge the uncertain

Remaining suspect clients get a proof-of-work challenge, so automated floods pay a cost while real browsers pass.

FAQ

Questions, answered

Does ArxLayer stop every DDoS attack?
No tool can promise that. ArxLayer absorbs and sheds traffic at the edge with rate, reputation, and challenge controls to keep your origin reachable, but it makes no absolute guarantee.
Does it protect against application-layer (L7) floods?
Yes. Per-route rate limits, reputation shedding, and proof-of-work challenges target application-layer floods that imitate real requests, not just raw volume.
How do you avoid blocking real users during an attack?
Mitigation is layered and tunable: high-confidence drops first, then proof-of-work challenges that real browsers solve. Verified crawlers are confirmed by reverse-DNS and forward-confirm.
Are my visitors' IP addresses stored?
Raw client IPs never leave the edge. Reputation uses hashed (HMAC) identifiers, and the edge request path stays local and in-memory.

Keep your origin standing when the flood comes

Route your traffic through ArxLayer Edge and shed volumetric and application-layer floods before they reach your servers.