Search for a DDoS protected hosting provider and the first page of results looks settled: a Tbps figure, a monthly price, a green tick next to “DDoS protection included”. Most of those pages never say whose network the filtering happens on, what the acceptable use policy permits the provider to do to your IP address during an attack, or whether a flood of HTTP requests at modest bandwidth is covered at all. The badge is not the protection.

What follows is six checks, written as questions a provider should answer in writing before the order form, along with the lookups and paperwork that prove or disprove each answer. The National Cyber Security Centre’s denial of service guidance sets the baseline framing for UK buyers: understand your dependencies, know what your provider has committed to, and test the assumption before you need it.

What “DDoS protected hosting”actually covers (and what it rarely does)

Three shapes of protection, built for different traffic

Buyers end up with one of three arrangements, sometimes without being told which. Filtering at the hosting provider’s own network edge, where traffic to your server passes through a mitigation appliance or platform before it reaches the rack. A reverse proxy in front of your hostname, where DNS points at the provider’s anycast network and your origin sits behind it. Or BGP scrubbing for prefixes you announce yourself, where routes are diverted to a scrubbing centre and clean traffic returns over a tunnel or cross-connect.

Edge filtering is good at packets. Reverse proxies are good at requests. BGP scrubbing is for organisations with their own IP space and an AS number, and it protects everything in the prefix, including mail, VPN concentrators and DNS. Buying the wrong shape is the most common and most expensive mistake on this list.

The same badge, two different problems

Game-server hosting and web hosting advertise identical protection for attacks that have almost nothing in common. A game host is defending UDP ports against amplification and high packet-per-second floods, where the failure mode is a saturated link or an overwhelmed NIC. An ecommerce site is defending a basket endpoint against HTTP request floods that arrive politely over TLS and look like customers. Hardware tuned for one is frequently blind to the other.

Bundled as standard, or charged as an add-on

Read the plan page as a price list rather than a feature list. Protected IPs are often charged per address beyond the first; clean bandwidth has a ceiling with overage above it; web application firewall rules are a separate tier; authoritative DNS hosting is free but unprotected; attack reporting is sometimes available only on managed plans. Our breakdown of what DDoS protection really costs in the UK covers how those line items stack up at renewal.

The test to run before you talk to anyone

Write down every service you expose and mark which ones sit behind the protection: website, API, authenticated admin panel, SSH or RDP, SMTP and IMAP, authoritative DNS, game ports, monitoring endpoints, staging. Most lists come back with four or five items outside scope. That inventory is the only honest starting point for a conversation with a vendor.

Check 1: whose network and scrubbing capacity are you really buying?

A large share of hosting brands selling mitigation are reselling it. The filtering belongs to a transit provider, a colocation operator or a scrubbing vendor further up the chain, and the capacity headline on the landing page is that upstream’s number, not the reseller’s. Nothing wrong with reselling. Plenty wrong with not knowing.

Ask three things and verify them independently: which autonomous system number announces the IP space your server will sit in, who the upstream transit providers are, and which mitigation platform or vendor performs the filtering. Routing and peering data is public. Look the ASN up in RIPE’s database and a route-collector service, check the upstreams, and see whether the announcement comes from the brand you are paying or from someone else entirely. If the answer is “we don’t disclose our suppliers”, you are being asked to buy a capability nobody will name.

Shared capacity is also shared during an attack. A 2 Tbps platform figure means little if your mitigation competes with every other tenant behind the same scrubbing centre while a broad campaign is running, which is why headline numbers deserve the scepticism we set out in our guide to judging Tbps claims.

The question that produces the most useful answer is about people, not pipes: during an attack on your IP, which organisation’s engineers make the mitigation decisions, and what is the escalation path between them and you? Our interview with Derek Raines of GigeNET is a useful read on how a network operator actually thinks about that chain of responsibility.

Check 2: will they mitigate your traffic or blackhole your IP?

Remote-triggered blackholing is the cheapest mitigation in existence. The provider tags your address with the well-known BGP BLACKHOLE community defined in RFC 7999, upstream networks drop everything destined for it, and the attack traffic stops at the border. The attack also stops reaching you. From the outside, a null-route and a successful flood are indistinguishable.

The permission to do this is usually already in the contract. Acceptable use and fair-use clauses in hosting agreements commonly allow suspension, null-routing or forced migration when an attack on one customer degrades service for neighbours on the same edge. A realistic version: a few gigabits per second of UDP reflection aimed at a single tenant starts affecting the shared uplink, the provider blackholes that one address, and the customer reads a ticket reply describing a total outage as successful mitigation.

Settle four points before signing. What traffic level or condition triggers a blackhole; how long the null-route stays in place by default; who authorises its removal and how quickly; whether you are notified at the time and whether there is a charge. Dedicated hardware, dedicated IP ranges or bring-your-own-address arrangements change the calculus, because your traffic is no longer a nuisance to someone else’s tenants. If the provider cannot commit to filtering rather than dropping, a separate cloud DDoS scrubbing service in front of the hosting is the cleaner fix, even though it costs more.

Check 3: is anything above layer 4 actually protected?

Hosting-level filtering watches bandwidth and packet rates, because that is what network appliances are built to see. Do the arithmetic on a request flood and the gap becomes obvious: around 10,000 HTTP requests per second against a search or basket endpoint, each request a kilobyte or two, amounts to a couple of hundred megabits per second. On a 10 Gbps edge that is background noise. The PHP worker pool, the database connection limit and the cache miss path are what fall over, while every network threshold stays untouched and no alarm fires.

Application-layer cover needs request rate limiting per client and per endpoint, caching that absorbs repeated requests, challenge logic for suspicious clients, some form of bot scoring, and a human who tunes all of it against your traffic patterns. Ask who owns that tuning. “Layer 7 is out of scope”is an honest answer. “Here is a self-service panel”means the rules are yours to write and troubleshoot at 03:00. The seven gaps we document in application layer DDoS protection are mostly ownership failures rather than technology failures.

Then there is the trade-off no pricing page mentions. Aggressive rules and interstitial challenge pages block real customers, break payment callbacks, upset mobile apps with pinned certificates and strangle partner API integrations that do not run a browser. Whoever signs the contract should know who carries that false-positive risk, and who is allowed to switch a rule off when conversion drops.

Check 4: who protects your authoritative DNS?

DNS arrives free with the hosting account, which is exactly why it sits outside the protection scope. A perfectly reachable server behind an unresolvable domain is still an outage, and the recovery is slower because you cannot move traffic without the very records that are unreachable.

Confirm four things in writing: whether the nameservers are anycast or single-site, how many distinct networks and locations serve your zone, whether query floods are rate-limited or filtered at those nameservers, and whether DNSSEC signing is supported. Two nameserver hostnames on the same subnet in the same data centre is one network wearing two names.

Secondary DNS with a second operator is the pragmatic answer for most buyers, and it costs little. Plan your TTLs alongside it: records at 300 seconds give you room to move traffic to an alternative origin in minutes, while a 24 hour TTL commits you to a day of whatever you chose last week. Before you sign, query each advertised nameserver directly for your zone (dig @ns1.example.net yourdomain.co.uk SOA) and check the IPs against the ASN data from Check 1. If every nameserver answers from one network, you have a single point of failure dressed as redundancy.

Check 5: can anyone reach your origin directly?

When protection is bypassed, the cause is usually not attack volume. The attacker simply found the server address and attacked that instead of the protected hostname. Data centre DDoS protection applied at the proxy or scrubbing layer cannot filter traffic that never passes through it.

Origin addresses leak from predictable places: historical DNS records held by passive DNS services, Certificate Transparency logs containing certificates issued for a direct IP or a forgotten subdomain, outbound mail headers that carry the sending server’s address, status pages and staging hosts pointed straight at the box, and verbose error pages that print internal hostnames.

The hardening is unglamorous and the provider should support all of it: an origin firewall that accepts traffic on web ports only from the published proxy or scrubbing ranges, a change of server IP after migration behind a proxy so the old address in historical records is dead, outbound mail routed from a separate address or relay, and no certificate issued to the bare IP. Ask for evidence rather than assurance. A firewall rule export, the current allowlist of upstream ranges, and a connection attempt to the origin IP from an arbitrary network that times out are all proof. A support agent saying “the server is protected”is not.

Check 6: what does “managed”commit them to in writing?

The dividing line is simple. If nobody on the provider’s side is empowered to change mitigation policy at 03:00 on a Sunday without your sign-off, you have bought monitoring, not management.

Read the SLA clock carefully. “Time to mitigate measured from detection by our monitoring”and “time to mitigate measured from receipt of a customer notification”are different products at a similar price. On a shared platform, detection is often triggered by aggregate edge traffic rather than by anomalies on your specific service, which is precisely how the request flood in Check 3 stays invisible until a customer complains. Ask what counts as detection for your IP, and what the clock does while a ticket sits in a queue.

Then the human questions. Which phone number reaches an engineer out of hours, which of your named contacts are pre-authorised to request mitigation changes without a purchase order, and how do they authenticate when your own mail is down? After the event, ask for a real attack report: vectors with a breakdown by protocol, peak packet and request rates, the mitigation actions applied and their timestamps. A screenshot of a traffic graph is not a report. If you are still working out whether an incident was an attack at all, our walkthrough on telling a DDoS apart from an ordinary outage is the faster diagnostic.

Price the fine print too: charges per protected IP, clean bandwidth overage rates, contract length and notice period, and how painful migration out would be once your DNS, certificates and firewall allowlists are tied to that platform. Build the business case from your own numbers. Revenue or contractual penalty per hour, multiplied by a realistic worst-case outage, compared against the monthly difference between a basic protected VPS and dedicated mitigation with named response commitments. The NCSC’s warnings about sustained hacktivist campaigns against UK organisations, covered in our seven-step response to the NCSC hacktivist DDoS alert, make the worst case less hypothetical than it looked a few years ago.

Frequently Asked Questions

Is a DDoS protected hosting provider enough on its own?

For a single website or game server with a low cost of downtime, often yes, provided layer 7 is genuinely in scope and the provider will filter rather than null-route. For anything with revenue or statutory obligations attached, hosting-level filtering is one layer among several: it needs authoritative DNS that is separately resilient, a locked-down origin, and a tested escalation route to a human.

What is the difference between DDoS protected hosting and a cloud scrubbing service?

Protected hosting filters traffic at the edge of the network your server already sits on, and the scope is whatever that provider chooses to cover. A cloud DDoS scrubbing service is bought separately and diverts traffic to the vendor’s scrubbing centres, either by pointing DNS at a reverse proxy or by rerouting your own BGP prefixes, and it travels with you if you change host. Scrubbing usually costs more and comes with firmer response commitments.

Can a hosting provider null-route my IP during an attack?

Yes, and most acceptable use policies explicitly allow it when an attack on one customer degrades service for others on the same infrastructure. The remedy is contractual rather than technical: agree in advance what triggers a blackhole, how long it lasts, who can lift it and whether you are notified.

Does DDoS protected hosting include my authoritative DNS?

Usually not. Nameservers bundled with a hosting account are frequently single-site and outside the advertised protection scope, so confirm whether they are anycast, how many separate networks answer for your zone, and whether secondary DNS with a second operator is available.

What should I ask a DDoS protected hosting provider before signing?

Which ASN announces your IP space and which mitigation platform filters it; what triggers a null-route and who lifts it; whether layer 7 is in scope and who tunes the rules; who protects authoritative DNS; how the origin is restricted to proxy or scrubbing ranges; and whether the SLA clock starts at their detection or your ticket. Get the answers in writing before the contract, not during the attack. Further background on attack trends and vendor practice is collected across DDoSInfo.