If you are hosting production workloads on a UK dedicated server, DDoS protection is not optional. The question is not whether you need it — the question is whether your provider's "included DDoS protection" is real mitigation or a marketing line that covers you until the first serious attack, at which point your server goes offline and the provider shrugs and points at the SLA.
This guide covers the attack types that matter in 2026, the mitigation layers a UK provider should have, the difference between network-level and application-level protection, and the specific questions to ask that separate a provider who can absorb a 100 Gbps attack from one who will null-route your IP at the first sign of trouble.
The attack landscape in 2026: what you are actually defending against
DDoS attacks have changed. Five years ago, most attacks were volumetric — large UDP floods designed to saturate your network link. These are still common, but the attacks that actually take services offline in 2026 are more targeted and more sophisticated.
Volumetric attacks (Layer 3/4)
UDP floods, amplification attacks (DNS, NTP, CLDAP, Memcached), and SYN floods. These work by overwhelming your network capacity. A 50 Gbps UDP flood against a server with a 1 Gbps uplink will take it offline regardless of what software you run. The only defence is upstream capacity that can absorb the traffic before it reaches your link.
Amplification attacks are the most common volumetric vector. The attacker sends small spoofed requests to open DNS resolvers or Memcached servers, which respond with large packets directed at your IP. A 1 Mbps spoofed request to a Memcached server can generate up to 51,000x amplification — meaning a single compromised server with 100 Mbps uplink can generate 5 Gbps of reflected traffic.
Application-layer attacks (Layer 7)
HTTP floods, slowloris, and cached-busting requests that target your web server's connection and processing limits rather than your network bandwidth. A 500 Mbps HTTP flood against an nginx server with 1,024 worker connections will take the server offline even though the bandwidth is well within capacity. Each request consumes a worker, a database connection, and application processing time.
Layer 7 attacks are harder to mitigate because they look like legitimate traffic. The packets are well-formed HTTP requests. They use real User-Agent strings. They follow redirects. They solve CAPTCHAs if the attacker is motivated enough. Mitigation requires application-aware inspection, not just traffic filtering.
Protocol attacks
SYN floods, fragmented packet attacks, and Ping of Death variants. These target the TCP/IP stack itself, exhausting connection state tables or causing the kernel to spend all its CPU time processing malformed packets. A well-executed SYN flood can consume all available kernel memory on an unconfigured server with as few as 50,000 packets per second.
The three layers of DDoS protection
Effective DDoS protection is layered. No single technology handles all attack types. A UK provider who claims "DDoS protection included" should be able to tell you which of these layers they operate and what capacity they have at each.
Layer 1: Upstream transit capacity
This is the most basic form of protection and the one most providers are quietly relying on when they say "DDoS included." If the datacentre has 100 Gbps of upstream transit and the attack is 40 Gbps, the attack traffic is absorbed at the network edge and never reaches your server. Your service stays online because the datacentre's pipe is bigger than the attacker's.
The problem is capacity. A London Tier 3 datacentre might have 40-100 Gbps of upstream. The largest recorded DDoS attacks in 2025 exceeded 800 Gbps. If the attack is larger than the datacentre's upstream capacity, the entire facility is affected — not just your server. At that point, the datacentre's upstream providers will null-route the target IP to protect the rest of their network, which means your server goes offline.
Ask your provider: What is the total upstream capacity of your datacentre, and at what attack size do you null-route? If the answer is "we null-route at 20 Gbps" or they cannot answer, the protection is upstream capacity only, and it has a hard ceiling.
Layer 2: Scrubbing and traffic filtering
When an attack is detected, traffic to your IP is redirected through a scrubbing appliance — either on-premise (Arbor, Radware, FortiDDoS) or cloud-based (Cloudflare Magic Transit, AWS Shield, Voxility). The scrubber analyses packets in real time and drops attack traffic while forwarding legitimate traffic to your server.
This is more effective than null-routing because legitimate traffic gets through. But it has limitations:
- On-premise scrubbers can handle 10-40 Gbps typically. Larger attacks overwhelm the scrubber itself.
- Cloud-based scrubbing has more capacity (Cloudflare operates 300+ Tbps globally) but adds latency — typically 10-30ms for traffic routed through the scrubbing network. For a UK-hosted server serving UK users, this means London traffic might route through Frankfurt or Amsterdam.
- BGP propagation time — when an attack starts, traffic needs to be redirected to the scrubber via BGP announcements. This takes 30-90 seconds. During that window, the attack hits your server directly.
Layer 3: Application-layer protection
For Layer 7 attacks, network-level scrubbing is not enough. You need a web application firewall (WAF) that can inspect HTTP requests and identify attack patterns. This is typically a reverse proxy (Cloudflare, Fastly, AWS WAF) that sits in front of your server and filters requests before they reach nginx.
A WAF can rate-limit by IP, challenge suspicious requests with a JavaScript or CAPTCHA challenge, and block requests matching known attack signatures. For most UK-hosted web applications, a properly configured Cloudflare or Fastly proxy in front of the server handles the majority of Layer 7 attacks without the origin server ever seeing the traffic.
The key insight: Network-level protection (Layers 1-2) is the provider's responsibility. Application-level protection (Layer 3) is yours. If your UK dedicated server runs a web application, you should have a CDN or WAF proxy in front of it — Cloudflare's free plan handles most Layer 7 attacks. Do not rely on the hosting provider to protect your application layer.
What "DDoS protection included" actually means
Most UK hosting providers include some form of DDoS protection in their base price. Here is what that typically means in practice:
| What they say | What it usually means | What to ask |
|---|---|---|
| "DDoS protection included" | Null-routing of attacked IPs at the upstream level. Your server goes offline, but the rest of the datacentre stays up. | "At what attack volume do you null-route my IP?" |
| "Up to 20 Gbps protection" | On-premise scrubbing appliance that handles attacks up to 20 Gbps. Above that, null-route. | "What happens above 20 Gbps? How long until null-route kicks in?" |
| "Always-on DDoS mitigation" | Traffic is continuously routed through a scrubbing appliance. No BGP propagation delay. Usually adds 5-15ms latency. | "What scrubbing vendor and capacity? What is the added latency?" |
| "Unlimited DDoS protection" | Cloud-based scrubbing with upstream capacity in the hundreds of Gbps. Usually a partnership with Cloudflare, Voxility, or similar. | "Is Layer 7 included, or only Layer 3/4? What is the failover time?" |
Questions to ask before signing
When evaluating a UK dedicated server provider's DDoS protection, these are the questions that will tell you whether the protection is real:
- What is the maximum attack capacity you can absorb? This should be a number in Gbps. If they cannot answer, the protection is null-routing only.
- Is mitigation always-on or on-demand? Always-on means traffic is continuously scrubbed (no failover delay). On-demand means traffic is redirected when an attack is detected (30-90 second gap).
- Do you protect Layer 7 (application) or only Layer 3/4 (network)? If only Layer 3/4, you need your own WAF for HTTP flood protection.
- What happens when the attack exceeds your capacity? The honest answer is "we null-route your IP to protect the network." The dishonest answer is "we have never had an attack we could not handle."
- Is there a surcharge for mitigation? Some providers include protection up to a threshold and charge per-incident or per-Gbps above it. Get this in writing.
- What is the SLA for mitigation response time? If it is not in the SLA, it is not guaranteed.
What ServerCabin does
We are not going to pretend our DDoS protection is perfect — no provider's is. Here is what we actually do:
- Upstream capacity: Our UK presence operates on a 40 Gbps upstream link. We can absorb volumetric attacks up to approximately 30 Gbps at the edge without affecting individual servers. Above that, we null-route the targeted IP.
- On-demand scrubbing: We use on-demand scrubbing, not always-on, because always-on adds latency to every request and the majority of our servers never see a significant attack. When an attack is detected (via netflow analysis), traffic is redirected through our scrubbing network within 30-60 seconds.
- Layer 3/4 only: Our included protection handles volumetric and protocol attacks. For Layer 7 (HTTP floods), we recommend customers put a Cloudflare or Fastly proxy in front of their server. We help with this configuration at no charge.
- Honest threshold: We null-route at 30 Gbps. We tell customers this upfront. If you need protection above 30 Gbps, we can provision a Cloudflare Magic Transit tunnel on your behalf, which extends protection to hundreds of Gbps. This is a paid add-on because it costs us money per gigabit.
We would rather be honest about the limits of our protection than claim "unlimited DDoS mitigation" and hope you never test it. If you want to talk through the specifics of your workload and what level of protection makes sense, email us or see our guide to choosing a UK dedicated server provider.
The bottom line
DDoS protection in 2026 is a layered problem. Your hosting provider should handle network-level attacks — but you should know their capacity ceiling and null-route threshold. You should handle application-level attacks with a CDN or WAF in front of your server. And you should ask the questions above before you sign with any provider, because the difference between "DDoS protection included" and actual mitigation capability is often the difference between your service staying online during an attack and your service being the thing the provider sacrifices to save the rest of the network.
Do not wait until the first attack to find out what your provider's protection actually is. Ask now, get it in writing, and put your own application-layer protection in place. The cheapest DDoS mitigation is the one you set up before you need it.