Shared Hosting 
WordPress Hosting 
Cloud VPS Hosting 
Dedicated Servers 
How 25 Gbps of DDoS Protection Lost to a 2.4 Gbit/s Attack
Last reviewed: October 2026
In August 2026 one of our Swiss dedicated customers went completely offline. They were subscribed to a 25 Gbps DDoS protection service. The attack that took them down peaked at 2.4 Gbit/s at their edge, roughly a tenth of what they were paying to absorb.
Nothing was broken and nothing was mis-sold. The DDoS protection was working, and working hard. The incident is worth writing up because it demonstrates the two things that feature lists never mention: the phrase covers wildly different products, and even the expensive version does not save a server that is unprepared for what gets through.
The short version: cheaper DDoS protection tiers often filter nothing. They stop an attack from consuming your bandwidth allowance, which is a real benefit and not the one the name implies. Real mitigation means diverting traffic to a scrubbing centre, and it is a separate and more expensive product. Either way, attacks are measured in packets as well as bits, and a small attack with a very high packet rate will take down a server that a far larger attack would not have touched.
What happened
The attack arrived mid-morning and ran for about fifty minutes. Measured at the customer's own edge:
Peak inbound: 2,383 Mbit/s
Peak packet rate: 1,847,229 packets per second
Protocol: roughly 70 per cent UDP, aimed overwhelmingly at destination port 80 with some 443
Sources: a sampled fifteen-second flow extract contained 39 distinct source addresses, most appearing only once or twice. No concentrated origin to filter on.
If those two peaks landed together, the packets averaged about 161 bytes on the wire. If they did not, the packets at peak rate were smaller still. Either way this was nowhere near an attempt to fill a pipe. It was an attempt to make a machine do work, nearly two million times a second.
It succeeded. The connection tracking table on the customer's edge filled at its ceiling of 1,048,576 entries, the kernel began logging a full table and dropping packets, and all three addresses stopped serving.
Here is the part worth dwelling on. CPU, memory and the network card were nowhere near saturation: an 80 vCPU, 64 GB machine sitting at around 20 per cent utilisation with zero missed packets at the interface. The hardware had capacity to spare in every dimension anyone monitors. The bottleneck was a kernel table that nobody thinks about until it overflows, and no amount of additional hardware would have helped.
One more detail. The flood targeted UDP on ports 80 and 443, where this customer runs TCP only. There is no UDP listener and no HTTP/3. Every single one of those packets was invalid by definition, and the kernel was dutifully allocating a tracking entry for each one.
What the upstream saw
When we escalated, the picture from the network side was considerably larger than what reached the server. Mitigation events during that window were reported at 54 Gbps and 77.3 Mpps, 39.6 Gbps and 137.5 Mpps, and later 56.6 Gbps and over 818 Mpps. As the campaign continued across following days the total exceeded 1 Tbit/s.
Try dividing those pairs and you get something interesting. 39.6 Gbps across 137.5 million packets implies 36 bytes per packet. 56.6 Gbps across 818 million implies under nine. Both are smaller than the minimum Ethernet frame, which is to say both are impossible.
That is not corrupted data. It is the whole point of this article showing up in the carrier's own alert logs: bit rate and packet rate are measured independently and peak at different moments, so the pairs are two separate maxima from the same event rather than a matched reading. Operators report them separately because they are separate, and DDoS protection sold to you in gigabits per second is describing one axis of a two-axis problem.
The residue is the attack
Scrubbing worked. The overwhelming majority of that traffic never reached Switzerland. What arrived was leftovers, and the leftovers were enough to cause a total outage.
No DDoS protection service removes everything, and the arithmetic of volumetric defence makes clear why that matters. Against a 1 Tbit/s attack:
| Removed | Still delivered to you |
|---|---|
| 99% | 10 Gbit/s |
| 99.9% | 1 Gbit/s |
| 99.99% | 100 Mbit/s |
A filtering rate that would be called excellent in any other context still hands you a substantial attack, and the same proportion applies to packets. Taking the reported 54 Gbps event against the 2.4 Gbit/s that arrived, something like ninety-five per cent of that event's volume was being stripped out. The remaining five per cent took the customer offline for the better part of an hour.
Upstream mitigation is not a shield. It is a reduction, and you have to be able to survive what it leaves.
What DDoS protection means on a feature list
Our Swiss dedicated servers include a DDoS protection option as standard, and we asked our upstream directly what it covers, because we did not want to guess on a customer's behalf.
The answer, in writing, was that the included tier will not block or filter malicious traffic. What it does is protect you from overusing bandwidth as a result of an attack. It is intended for customers who plan to handle mitigation themselves, for instance by putting a CDN or scrubbing service in front of their own origin.
Read that again in the context of a pricing page. An option called DDoS protection, which does not stop a DDoS. It is not dishonest and it is genuinely useful: an attack that would otherwise blow through your transfer allowance and generate an overage bill does not. But a customer reading two words on a feature list will assume something else entirely, and the gap between those two readings is where outages live.
The tier that scrubs is a separate purchase. On that one, traffic is diverted to the nearest scrubbing centre within about three minutes of detection, the malicious portion is dropped and clean traffic is forwarded on. That is the thing most people picture when they read the phrase.
Three practical traps
Thresholds may be expressed in bits, not packets. This is what caught the customer above. A 2.4 Gbit/s attack against a 25 Gbps subscription looks like background noise if you are watching bandwidth. The 1.85 Mpps packet rate was the part that mattered, and packet-rate ceilings are not published for these tiers. Neither the reseller nor the carrier would give a figure, and that is normal across the industry rather than evasion by anyone in particular.
Upgrading may mean renumbering. Basic DDoS protection is typically applied as a blanket across every address allocated to a server. The scrubbed tier was not an upgrade in place: it came with a newly allocated range that has scrubbing enabled, so you change IP addresses and update DNS. The old range stayed live briefly so the switch could be made cleanly, but it is a migration rather than a checkbox, with all the planning that implies.
The useful tools exist; you probably cannot reach them. We asked whether UDP to ports 80 and 443 could simply be discarded upstream for that customer, since it is always invalid for them. The answer was no. The capability is not the problem: carriers routinely offer BGP Flowspec, which lets a customer specify exactly which traffic to discard inside the carrier network, along with blackhole communities that drop UDP selectively. Those are offered to the carrier's own transit customers. If you buy a server from a host, who rents a rack from a datacentre, who buys transit from a carrier, you are three steps from the party who can pull those levers, and each step has its own reasons not to maintain per-customer rules. Stale network policy causes outages later, so nobody wants to own yours.
The DDoS protection ladder, in plain terms
| What it is | What happens to you during an attack |
|---|---|
| Deprioritisation | Traffic identified as hostile is marked to be dropped first if a link congests. Protects the carrier's backbone and your neighbours. Does nothing for you when the link is not congested, which is exactly the small-packet case. |
| Bandwidth protection | Nothing is filtered. You are shielded from the billing and allowance consequences of the flood, not from the flood. Mitigation is your problem. |
| On-server filtering | Your own firewall drops bad packets. Free and instant, and useless once traffic exceeds what your link or your kernel can process. |
| Selective blackholing | Carrier-side communities that discard a category of traffic, typically all UDP or traffic from known amplifiers. Blunt but effective, and it keeps TCP alive. |
| Flowspec | Filtering rules pushed into the carrier network over BGP, matching protocol, ports and packet characteristics. Surgical, and generally reserved for direct transit customers. |
| Scrubbing | Traffic diverts to a scrubbing centre, the attack is separated out and clean traffic is delivered. The expensive tier, and the one that keeps you online. |
| Null-routing (RTBH) | Your IP is announced with a blackhole community and all traffic to it is discarded at the network edge. The attack stops. So does your site. |
Null-routing deserves a word of defence. It is not a scam, it is the correct response when an attack would otherwise saturate shared infrastructure and take down everyone else on it. The problem is purely one of labelling: a provider whose only answer is a blackhole still writes DDoS protection on the pricing page, and from your seat that protection is indistinguishable from an outage.
Attacks in 2026, for scale
Two numbers from Cloudflare's H1 2026 threat report are worth holding together. In the first half of 2026, 96.62 per cent of the network-layer attacks they mitigated stayed under 500 Mbps and 90.60 per cent finished inside ten minutes. At the same time, attacks exceeding 1 Tbps rose from 130 in the first quarter to 805 in the second, and the current public record, mitigated in November 2025, hit 31.4 Tbps and lasted 35 seconds.
Thirty-five seconds is the number to remember, because it means no human is involved in your defence. By the time an alert reaches anyone, the attack is over. Whatever DDoS protection you have is automated and configured in advance, which is why what you bought matters more than how responsive the support desk is.
What to actually do
- Tune your edge before you need to. The outage above was a conntrack table at its default ceiling. Raising kernel limits and adding a filter that discards invalid traffic before connection tracking sees it let that customer absorb 831 million packets and 124 GB of hostile traffic afterwards without an interruption. The fix cost nothing, and it had to be done on the server because nobody upstream would do it.
- Drop what cannot be legitimate. If your ports 80 and 443 serve TCP only, UDP to those ports is always invalid. Say so explicitly in your firewall rather than letting the kernel allocate state for it.
- Ask about packets, not just gigabits. DDoS protection sold in Gbps describes one axis. Ask what the packet-rate behaviour is, and if nobody will tell you, assume a high-rate small-packet flood is the case you have to survive yourself.
- Separate services across addresses, but confirm first whether mitigation applies per address or across the whole subnet, or the separation buys you nothing.
- Cache aggressively. Application-layer floods work by making your server do expensive work per request. A well-cached site absorbs far more before anything upstream is involved.
- Understand what a CDN changes. Putting a large edge network in front of your origin is the most effective volumetric DDoS protection available to a small operator, and it hands that company plaintext visibility of every request. Worth deciding deliberately, which we covered in what the edge actually sees.
- Size the machine for the right thing. More cores would not have helped here. If you are specifying a server with this in mind, our notes on choosing a VPS without overpaying apply equally to dedicated hardware.
Questions worth asking any host
1. Does the included DDoS protection filter attack traffic, or only protect my bandwidth allowance?
2. If it filters, is it scrubbing or null-routing, and how long does a null route stay in place?
3. Are detection thresholds based on bits per second, packets per second, or both?
4. Is mitigation applied per IP or across the whole subnet?
5. If I upgrade to a scrubbed tier, do I keep my IP addresses?
6. Can any standing filter rules be applied upstream, or is that entirely on me?
7. Will I be notified when mitigation triggers, and can I see what was dropped?
A provider who answers all seven precisely is worth more than one advertising a larger number. Vagueness here is usually not evasion. It is that they are reselling capacity and never asked either.
Where we stand
Our Swiss dedicated servers include a DDoS protection tier as standard, applied as a blanket across every address allocated to the server. As set out above, our upstream has confirmed in writing that this protects against the bandwidth consequences of an attack and does not filter hostile traffic. Scrubbed DDoS protection is available at additional cost, and moving to it means a new IP range rather than an in-place upgrade.
We would rather publish that plainly than leave two words sitting on a feature list doing work they cannot do. If you are evaluating us for something where this genuinely matters, open a ticket before you order and ask which tier fits. You will get the same answer as above rather than a marketing one.
The general lesson holds whoever you buy from. A host advertising DDoS protection is telling you that something happens when an attack arrives. It is not telling you whether your site is still serving afterwards, and it is certainly not telling you whether your own edge can cope with what gets through. Those are the two questions, and almost nobody volunteers them.
Research note. The incident described is a real case on our Swiss infrastructure in August 2026, published with identifying details removed. Figures at the customer edge are their own measurements; mitigation event figures are as reported in upstream alert logs, where bit-rate and packet-rate peaks are recorded independently and should not be read as matched pairs. DDoS protection tier behaviour is as confirmed to us in writing by our upstream provider for the service as supplied to us, and may not describe how a carrier's equivalent product is sold directly. Carrier-side tooling described in the ladder reflects published documentation for BGP transit customers. Attack statistics are from Cloudflare's H1 2026 and Q4 2025 DDoS threat reports. Last checked October 2026.
Frequently asked questions
How can a 2.4 Gbit/s attack take down a server with 25 Gbps of DDoS protection?
Because bandwidth is not the only axis. That attack carried 1.85 million packets per second in very small packets. The volume was trivial, the packet rate was not, and it exhausted a kernel connection-tracking table while CPU, memory and the network card all sat idle.
What is the difference between blackholing and scrubbing?
Blackholing discards every packet destined for your IP, including your legitimate visitors, so the attack stops affecting the network and your service is offline. Scrubbing diverts traffic through filtering infrastructure and delivers the clean remainder, so your service stays up.
Does basic DDoS protection do anything at all?
Yes, just not what the name suggests. On the tier we include as standard, it protects you from the bandwidth and allowance consequences of an attack. It does not filter hostile traffic, which is left to you or to a service you put in front.
Will scrubbing keep my site up completely?
Not necessarily. Removing 99.9 per cent of a 1 Tbit/s attack still delivers 1 Gbit/s to your door, and that residue can be larger than most servers handle. Your own edge needs to absorb what gets through.
Can my provider block specific traffic upstream for me?
Usually not, even though the technology exists. Carriers offer BGP Flowspec and selective blackhole communities to their direct transit customers. If you are buying a server from a host who rents from a datacentre who buys transit, you sit several steps from whoever can apply those rules, and per-customer policy is something nobody in that chain wants to maintain. Anything specific to your application belongs on your own firewall.
How big is a typical attack?
Smaller than the headlines suggest. In the first half of 2026 over 96 per cent of network-layer attacks stayed under 500 Mbps and over 90 per cent lasted under ten minutes. That is still more than an unprepared small server can absorb.
