Anatomy of a DDoS Attack, and What Mitigation Really Does

Every WordPress site owner hears the term DDoS eventually, usually right after a site goes down for no obvious reason. The mechanics are not mysterious once you break them apart, and understanding them makes it much easier to judge whether your hosting setup is actually protecting you or just adding a badge on a dashboard.

What a DDoS Attack Actually Is

A distributed denial-of-service attack is an attempt to make a site or server unavailable by overwhelming it with traffic or requests from many sources at once. The “distributed” part matters: instead of one machine hammering your server (which is easy to block), the traffic comes from thousands of devices, often compromised machines or rented botnets, spread across many networks and countries. Blocking a single IP does nothing when the next request comes from a different one a moment later.

The goal is rarely to “hack” the site in the sense of stealing data. It is to exhaust some resource, bandwidth, CPU, database connections, or application logic, until legitimate visitors cannot get through.

Volumetric vs Application-Layer Floods

Not all floods work the same way, and the difference matters for how you defend against them.

Volumetric attacks

These aim to saturate raw bandwidth or network capacity. Think of it as flooding the pipe with more traffic than it can carry, regardless of what that traffic actually asks for. A small origin server has no chance against this on its own; it simply does not have the bandwidth or network infrastructure to absorb a flood measured in gigabits per second. This is a network-layer problem and it needs a network-layer answer.

Application-layer attacks

These are subtler and often more damaging to a WordPress site specifically. Instead of brute-force volume, the attacker sends requests that look legitimate but are expensive to process: repeated hits to wp-login.php, search queries that force uncached database lookups, or requests to endpoints like xmlrpc.php that can be abused for pingback floods. A modest number of these requests per second can pin your PHP workers and database connections at 100 percent, which crashes the site just as effectively as a bandwidth flood, using a fraction of the traffic.

This is why “we got DDoSed” can mean wildly different things. A volumetric attack needs scrubbing capacity upstream. An application-layer attack often needs smarter filtering closer to the application, caching, and rate limiting.

What Edge Scrubbing Really Does

This is where a service like Cloudflare sitting in front of your site earns its keep. When Cloudflare is properly configured as a reverse proxy, all traffic to your domain routes through its network first. That gives it several distinct advantages:

• Massive absorption capacity. Cloudflare’s network is built to absorb volumetric floods far larger than any single origin server could handle, spreading and filtering the load across its global edge before it ever reaches you.
• A web application firewall (WAF). Malicious or malformed requests, including many of the patterns used in application-layer attacks, can be identified and dropped at the edge based on rule sets, not left for your PHP process to chew through.
• Bot mitigation. Automated request patterns that do not behave like a human browser can be challenged or blocked before they reach WordPress.
• Edge caching. Static and cacheable content gets served directly from Cloudflare’s edge nodes, so a flood of requests for your homepage never has to touch your origin server or database at all.
• Universal SSL and HTTP/3. Beyond attack mitigation, this setup terminates TLS at the edge and speeds up connection handling for legitimate visitors, which is a nice side benefit rather than the main point here.

In short, scrubbing means the fight happens at the edge, on infrastructure sized for exactly this problem, instead of on your single origin server that was sized for normal traffic.

The Origin Exposure Problem

Here is the part that undoes all of the above if it is overlooked: none of this scrubbing matters if an attacker can find your origin server’s real IP address and hit it directly.

If your DNS history, an old server response header, a misconfigured subdomain, or a leaked email header ever exposed your origin IP, an attacker does not need to go through Cloudflare at all. They can send traffic straight to your server, bypassing the WAF, the bot mitigation, and the edge caching entirely. A firewall in front of a door does nothing if there is an unlocked window around the side of the house.

Keeping the origin IP unpublished is therefore not a minor detail, it is a core part of DDoS resilience. Practical steps that matter here:

• Make sure every DNS record for the domain, including subdomains, is proxied through Cloudflare (orange-clouded), not set to DNS-only (grey-clouded), unless there is a specific reason it needs to bypass the proxy.
• Configure your origin server’s firewall to only accept web traffic from Cloudflare’s published IP ranges, rejecting direct connections from anywhere else.
• Avoid ever exposing the origin IP in outgoing mail headers, staging subdomains, or old A records left over from before the site moved behind the proxy.
• Rotate the origin IP if you have reason to believe it was previously exposed, since old scans and cached DNS records can linger for a long time.

What You Can Do on Your Own Site

Edge protection handles the network and firewall layer, but application-layer resilience still benefits from a healthy WordPress stack underneath it.

• Run a supported PHP version (8.1 through 8.3, with 8.3 and OPcache being a solid default) so requests that do reach your server are processed as efficiently as possible.
• Use full-page caching, such as LiteSpeed Cache on a LiteSpeed or OpenLiteSpeed server, so repeated requests for the same page never touch PHP or the database.
• Add persistent object caching with Redis or Memcached so dynamic queries that can’t be full-page cached still avoid repeated expensive database lookups.
• Disable or restrict xmlrpc.php if you do not use it, since it has historically been a favorite target for both brute-force login attempts and pingback-based floods.
• Use wp-cli to audit and manage plugins and users quickly during an incident, for example wp plugin list to check what’s active or wp user list --role=administrator to confirm no unexpected accounts have appeared.

A managed host that keeps this stack tuned (up to date PHP, server-level caching, object caching, and origin-IP hygiene handled by default) removes a lot of the guesswork here, which is one thing ServerBorn takes care of as part of the underlying platform.

The Takeaway

A DDoS attack is really two different problems wearing the same name: raw volume that needs network-scale absorption, and clever application requests that need smart filtering and an efficient stack. Edge scrubbing through a service like Cloudflare addresses both, but only if the origin server stays hidden behind it. Get the DNS and firewall configuration right, keep your WordPress stack lean and cached, and the anatomy of an attack stays mostly academic instead of an outage you have to explain.