"Best" is not a ranking — it is a checklist
Search results for the best DDoS protection are a list of vendors, each asserting the superlative about itself. None of that is testable. What is testable is a short set of properties that decide two things: whether the service stops the attack you will actually get, and whether you can afford to leave it switched on for the years before that attack arrives.
Eight criteria, in the order they change outcomes:
1. Always-on, not on-demand. On-demand mitigation is activated after someone notices the outage. Even with a perfect operator, BGP or DNS diversion into a scrubbing center takes 5–20 minutes to converge — and those are the minutes the attack was designed to win. Always-on edge filtering has nothing to converge: the traffic is already arriving at the filter.
2. Real Layer 7 defense, not just gigabits. Capacity numbers are the loudest thing on every provider's homepage and the least likely thing to save you. Volumetric floods are absorbed by any competent backbone. The attacks that take sites down are application-layer — a few thousand requests per second against search, login or checkout, each request individually indistinguishable from a real visitor. Ask what the edge does when volume looks normal and the origin is dying anyway.
3. No CAPTCHA tax on real visitors. A defense that makes every human prove themselves with an image grid converts your traffic into abandonment. The current state of the art is an invisible proof-of-work challenge: the browser burns a fraction of a second of CPU, the visitor sees nothing, and the same cost multiplied by a botnet is prohibitive.
4. Attack traffic must not be billed to you. This is the criterion buyers skip and regret. If mitigated bytes count against your bandwidth quota, an attacker can spend your allowance and push you into overage — or into a hard cut-off — without ever reaching your origin. The attack becomes a billing event you pay for.
5. Every feature available before the attack. Under attack you will want a WAF rule, a rate limit, a waiting room and raw request logs, in the same hour. If any of those sit one tier above your plan, your incident response is a procurement conversation. Check where the tier lines fall, not just the price.
6. Evidence, at request granularity. Aggregate graphs tell you that something happened. Per-request logs — status, latency, client fingerprint, WAF verdict — tell you what happened, which is what a post-mortem, an insurance claim and a police report all need. Check the retention period before you need it.
7. Onboarding you can reverse. Protection that requires moving your nameservers moves your entire DNS zone into the blast radius of a decision you have not tested yet. Two records at your existing DNS provider lets you migrate one hostname, watch it, and roll it back in a TTL.
8. Jurisdiction and data protection. Every request your visitors make passes through this provider. For anyone inside the EU that makes the operator's jurisdiction, its DPA, its sub-processor list and its retention policy part of the technical decision, not paperwork after the fact.
| Criterion | Why it decides the outcome | What to ask |
|---|---|---|
| Always-on filtering | On-demand diversion costs 5–20 minutes per trigger | Is mitigation active before the first attack packet? |
| Layer 7 mitigation | Volume looks normal while the origin dies | What happens at 5,000 rps of realistic-looking requests? |
| Challenge type | CAPTCHAs cost conversions | Proof-of-work, or an image grid? |
| Attack traffic billing | An attack can exhaust your quota | Are mitigated bytes metered? |
| Feature availability | Incident response cannot wait for an upgrade | Which features are tier-locked? |
| Per-request logs | Post-mortems need evidence, not averages | What is logged, and for how long? |
| Onboarding | Nameserver moves are hard to reverse | DNS records, or a full zone transfer? |
| Jurisdiction | All visitor traffic transits the provider | Where is the operator, and is the DPA published? |
How Itnetic answers the checklist
Itnetic was built against exactly this list, which is the honest reason it scores well on it.
| Criterion | Itnetic |
|---|---|
| Always-on filtering | Always on from the first request; a host flips into challenge mode within a second of a spike, decided at the edge without a control-plane round trip |
| Layer 7 mitigation | Behavioral signatures over path, header shape and TLS fingerprint; adaptive challenge stages; repeat offenders dropped in the kernel so they cost nothing per request |
| Challenge type | Invisible proof-of-work. No image grids, no puzzles, no third-party CAPTCHA |
| Attack traffic billing | Scrubbed attack traffic is never metered, on any plan — including free |
| Feature availability | Every feature on every plan: WAF, custom rules, IP reputation, rate limiting, waiting room, per-request logs, origin load balancing, CDN |
| Per-request logs | Status, latency, client fingerprint and WAF verdict per request, exportable via the API |
| Onboarding | Two DNS records at your existing provider — no nameserver change, one hostname at a time |
| Jurisdiction | Operated from the Czech Republic (EU); DPA, sub-processors, retention and incident-response policies published in full |
Volumetric capacity sits upstream of that edge: Frankfurt and Beauharnois run behind X4B, a network with 500 Gbps of mitigation capacity, and Singapore runs on OVHcloud behind OVHcloud's own network-level protection. The network page has the current list.
Best DDoS protection by situation
The right answer genuinely changes with what you are protecting.
- Personal sites and side projects. What matters is that the free tier is real protection rather than a trial. Itnetic's Starter plan is free, covers one domain and 2 GB of delivered traffic a month, and ships the same mitigation stack as the €1,000 plan.
- WordPress. The flood targets are always the same handful of endpoints —
xmlrpc.php,wp-login.php,admin-ajax.php, unbounded search. You need custom WAF rules and rate limits on those paths, and edge caching in front of the read traffic that a PHP security plugin never gets a chance to see. - Online stores. Checkout is uncacheable and breaks first, and a genuine Black Friday surge looks like an attack. Prioritize a waiting room and card-testing/scraper defenses over raw capacity.
- APIs. Browser challenges break machine clients. You need per-credential rate limits, behavioral signatures instead of interstitials, and correct 429/403 status codes rather than HTML your client cannot parse.
- Minecraft and game servers. A different protocol and a different attack surface — join floods, ping floods, connection floods — which a web WAF does not address at all.
- Very large enterprises. If your requirement is anycast at hyperscaler scale, an edge compute platform, or a global enterprise contract with named support, buy from Akamai, Cloudflare or AWS. Itnetic is deliberately not that.
The two commercial traps
Nearly every complaint about DDoS protection reduces to one of two things, and both are visible before you sign.
The attack is billed to the victim. If mitigated bytes count against your quota, the flood spends money you did not budget, and a large enough attack pushes you into overage or a cut-off page — caused by the very traffic you are paying to have filtered. Itnetic classifies mitigation bytes separately at the edge (challenge pages, rate-limit responses, WAF blocks) and subtracts them before metering. Only delivered, legitimate traffic counts.
The feature you need is one tier up. The waiting room is the classic case: teams discover it is a Business-plan feature at the moment they need it, during a launch or a restock. Raw per-request logs are frequently Enterprise-only. Itnetic's plans differ by domain count and delivered bandwidth and by nothing else, so an incident never turns into an upgrade decision. The comparison pages lay out where those lines sit for other providers.
A ten-minute buying check
Run this against any shortlist, including ours:
- Read the pricing page and write down every feature marked as tier-limited.
- Find the sentence that says whether attack traffic is metered. If there isn't one, ask.
- Check the log retention period and whether raw per-request rows are exportable.
- Check whether onboarding is DNS records or a nameserver change.
- Find the DPA and the sub-processor list. If they are not published, that is your answer.
- Sign up for the free tier and put one non-critical hostname behind it for a week.
Step 6 is the one that matters. Every claim on this page — ours included — is checkable in an afternoon with a test hostname, and the best DDoS protection for you is whichever one you have already watched work. When you are ready, Itnetic's DDoS protection goes live with two DNS record changes, on a free plan with nothing held back.
Still deciding what you are defending against? Start with what a DDoS attack is, then how mitigation actually works.