A DDoS attack tries to make a server or its network link unusable by sending requests from many sources at once. Attacks are not all the same; the layer they target decides what stops them.
Layer 3 and 4: filling the pipe
These attacks aim to fill the server's network link or connection table (UDP flood, SYN flood). The goal is not to reach the application but to stop traffic from arriving at all. This layer must be filtered upstream on the network; nothing inside the server can unclog a saturated link.
Layer 7: exhausting the application
A Layer 7 attack sends real HTTP requests. The volume can be low, but every request runs a database query, a search or a page render. Resources run out and the site starts returning 502/504. At this layer the question is whether a request comes from a real visitor or a bot.
How do you know you are under attack?
- The site slows down or returns 502/503/504 while CPU usage suddenly spikes.
- One specific URL (a search page, for example) receives far more requests than usual.
- Many different IPs send requests with missing or identical browser details.
- On a game server, players see ping spikes or drop at the same time.
Which protection stops what?
| Measure | Attack it stops |
|---|---|
| Network-level filtering (RouteFence®) | Layer 3 / 4 volumetric attacks |
| Rate limiting | Heavy request floods from a single IP |
| Browser verification | Simple botnets and script-based L7 attacks |
| WAF rules | Targeted requests such as SQL injection, XSS, vulnerability scans |
| Caching | The cost of attacks that request the same page repeatedly |
What Light Hosting provides
On our services, Layer 3, 4 and 7 attacks are filtered before they reach your server. The RouteFence® infrastructure runs with 8 global POP locations and 6+ Tbps of filtering capacity, and protection is Always-On, so nothing needs to be switched on when an attack starts. Automatic port learning also covers the ports used by game servers. DDoS protection is included free with our VDS, Ryzen VDS and dedicated server plans.
What to do during an attack
- Do not reboot in panic. Restarting does not stop an attack; it only extends the outage.
- Confirm it really is an attack. Are many IPs hitting the same URL with abnormal volume, or is this a real traffic spike after a campaign?
- Find the targeted URL. The most requested path in the access log is usually the target; search and filter pages are common ones.
- Raise the protection level. A mode where new visitors pass a browser check removes most bots.
- Open a support ticket. Telling us the size and target of the attack speeds up filtering on our side.
Which logs to read
- Access log: IP, requested URL and user agent. The same user agent arriving from hundreds of IPs is a bot signature.
- Error log: 502/504 errors mean resources are exhausted.
- Server resources: CPU at the ceiling with normal traffic means an application-level attack.
After the attack
Return the protection level to normal; leaving verification higher than needed hurts real visitors and conversions. Review the page that was targeted: if it is a heavy search page, add caching and reduce unnecessary database queries. The next attack will aim at the same page.
What you can do on your side
Close unused ports, restrict management access (SSH/RDP), cache the heavy pages of your application and index your database queries. During an attack, unoptimised dynamic pages are what suffer first.