Hardening Reference
DDoS attack — Why a DDoS is a capacity problem, not a rules problem
The site is down, the server looks healthy, and every graph you own is flat except one.
The short answer
A DDoS exhausts a finite resource rather than exploiting a flaw — bandwidth, connection slots, PHP workers, database connections — by consuming it from thousands of sources at once until nothing is left for real visitors.
The name covers two very different attacks. A network flood tries to fill your pipe with packets. An application flood sends requests that look almost legitimate and are expensive to serve. A small site is far more likely to be knocked over by the second, and the two need entirely different answers.
By the HostingFast team · Reviewed 24 August 2026
0
Hand-waving in this entry
100+
Entries wired to each other
Real
Numbers you can reproduce
Free
To read, no gate
The network kind is a volume contest and it is settled upstream. Filtering capacity larger than the flood absorbs it, scrubs it and passes the genuine traffic through. Nothing you configure on the machine helps, because the pipe into the machine is already the bottleneck.
The application kind is more interesting and more common. A few hundred requests per second aimed at a search URL, a WooCommerce filter or wp-login.php will not fill anyone's pipe, but every one of them misses the cache, wakes PHP and reaches the database. Your worker pool runs out long before your bandwidth does.
What runs out first on a PHP site
Workers. Cached pages come off LiteSpeed at static-file speed, so a flood only hurts when it lands on something uncacheable — a query string that defeats the cache, a filtered category, an admin endpoint, a POST. Those requests all queue for the same small pool of PHP processes, and once the pool is saturated, ordinary visitors join the same queue.
That is why the symptom is so confusing. Disk is fine, CPU may look moderate, bandwidth is unremarkable, and the site still times out. You are not out of capacity in general; you are out of the one specific thing every dynamic request needs.
Telling an attack from a good day
Read the access log rather than the dashboard. Count requests per minute by URL, then by user agent, then by network. A real traffic spike spreads across many URLs and arrives with a plausible referrer mix. A flood concentrates: one path, one or two agents, thousands of sources, no referrers, and an arrival rate that is suspiciously constant.
Watch the cache header too. If the flood is hitting URLs that return a cache miss, you have found both the attack and the fix, and the fix is often as simple as making that URL cacheable or refusing the parameter that defeats the cache.
Why blocking addresses is arithmetic you lose
A list-based defence needs you to be faster than a botnet at adding entries. You will not be. Sources rotate through tens of thousands of hijacked devices, and by the time you have banned a page of them you have spent the outage at a keyboard achieving very little.
What does work is a rule that matches shape rather than origin: rate limits per address, a challenge on the expensive path, or simply caching the response so the request stops being expensive. Filtering at the network edge is included on plans here, which turns most of this into a spike on a graph rather than a phone call.
What to have ready before it happens
Know your normal. Requests per minute, cache hit ratio and uncached response time on an ordinary Tuesday are three numbers that take ten minutes to collect and make the difference between a diagnosis and a guess when something goes wrong.
Neighbouring entries: Firewall, CDN, Cache and Uptime. Backups run daily on every plan and restore from the panel in a click, which matters here because a flood that lands during a deploy is a bad combination to be improvising through.
The reference we wanted during the incident
Every entry is written for the moment you are actually reading it: something is wrong, you have a terminal open, and you need the mechanism and the number rather than a definition.
Filtering at the network edge, NVMe storage and LiteSpeed caching are standard on every tier, so the baseline is the same whichever plan you start on.
- Written for the incident, not the exam
- Numbers to collect before you need them
- Terms linked in the order you hit them
- Maintained by the people on call
Why HostingFast
Standard on every plan
Two attacks, told apart
Packet flood and request flood share a name and share almost nothing else, including the fix.
The resource that runs out
On a PHP site it is workers, not bandwidth, which is why the server looks healthy while the site is down.
Log-first diagnosis
Requests per minute by URL, agent and network separates a flood from a good day in about a minute.
Why IP blocking fails
Arithmetic, not opinion: rotating sources outpace any list you can maintain by hand.
Baselines worth having
Three numbers collected on a quiet day turn a future outage into a comparison.
Where the platform helps
Edge filtering is standard here, so the common case never reaches your worker pool.
Quick Start
From order to online
- 1
Check what is missing the cache
Look at the cache header on the URLs taking the traffic. A flood on cacheable pages is nearly harmless; a flood on cache misses is the one eating your workers.
- 2
Count by URL, agent and network
Three passes over the access log tell you whether this is an attack or an unusually good day, and which path to protect first.
- 3
Change shape, not source
Rate limit the expensive path or make it cacheable. Banning addresses one at a time is a way of being busy during an outage.
Built In
Loaded onto every plan
- DDoS filtering absorbed out at the network edge
- Spam and virus screening on every mailbox as standard
- LiteSpeed caching built into the server rather than patched in by plugin
- Human support on duty every hour of every day
- In-place account upgrades — no migration when you change plan
- WordPress and 400+ other applications installed in one click
- Softaculous on board for one-click application installs
- Browser webmail plus IMAP, POP and SMTP for any mail app
- A renewal price identical to the price you signed up at
- Zero setup charges — there is no joining fee, ever
Frequently Asked
What people ask us most often
How do I tell a flood from a genuine traffic spike?
Spread and shape. Real traffic touches many URLs, carries a mixed referrer profile and rises and falls unevenly. A flood concentrates on one or two paths, arrives at an eerily constant rate, and usually shows a thin user-agent spread across a very wide address range. Count requests per minute by URL first — that one pass answers it most of the time.
Can caching absorb an application-layer flood?
Often, yes, and that is the cheapest defence available. A request that returns from cache costs a fraction of one that wakes PHP, so making the targeted path cacheable can end the incident outright. The attacks that survive it are the ones aimed at endpoints that cannot be cached — login, checkout, search with arbitrary parameters — and those need rate limiting instead.
Is DDoS filtering part of the plan or sold separately?
It is absorbed at the network edge on every plan here, not an add-on and not a tier. What that covers is the volumetric case, which is the one you have no way to answer from inside your own account. Application-layer floods are a joint effort: we filter, you make the expensive path cheaper.
What happens to legitimate visitors while filtering is engaged?
Usually nothing they would notice beyond slightly slower first loads while traffic is being scrubbed. Aggressive mitigation can add a challenge step for a small share of visitors on unusual networks. If a site is genuinely down, our support target is a first reply inside an hour.
Keep reading
CDN (Content Delivery Network)
Edge delivery, the round-trip figures by region, and what never gets cached out there.
Uptime
The reachability figure, what a 99.9% target actually permits, and how it is monitored.
Best Hosting With DDoS Protection
The buyer's version: what to verify about filtering capacity and what to ignore.
CMS Hosting
Hardened, quick hosting for WordPress, Joomla, Drupal and the rest of the major platforms.
VPS Hosting
KVM virtual servers with root access, edge filtering and one flat monthly price.
Changing hosts? Run through our checklist first.
A straightforward sequence for a switch your visitors never feel: which files move first, how to shift email across without losing a single message, the right moment to repoint DNS, and the two mistakes behind almost all the downtime we get asked to rescue.
Keep the workers free for real visitors.
Free SSL, free migration, renewals at the original rate, and edge filtering included on every tier.
View CMS Hosting plans