DDoS Attack

DDoS is an attempt to make a service unavailable by flooding the network, server, or application from many sources. The goal is not to steal data, but to exhaust bandwidth, connections, CPU, or request quotas until legitimate users cannot get in.

Three layers of attack

Volumetric attacks flood bandwidth with UDP floods or DNS amplification. Protocol attacks exhaust connection tables with SYN floods or fragmented packets. Application attacks send HTTP requests that look normal, but in numbers large enough to exhaust PHP workers or database connections.

On shared hosting, the usual symptoms are Error 503, Error 508, or slow pages while traffic looks normal. Application attacks are the hardest to recognize because the requests resemble ordinary visitors.

What to record

Before contacting the provider, record the start time, URL patterns, and source IPs. Check ss -s for a large number of SYN-RECV or TIME-WAIT connections. Look at the access log too: if one user agent or IP range requests thousands of pages in a minute, that is an early clue.

Do not jump to a DDoS conclusion from a traffic spike. Crawlers, bot campaigns, or a cache misconfiguration can produce a similar pattern. Clean data speeds up escalation and prevents the wrong response.

Layered mitigation

A CDN and anycast spread traffic across locations, so attack capacity does not pile up on one server. A WAF and rate limits filter malicious request patterns. In Nginx, limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s; can protect a frequently attacked endpoint, followed by limit_req zone=api burst=20 nodelay;.

Autoscaling helps with short spikes but gets expensive during a long attack. The provider can also scrub traffic or null-route the IP. Null routing saves the network but takes the service offline, so it is an emergency option only.

A resilient application still matters. Cache pages, limit database connections, and move heavy work to a queue. If every request opens a new database connection, even a small attack can exhaust the connection slots.

Common mistakes

Upgrading the hosting plan without analysis often does not help because the bottleneck is a query or a worker. Blocking an entire country risks hitting legitimate users. Captcha helps login and forms, but it does not stop a flood of requests to public pages.

For attacks disguised as normal traffic, combine a WAF, Cloudflare, and a load balancer. If the root cause is database connections, see Connection Pooling.

FAQ