Ops Brief
Hosting with DDoS protection — Two different attacks, two different defences, one log file
The site is unreachable, the resource meter is pinned, and before you can do anything useful you need to know whether this is a flood, a crawler or your own cron job.
The short answer
Buy infrastructure where filtering is permanent rather than activated on request: our VPS range carries 1 Tbps+ DDoS filtering in front of every machine on a 20 Gbps uplink per hypervisor, and edge filtering sits in front of the shared platform too.
But start by identifying what you are actually looking at. A volumetric attack saturates the network and is absorbed upstream before it reaches you. An application-layer flood is a modest number of requests aimed at your most expensive URL — search, filtered category pages, anything uncacheable — and it will take a site down with traffic your bandwidth graph barely registers.
Below: how to tell them apart from your own access log in about two minutes, what the filtering absorbs, and the one application-layer change that does more than any of it.
By the HostingFast team · Reviewed 24 August 2026
99.9%
Uptime target
24/7
Humans on the desk
Free
SSL, every plan
NVMe
Storage as standard
Attack traffic is a commodity purchase now, so entirely unremarkable sites get targeted. That is a genuine reason to have filtering in place before you need it rather than as an emergency purchase mid-incident.
It is also a reason to be precise about diagnosis, because the majority of 'we were DDoSed' incidents turn out to be a badly configured crawler, a scraper, or an uncached URL that a modest amount of traffic can overwhelm. The response differs completely.
Two minutes with the access log
Get the top source addresses: `awk '{print $1}' access.log | sort | uniq -c | sort -rn | head -20`. A handful of addresses producing enormous counts is usually a scraper or a single abusive client. Thousands of addresses each producing a few requests looks more like a distributed flood.
Then look at what they are asking for: `awk '{print $7}' access.log | sort | uniq -c | sort -rn | head -20`. If the top URLs are your search endpoint or a faceted category page with query strings, you are looking at an application-layer problem, because those cannot be served from cache.
Then the user agent: `awk -F'\"' '{print $6}' access.log | sort | uniq -c | sort -rn | head`. An identifiable crawler hitting you too hard is a robots.txt and rate-limit conversation, not an attack.
The cPanel resource meter completes the picture by telling you whether CPU, memory or entry processes hit the ceiling. That is the difference between 'the network was saturated' and 'PHP ran out of workers', which point at completely different remedies.
What the filtering absorbs
Volumetric traffic is scrubbed upstream, so a flood is absorbed by infrastructure rather than arriving at your server to be dealt with. On the VPS range that is 1 Tbps+ of filtering capacity, with a 20 Gbps uplink on every hypervisor behind it.
During mitigation, legitimate requests continue through. Very large events can add latency, and staying reachable throughout is the design goal rather than pretending nothing is happening. You will usually see the event in traffic graphs rather than in downtime.
Shared accounts sit behind edge filtering as well, so the same class of traffic never reaches the machine your site is on. What no network layer can do is tell the difference between a legitimate search request and a malicious one — that judgement has to happen at the application.
The application-layer change that does the most
Cache aggressively, because a cached response is orders of magnitude cheaper to serve than an uncached one. LiteSpeed is compiled into the web server, so a cached page is answered without waking PHP, MySQL or your plugin stack at all.
That reframes the whole problem. A flood aimed at cacheable URLs is absorbed by the cache. A flood aimed at uncacheable ones — search, filtered listings, login — is the real threat, which is why the specific mitigations are rate-limiting the search endpoint, blocking query-string variations you never intended to serve, and requiring a session before an expensive operation.
Check what proportion of your traffic is currently cacheable before an incident rather than during one: `curl -sI` and read the LiteSpeed cache header on your busiest URLs. A site where the top ten URLs all miss the cache is fragile regardless of what filtering sits in front of it.
What to buy, and when
For a site on shared hosting, edge filtering plus a well-configured cache handles the realistic threat and costs nothing extra. Most sites never need more than that.
For a workload that genuinely draws attention — a busy forum, a contested niche, an application with an exposed API — the answer is the Surge VPS plan, where filtering sits in front of a machine whose resources are yours alone and where you can implement rate limiting exactly as your application needs it.
VPS pricing runs from $13.52 a month for 1 core and 1 GB up to $270.57 for 10 cores and 32 GB, all on KVM with full root, a choice of 24 Linux and BSD images, and a London or Dallas location. Note that VPS and dedicated servers carry no refund window, because the capacity is allocated to you specifically — worth knowing before you order rather than after.

Why the diagnosis section comes first
Selling mitigation to someone whose actual problem is an uncached search page would be easy and would not fix anything. The log commands above cost us nothing and settle the question in two minutes.
We are recommending our own infrastructure and say so plainly. The diagnostic method works on any host, and our desk is staffed at every hour if you would rather read the log with someone.
- 1 Tbps+ filtering, 20 Gbps uplink per hypervisor
- Edge filtering on the shared platform too
- Log commands that separate a flood from a crawler
- Cache coverage checked before an incident, not during
Why HostingFast
Standard on every plan
The Surge VPS plan, filtered up front
1 Tbps+ of DDoS filtering ahead of every machine, on a 20 Gbps uplink per hypervisor, included rather than sold mid-incident.
Edge filtering on shared too
Volumetric traffic is absorbed before it reaches the machine your site is on, on every plan rather than as a premium tier.
A cache that absorbs the rest
LiteSpeed answers cached requests without waking PHP or MySQL, which is what makes a spike survivable at all.
Logs you can actually read
Full SSH and access logs on the account, so diagnosis takes two minutes rather than a support round trip.
Full root when you need your own rules
KVM VPS from $13.52 with 24 Linux and BSD images and a London or Dallas location, for application-layer rate limiting you control.
Humans during the incident
Support at every hour with a one-hour first-reply target when a site is down, which is exactly when this matters.
Quick Start
From order to online
- 1
Rank the source addresses
One awk over the access log. A few addresses with huge counts is a scraper; thousands with small counts is distributed.
- 2
Rank the requested URLs
If your search endpoint or a faceted listing is at the top, this is an application-layer problem and no network filter fixes it.
- 3
Check the resource meter
Network saturation and exhausted PHP workers look identical from outside and need entirely different responses.
- 4
Measure cache coverage while nothing is wrong
`curl -sI` on your busiest URLs. A site whose top ten all miss the cache is fragile no matter what sits in front of it.
Built In
Loaded onto every plan
- Mailboxes on your own domain, included in the plan
- Full SSH with access to your own logs for diagnosis
- Webmail plus IMAP, POP and SMTP for any mail client
- In-place upgrades between tiers, with no migration to arrange
- WordPress Toolkit, with updates handled for you
- NVMe drives on the entry tier as well as the expensive ones
- Daily backups with self-service restores from the panel
- WebP image conversion built in at no extra cost
- DDoS filtering upstream, so a flood is infrastructure's problem
- 1 Tbps+ filtering and a 20 Gbps uplink on the VPS range
- Softaculous: WordPress and 240+ applications in one click
Frequently Asked
What people ask us most often
How do I tell an attack from a badly behaved crawler?
Three awk commands over the access log. Rank source addresses: a few with enormous counts is a scraper, thousands with small counts is distributed. Rank requested URLs: your search endpoint at the top means an application-layer problem. Rank user agents: an identifiable crawler is a robots.txt and rate-limit conversation, not an attack.
What does the filtering stop, and what still reaches my application?
Volumetric traffic is scrubbed upstream — 1 Tbps+ of capacity in front of the VPS range, on a 20 Gbps uplink per hypervisor, with edge filtering ahead of the shared platform too. What no network layer can judge is whether a single well-formed search request is malicious. That decision has to happen in your application.
Does mitigation slow the site down for real visitors?
Legitimate requests continue through while hostile traffic is scrubbed, so you generally observe an event in the traffic graphs rather than in downtime. A very large attack can add latency; remaining reachable throughout is the design goal rather than claiming an event is invisible.
What is the highest-value thing I can change myself?
Cache coverage. A cached page is answered by LiteSpeed without waking PHP or MySQL, so a flood aimed at cacheable URLs is absorbed for free. Check with `curl -sI` on your busiest URLs while nothing is wrong — if the top ten all miss the cache, that is your real exposure.
Keep reading
LiteSpeed Hosting
The cache layer that decides how much traffic a site can absorb before anything else has to intervene.
Laravel Hosting Plans
Application-layer rate limiting is framework work, and Laravel gives you the middleware to do it properly.
DDoS Attack (Glossary)
The definition, the layer distinction, and why the two types need completely different responses.
VPS Hosting
KVM servers from $13.52 with full root, 1 Tbps+ filtering in front and a London or Dallas location.
Plesk Reseller Hosting
Plesk-based reseller accounts, for teams whose rate-limiting and firewall work happens in that panel.
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.
Read the log. Then decide.
Edge filtering on every plan, 1 Tbps+ in front of the VPS range, and a cache that answers before PHP ever wakes.
View VPS Hosting plans