Anti-DDoS L3/L4 – L7
Multi-layer DDoS protection
DDoS is not one kind of attack. A flood that fills the pipe and a request stream indistinguishable from real users are detected differently and stopped differently. Both are here.
Multi-layer DDoS protection
DDoS is not one kind of attack. A flood that fills the pipe and a request stream indistinguishable from real users are detected differently and stopped differently. Both are here.
Most defences rest on a single number: above so many requests per second, block. That is wrong in both directions. On a sale day real traffic crosses the threshold and your customers get blocked; a slow, careful attack never reaches it at all and walks straight through.
Because a threshold knows nothing about your site. A system that does not know what normal traffic looks like sees only volume — never intent.
So two things work together here: thresholds are computed from your own site's normal, and the decision is made on behaviour rather than volume.
| Layer | What the attack looks like | What stops it |
|---|---|---|
| L3 — network | Packet flood, amplification (DNS, NTP) — filling the pipe | Packet-level filtering, dropping by source, ASN and geography limits |
| L4 — transport | SYN flood, exhausting the connection table with open sessions | Connection limits, clearing half-open sessions, kernel-level drop |
| L7 — application | A stream that looks like real requests, a hit on an expensive endpoint, deliberately slow requests | Four-layer rate limits, session behaviour analysis, browser check |
Blocking an L7 attack at the application layer costs resources too: every rejected request is still accepted, read and answered. At enough volume the server falls over from exactly that work.
So the identified source never climbs higher — the packet does not reach the application layer at all. During volumetric attacks that is where the difference shows.
The response does not start with a full block. Each stage is stricter than the last, and each touches a real user as little as it can.
| Stage | What is done | Does a real user notice |
|---|---|---|
| Detection | Traffic departs from the norm; the layer and the source are identified | No |
| Throttling | Request rate is limited for suspicious sources | Barely |
| Challenge | A browser check is sent to suspicious sessions | A few hundred milliseconds |
| Kernel-level drop | A confirmed attack source is dropped at the packet level | No |
| Return | Thresholds return to normal once the attack is over | No |
Through DNS: your domain's traffic is routed through the platform. Nothing is installed on your server. Connection usually takes a few hours, not counting DNS propagation.
Thresholds are computed from your own traffic norm, so a sale or a news spike is not read as an attack by itself. Where it is unsure, the first response is not a block but throttling or a browser check.
Traffic does not leave Uzbekistan, so a request does not travel to a foreign node and back. The browser check is applied only to suspicious sessions.
Usually nothing — the response is automatic. If you want to switch Under Attack mode on by hand or tighten thresholds temporarily, that is done from the panel.
An L3/L4 flood is dropped at the kernel and never reaches the application. Volume beyond the capacity of the link is handled at the carrier level — in those cases the coverage is agreed separately in the contract.
Connect your domain and we will show you its current traffic norm and the attempts aimed at it. Nothing is blocked at this stage.

