Two words, two opposite behaviours
There are two things a host can do when a flood arrives, and the industry sells both of them as "DDoS protection". The first is absorption: traffic is pulled into a scrubbing layer upstream of your server, attack packets are dropped there, legitimate packets carry on, and your service stays reachable throughout. The second is blackholing — also called null-routing, or RTBH after RFC 5635 — where your IP address is withdrawn from the routing table so that nothing reaches it at all. The flood stops hitting the datacentre. So do your users, your monitoring and your SSH session. The attacker gets precisely the outcome they paid for.
Both are real engineering and neither is dishonest on its own terms. Blackholing exists because absorbing a large flood costs actual money — transit is metered, scrubbing capacity is bought and provisioned — and a budget host that null-routes one customer to keep four hundred others online is making a defensible call. The trick is the pronoun. "DDoS protection" is true in both cases; what differs is whose service is being protected. Read every plan card with that question in front of you.
| Response | Attack traffic | Your service | Usually described as |
|---|---|---|---|
| Scrubbing / absorption | Filtered upstream, dropped at the edge | Stays up, usually with no visible change | "Always-on mitigation", "anycast scrubbing" |
| Blackhole / null-route | Discarded together with your legitimate traffic | Offline for the duration — commonly 1–24 h | "Protection up to X Gbps", "temporary IP suspension" |
| Edge rate-limit only | Partially dropped, partly at random | Degraded — real users see packet loss | "Basic protection included" |
| Nothing (the carrier decides) | Reaches the rack until an upstream blackholes the prefix | Offline, and so are your rack neighbours | "DDoS protection available" |
Reading the fine print before you pay
The vocabulary gives it away. "Protection up to 10 Gbps" is a ceiling, and the sentence immediately after it — the one about traffic exceeding the limit — is the null-route clause. "Protected IP available as an add-on" means the address you get by default is not protected. "Per-incident" means an invoice arrives after the attack does. "Fair use" attached to mitigation means a quota of attacks per month, after which you are on your own. None of these phrases are lies; they are simply written to be skimmed past.
A named, published example, because it is documented policy rather than gossip: BuyVM sells DDoS-filtered addresses as a separate $3/month per-IP add-on, and unfiltered addresses are null-routed while an attack is in progress. We describe it without much editorialising on our BuyVM comparison page, because a cheap unfiltered IP is a perfectly reasonable product when you know that is what you bought. The failure mode is finding out at 03:00 with a booter running.
Four questions worth sending to pre-sales before the first invoice. What is the mitigation capacity, and is that number the aggregate or the figure available at a single point of presence? A "2 Tbps network" that terminates in one scrubbing centre has one pipe to fill. Is mitigation included on this plan or is it an add-on? Is there a per-incident charge or a monthly quota of mitigated events? At what threshold do you null-route, and for how long? A host that answers the last one with a number is worth more than one that answers it with adjectives.
The three layers, and why the layer decides who can fix it
Layer 3/4 volumetric. SYN floods, UDP floods, and reflection or amplification through open NTP, DNS, memcached, CLDAP and SSDP services. The attacker spends a little upstream bandwidth and gets back a multiple of it aimed at you. This is a bandwidth and packets-per-second problem, and it is categorically unsolvable on your server: by the time your kernel could drop the packet, the pipe carrying it is already full. Nothing in nftables saves you here. Only capacity above you does.
Layer 4 state exhaustion. SYN, ACK and connection floods sized not to fill the pipe but to fill a table — the kernel's SYN backlog, the conntrack table, the accept queue of your application. Bandwidth can be trivial: a few hundred Mbps will take down an untuned box while the graph on the host's side looks like a quiet afternoon. This layer is genuinely half yours: it is survivable with tcp_syncookies, a sized nf_conntrack_max, and per-source limits, and it is not survivable without them.
Layer 7 application. HTTP floods made of individually valid requests — real TLS handshakes, credible User-Agent strings, sometimes real browsers — aimed at whatever on your site is expensive: search, login, cart, a database-backed listing page. The HTTP/2 Rapid Reset class showed how few megabits it takes when each request costs the server more than it costs the client. A scrubbing appliance cannot see inside a TLS session it does not terminate, so this layer is handled either by rules at the edge or by your own reverse proxy — never by raw volumetric capacity.
| Layer | Typical attack | Typical size | Where it must be stopped | Fixable on your box? |
|---|---|---|---|---|
| L3/L4 volumetric | UDP flood, DNS/NTP/memcached amplification | 5 Gbps – 1+ Tbps | Upstream, at the edge | No — the pipe fills first |
| L4 state exhaustion | SYN / ACK flood, conntrack exhaustion | 0.1 – 10 Gbps | Edge, plus kernel tuning | Partly — syncookies, conntrack sizing |
| L7 application | HTTP(S) request flood, slow POST, Rapid Reset | Often under 1 Gbps | Edge rules or your reverse proxy | Yes — rate-limit, challenge, cache |
How big is a real attack, honestly?
Roughly nine attacks in ten that land on a small offshore server come from a booter or stresser — a subscription service costing $10 to $30 a month that resells amplification capacity by the minute. They deliver something between 5 and 50 Gbps in bursts of a few minutes, and they are what a Minecraft server, an IRC network, a Tor relay, a forum with an angry ex-moderator or a competitive game lobby actually faces. This band is entirely survivable and it is also entirely sufficient to knock over an unprotected $5 VPS.
The next band up — 100 to 400 Gbps from a rented botnet — is what arrives when somebody has a specific grudge and a budget. It is rare against small targets and routine against gambling, streaming and adult properties. Above that sit the record-class events reported by the large mitigation vendors, now measured in multiple terabits per second and hundreds of millions of requests per second; the quarterly figures on Cloudflare Radar are the usual public reference. You are almost certainly not the intended target of one of those.
You can still be a casualty of one, and this is the part nobody puts on a plan card: collateral damage travels by prefix. If a host blackholes at /24 granularity — many do, because that is the smallest prefix most carriers will accept for RTBH — then an attack aimed at one address in your subnet takes down every address in it. Your uptime depends on a stranger's enemies. Capacity headroom is what keeps that decision from ever needing to be made.
Our own numbers, for calibration rather than as a boast: 1 Tbps of anycast L3/L4 scrubbing split across four points of presence, each able to absorb roughly 300 Gbps standing alone, with automatic detection inside two seconds. The largest event we have absorbed for a customer was north of 600 Gbps against a game server, and the player connections did not drop. The architecture is documented in more detail on the network page.
Included, per-incident, or quota — the commercial shape matters
There are three ways to sell mitigation and they produce very different bills. Included: the cost is priced into the plan and an attack changes nothing about what you pay. Per-incident: you are charged for each mitigated event, sometimes per hour of mitigation. Quota: a number of events per month, or a "fair use" clause that lets the host decide when you have had enough.
The per-incident model is not a scam. Scrubbed traffic still crosses the host's transit before it is dropped, and transit is billed at the 95th percentile or against a committed rate — a sustained campaign against one customer is a real line item on someone's invoice. The problem is not fairness, it is predictability: under a two-week campaign, a per-incident host turns an attack on you into a bill for you, which is a second attack with extra steps. Ask which model applies before you need to know.
Our position, stated plainly so it can be checked: the shield is on by default on every plan from the $8.50 Starter to the $299.50 Citadel, there is no opt-in, no per-incident charge, no monthly quota and no "fair use" clause attached to mitigation. It is the same fabric on the cheapest VPS as on the largest dedicated box — see the VPS plans and the dedicated tiers. What scales with the tier is the uplink and the optional Layer 7 rule set, not whether you are defended at all.
Anycast diffusion, and why detection time beats headline capacity
A single scrubbing centre has a hard ceiling: the transit into that one building. It also has a latency cost, because during mitigation everyone's traffic is hauled to that building first — the reason some hosts get visibly slower for European users the moment an attack starts, and stay that way until it stops.
Anycast changes the arithmetic before any hardware is involved. The same prefix is announced from every point of presence, so a globally distributed botnet is split across those points by internet topology alone: a 600 Gbps attack sourced from everywhere arrives as roughly 150 Gbps in four places rather than 600 Gbps in one. Diffusion does most of the work; the scrubbing gear only has to handle what is left after geography has already divided it.
Detection time is the underrated number. Mitigation that engages in two seconds is invisible to a TCP session; mitigation that engages in sixty seconds arrives after your users have reloaded twice and left, and after a game lobby has emptied. When a host quotes capacity but not detection latency, ask for the second figure — it is the one that decides whether your users ever noticed.
If you bring your own prefix, blackholing becomes a scalpel you hold rather than something done to you. Our BGP communities cover per-carrier de-preference (cs:100:carrier), regional prepend (cs:200:region) and selective blackhole (cs:666:prefix), so you can null-route one address under attack while the rest of your allocation keeps serving. That is blackholing used correctly: surgical, brief, and your decision.
The offshore complication: a US proxy in front undoes the point
The standard advice on every forum is "just put it behind Cloudflare, the free tier is fine". For an ordinary site it is good advice. If you chose an offshore host for jurisdictional reasons, it quietly re-imports everything you left: a US-incorporated company now terminates your TLS and sees your plaintext, receives abuse and copyright complaints and acts on them under its own policy, holds an account tied to an email address and usually a payment method, and can be served with US legal process. Your host ignoring a DMCA notice is worth very little when your CDN honours it — the mechanics are in the DMCA-ignored explainer and the jurisdictional exposure in the 14-Eyes guide.
A proxy also does not hide your origin unless you firewall the origin to the proxy's prefixes and keep it that way. Even then the address leaks through passive DNS history, through certificate transparency logs if the origin ever answered TLS on its own name, through mail sent directly from the box, through an old A record that was never removed, and through any error page that echoes the server's own hostname. Direct-to-origin hits are how "protected" sites get taken down anyway. The anonymous-hosting playbook walks the full leak surface.
If you want a proxy layer without the jurisdictional cost, run it yourself: a second small instance in the same or a compatible jurisdiction, terminating TLS under your own key, with the origin's firewall accepting nothing but that address. You keep the caching and the request filtering, and no third party joins the trust chain. Both machines sit behind the same scrubbing fabric, so the proxy is not a new soft target.
What is still your job, on the box
Upstream scrubbing protects the pipe. It does not tune your kernel, and the state-exhaustion band is where an untuned server dies to an attack the network barely registered. The short list, in the order it pays off: enable net.ipv4.tcp_syncookies and raise net.ipv4.tcp_max_syn_backlog (the parameters are documented in the kernel's ip-sysctl reference); size nf_conntrack_max to the connection count you actually expect, or use notrack for high-rate UDP game traffic so the table is never consulted; add per-source rate limits in nftables rather than counting on the edge to be surgical.
On the application side, limit_req and limit_conn in nginx cost nothing and stop most L7 floods that are not deliberately shaped to look human. Cache what can be cached, because an attacker's best target is always the one page you generate from the database on every request. Keep SSH and any control panel off the address that serves the public workload, or behind an allowlist.
One direction people forget: do not become a reflector. An open DNS resolver, an unconfigured NTP daemon or an exposed memcached on your box makes you part of somebody else's amplification attack, and outbound abuse is treated far more sharply than inbound — the published response time in our AUP is a null-route and suspension inside two hours. Inbound floods are something that happens to you; outbound floods are something you are responsible for.
The checklist worth running before you buy
Nine questions, in the order that separates hosts fastest. What is the mitigation capacity, and is it per point of presence or aggregate? Is it included in the plan price or sold per IP? Is there a per-incident charge, or a quota of mitigated events per month? What is the detection latency? Is Layer 7 filtering available at all, and on which tiers? At what threshold and for what duration do you null-route, and are you told when it happens? Does mitigation change my routing or my latency while it is active? Is the protection on the address I get by default? And — the one almost nobody asks — what is retained about my traffic while mitigation is running?
That last question matters more in this market than in any other. Scrubbing means something upstream is looking at your packets. Ask what survives the event. Our answer, and it does not change during an attack: detection runs on aggregate counters at the edge — packets and bits per second, per prefix — not on retained per-flow records, and the standing position of no netflow, no PCAP and no NIC mirroring published in the privacy policy applies during mitigation exactly as it does the rest of the time. A host that cannot answer this is telling you something.
If the answers come back thin, the fallback is cheap: buy one month of the smallest plan, point a monitoring probe at it, and ask support directly what happens when the box gets hit. There is no contract here and no setup fee, so a host that dodges the question in writing costs you $8.50 to find out about. Deploy a Starter, or read VPS versus dedicated if the workload is large enough that the answer changes the tier.
