Two kinds of flood
"Layer" comes from the OSI model, the textbook way of splitting a network connection into levels. For DDoS attacks two families matter.
| Network floods (Layers 3 and 4) | Application floods (Layer 7) | |
|---|---|---|
| What arrives | Packets: UDP, SYN, amplified replies | Complete HTTP requests over real connections |
| Measured in | Bits or packets a second | Requests a second |
| What it exhausts | The network link and routers | The web server, the application and its database |
| Looks like | Traffic no browser ever sends | Visitors loading a page |
| Stopped by | Network filtering upstream | Something that reads each request |
A network flood tries to fill the pipe. A Layer 7 flood does not need to: it sends requests a website has to answer, and lets the website's own work do the damage.
Every request makes your server work
Answering a request is cheap for a static file and expensive for almost everything else. A login page checks a password hash and queries a database. A search runs a query. A shop page builds a cart. That is why a few thousand requests a second can take down a website that a network flood of the same size would never notice.
The floods are not small either. On 20 October 2026 our edge measured 1,015,237 requests in a single second, and on 23 October the same tool sent 96.8 million requests to one login page in 12 minutes. Both came over HTTPS and HTTP/2, from roughly a million addresses each.
Network filters cannot read HTTPS
Most hosting providers' DDoS protection works at the network level. It is good at what it was built for: dropping packets that no real connection would send. A Layer 7 flood sends nothing of the kind. Its connections are complete, its TLS handshakes are valid, and its requests are encrypted inside them. A filter that does not end the TLS connection itself cannot see which page is asked for, by what, or how often.
So the flood reaches your server looking like traffic, and your server does the rest.
Five fixes that do not hold
Limits per IP address
A flood from a million addresses needs very little from each. On 20 October each address sent about two requests a second in the busiest minute. A limit that low also stops real visitors who share an address.
Blocking countries or networks
Both floods we measured came from more than 50 countries and from the largest home internet providers. Blocking them blocks your customers long before it slows the flood.
A bigger server
An attacker's extra requests cost the attacker almost nothing. Your extra capacity costs you every month, and the next flood is bigger.
Caching everything
A cache helps with pages that are the same for everyone. Attackers aim at what cannot be cached: logins, searches, carts, and URLs with random parameters that miss the cache on purpose.
A challenge for every visitor
Making everyone solve a puzzle during an attack also stops your apps, your API clients and part of your visitors, for as long as the attack lasts.
Read every request, judge every client
What stops a Layer 7 flood is something in front of your website that ends the HTTPS connection, reads each request, and judges each client on its own: how its connection behaves, what it asks for, and whether it acts like the browser it claims to be. Clients that show the evidence of a flood are stopped. Clients that do not, including new ones and ones on the same network as an attacking device, get in.
Two things make that protection hold:
- Lock down your server. The protection only covers traffic that goes through it. If attackers know your server's own address, they go around it. See how origin addresses leak.
- Set it up before you are attacked. It can be switched on in the middle of a flood, but every minute counts. If it is already happening, see the first 15 minutes.
This is what Shieldify does for every website it protects: Layer 7 DDoS protection that decides per request and per client, in front of your server.