What Is a DDoS Attack — How It Works and How to Survive One

The three types, and why the difference matters

Knowing which type you are facing decides everything else — where the defence has to sit, and whether anything you do on the server can help at all.

How to tell a DDoS from an ordinary traffic spike

This matters more than it sounds. Being featured somewhere popular and being attacked produce the same symptom — a site that stops responding — but the correct reaction is completely different.

• Look at the request distribution. Real traffic spreads across many pages and arrives with varied referrers; an attack usually hammers one or two URLs with an unnaturally flat pattern.
• Look at the user agents. Genuine visitors bring a wide mix of browsers and versions. Long runs of an identical string, or of obviously fake ones, point at automation.
• Look at geography against your audience. A Thai-language site suddenly taking most of its traffic from unrelated regions is a strong signal, especially when it appears within a single minute.
• Look at the shape over time. Organic spikes ramp up over minutes and decay slowly. Attacks tend to start at full volume instantly and stop just as abruptly.
• Check whether the requests convert to anything. Real visitors load images, CSS and fonts. Attack traffic often requests only the HTML, which shows up clearly in the access log.
• Check bandwidth against request count. Very high bandwidth with modest request counts means volumetric; very high request counts with modest bandwidth means application layer.

What to do while it is happening

• Confirm the type first using the checks above. Everything else depends on it, and thirty seconds of reading logs saves an hour of the wrong work.
• If your site sits behind a CDN or proxy, make sure the origin IP is not reachable directly. Attackers who find the real IP bypass the protection entirely, and this is the single most common way protection fails.
• Turn on the strictest mode your provider offers. Cloudflare's "Under Attack" mode and equivalents challenge every visitor; it hurts legitimate experience, but a slow site beats an unreachable one.
• Rate-limit at the edge rather than on the server. A request blocked before it reaches your machine costs you nothing; one blocked by PHP has already consumed a worker.
• Cache aggressively, even temporarily. Serving static HTML to everyone removes the database from the attack surface, and many application-layer attacks stop working the moment their expensive target is cached.
• Block the obvious patterns, but do not chase individual IPs. In a distributed attack, banning addresses one by one is a race you lose — block by pattern, ASN or country instead.
• Tell your host. On shared hosting they may already be involved, and on a VPS they can often null-route or filter upstream, which is the only place volumetric traffic can be stopped.

What protection actually does, and what it does not

DDoS protection is mostly about where the traffic is filtered, not about how clever the filter is.

A CDN or scrubbing provider works because it has far more capacity than your server and sits between the attack and you. Volumetric traffic hits their network, gets absorbed, and never reaches your cable. This is the only defence that works against volumetric attacks, and no amount of server configuration substitutes for it.

A WAF works differently: it inspects requests and drops the ones matching attack patterns. That is what helps against application-layer attacks, where every individual request looks legitimate and the problem is their number and their target.

Server-side hardening — connection limits, SYN cookies, fail2ban, sensible timeouts — is real and worth doing, but it only helps in the middle band. It will not save a saturated network link.

The most under-rated defence is simply caching. A site that serves most requests from static files has an enormous capacity advantage, and a very large share of small-scale attacks simply fail against it without anyone noticing.

Preparing before it happens

• Keep your origin IP private if you use a CDN. Old DNS records, mail server records and direct-IP links are the usual leaks, and they undo the entire protection.
• Enable page caching now, not during an incident. It is the cheapest capacity increase available and it works whether or not you are ever attacked.
• Set up uptime monitoring with alerting. Finding out from a customer costs you the first and most valuable half hour.
• Know where your logs are and how to read them quickly. During an attack, the access log is the only source of truth about what is actually happening.
• Have your host's emergency contact somewhere other than the affected site. Support details stored only in a panel you cannot reach are of no use.
• Keep the software patched. Amplification attacks often abuse misconfigured services — DNS resolvers, NTP, memcached — and an unpatched server can end up being used against others.