DDoS protection

A Cloudflare DDoS protection alternative, layer by layer

Volumetric floods are the loud half of the problem and the easy half to absorb. The attacks that take sites down look like visitors. This page is about how Itnetic separates the two — every layer, in the order a request meets them, on every plan.

Anyone can absorb bandwidth if they have enough of it. That is why "we have N Tbps" is the least useful number in this industry — it answers the attack that was already going to fail. What decides whether your site survives is what happens to a flood of well-formed HTTPS requests, from thousands of residential addresses, aimed at a path that cannot be cached.

Itnetic is built almost entirely around that problem. There are seven layers between a packet arriving and your origin being touched, and the ones that matter most are the cheapest ones — the further down the stack a bad request dies, the less it costs you.

This page describes our own machinery in detail and compares availability only. It makes no claim about Cloudflare’s capacity, speed or effectiveness.

Layer inventory

The mitigation layers, and which plan gets them

Read top to bottom: this is the order a request meets them. Availability from each vendor’s public documentation.

Mitigation layerItneticCloudflare
1. Volumetric L3/L4 absorptionIncluded on every plan — upstream backboneEvery plan
2. Packet-level filtering at the driver (XDP)Every plan — protocol identity per flow, SYN capsNot documented per-plan
3. Kernel drop of proven attackersEvery plan — nftables set, zero per-request costNot documented per-plan
4. TLS handshake admission controlEvery plan — per-source connection-rate capNot documented per-plan
5. Adaptive under-attack detectionEvery plan — trips at the edge in under a secondPlan-dependent
6. Proof-of-work challenge (no CAPTCHA)Every plan — two-stage, escalatingEvery plan — Managed Challenge
7. Behavioral signatures (path, header order, TLS)Every planPlan-dependent
Statistical anomaly layer (per-host baseline)Every plan — EWMA z-scorePlan-dependent
Machine-learning request scoringEvery plan — challenge-only, never a blockPlan-dependent (Bot Management)
JA4 TLS fingerprint + cross-fleet reputationEvery plan — challenge-only, opt-inPlan-dependent
Managed OWASP WAF filtersEvery plan, including freePaid plans
Rate limitingEvery planPlan-dependent
Waiting room to cap origin concurrencyEvery plan, including freeBusiness and Enterprise
Real-time attack alertsEvery plan — email and DiscordPlan-dependent
Per-request log with the verdictEvery planRaw log export on Enterprise (Logpush)
Attack traffic billed against your quotaNever — mitigated bytes are excludedNot metered

About this comparison

Compiled from Cloudflare’s own public documentation and plan pages on 10 September 2026, and describing feature availability by plan at that date. Plan contents change — check Cloudflare’s current pages before making a decision. Cloudflare is a trademark of Cloudflare, Inc.; Itnetic Technologies is not affiliated with, endorsed by or sponsored by Cloudflare, Inc. Prices named on this page are Itnetic’s own; this page makes no claim about any other provider’s pricing, performance, capacity or availability.

The cheapest layer that can stop it, stops it

Every defence has a price, paid by us and ultimately by your latency. A packet dropped by the network card driver costs almost nothing. A TLS handshake costs three asymmetric operations and is paid before any request-level logic runs at all — which is why a small node caps out on handshakes long before it caps out on requests. So the design principle is to push every decision as far down as it will go, and only the traffic that survives all of it is allowed to be interesting.

  • An eBPF filter at the driver hook enforces protocol identity per flow and drops floods of ACK, RST and FIN packets that a stateless filter cannot see.
  • Proven attackers are held in a kernel set, so they cost nothing per request thereafter.
  • Per-source connection-rate limits protect the handshake itself, with proven visitors admitted ahead of the cap.

Detection that reacts before anyone tells it to

A control plane round trip is a long time during a flood. Each edge node counts navigations per host itself and flips a domain into challenge mode within a second of a spike, without asking anyone. It then pushes that decision to every other node, so an attacker who is bounced at one point of presence cannot simply re-resolve into another that has not noticed yet. Three separate counters run in parallel — navigations, cookieless navigations, and non-navigation subresource floods — because an API flood and a page flood look nothing alike.

A baseline of your site, not of the internet

Fixed thresholds are the reason protection either misses real attacks or fires at popular sites having a good day. On top of the fixed ceilings runs a statistical layer: an exponentially weighted baseline of each host’s own traffic, which trips when this second’s count is several standard deviations above what that host normally does. The ratio is the point — a large site is never punished for being large, and a small site is not required to absorb a flood that would be background noise elsewhere.

A challenge that costs a visitor nothing and a botnet everything

There is no image grid, no traffic-light puzzle and no third-party verification service. A challenged host starts at a stage where a single invisible redirect is enough — one round trip, and a visitor sees nothing. If our own detector sees that stage being beaten, the host escalates to a proof-of-work solve: cheap once, ruinous at a million requests a second. Escalation holds for a window that doubles on repeat, so a paused-and-resumed attack cannot farm fresh cheap windows.

  • Solving once does not buy immunity forever: an IP that passes and then floods has its solver trust revoked.
  • An in-page recovery script re-solves the challenge in the background and replays failed requests, so a page loaded before an attack does not simply break.
  • Machine clients on declared API paths are never challenged at all — they get rate limits and correct status codes instead.

The bill is the last defence

A quieter kind of damage from an attack is the invoice. Itnetic classifies every response the edge generated in mitigation — challenge pages, redirect hops, rate-limit 429s, WAF blocks — and subtracts those bytes before your bandwidth is metered. A flood cannot spend your allowance, and it cannot push you into an overage or a suspension. Cached hits stay billable, because that is real traffic being served to real people.

What we do not claim

Our points of presence are in Frankfurt, Beauharnois and Singapore, and the volumetric layer upstream of Frankfurt and Beauharnois is a network with 500 Gbps of capacity; Singapore runs on OVHcloud with OVHcloud’s own network-level protection. That is a real number and it is smaller than the largest networks in this industry. If your threat model is a record-breaking terabit flood and you need a contractual guarantee about it, buy from someone who can put that in writing. What we are good at is everything that arrives looking like a visitor.

FAQ

Cloudflare alternatives: common questions

What is the best Cloudflare alternative for DDoS protection?

For Layer-7 attacks — the ones that look like real traffic — the deciding question is whether the detection, challenge, WAF, rate limits and logs are available to you on the plan you are on. On Itnetic all of them are, including on the free plan. For a purely volumetric threat model with contractual capacity guarantees, a large scrubbing provider is the honest answer.

How fast does mitigation kick in?

Under a second. Each edge node has its own detector and does not wait for a control plane, then fans the decision out to the rest of the fleet so every node challenges within push latency rather than waiting to be attacked itself.

Will my visitors see a CAPTCHA?

No. There are no image grids and no third-party verifiers. The first stage is an invisible redirect; if that stage is being beaten, it escalates to a proof-of-work solve that runs in the background and takes a fraction of a second on a real device.

Does DDoS protection cost extra during an attack?

No, in two senses. There is no surge pricing, and mitigated traffic is excluded from your bandwidth quota entirely — challenge pages, blocked requests and rate-limit responses are reported separately and subtracted before metering.

Can it block a legitimate customer by mistake?

Any protection can. The design tries to make being wrong cheap: the machine-learning score and the fingerprint reputation are challenge-only and never block or feed the kernel blocklist, so a false positive costs one background proof-of-work solve rather than an error page. Everything is logged with the rule that fired, so you can see it and fix it.

Do I need to do anything when an attack starts?

No. Detection, escalation and de-escalation are automatic. You get an email and a Discord alert so you know it happened, and the log and analytics show you what it looked like.

Does it protect against volumetric L3/L4 attacks too?

Yes, upstream of the edge, and it is included on every plan. We publish where and at what capacity rather than quoting a headline number, because those two facts are what actually determine whether it applies to you.

Other comparisons

Same method, different provider — feature availability by plan, with the date it was checked.

Try it on one domain.

Two DNS records, no nameserver change, free plan with no card.