This page describes intentional and documented behaviors that result from how our protection systems work. These are not bugs, but inherent trade-offs of effective DDoS protection.
A detailed description of the network modes (Unprotected, Protected, Extra Protected) can be found here: How does the protection work?
Most of the limitations listed here apply **exclusively to the Extra Protected** IP range (`45.146.6.0/24`). For regular **Protected** mode, only what's described in the "Protected mode - sensor operation" section below applies.
Our in-house developed XDP/nftables-based protection operates in sensor mode: filtering rules only take effect during an active attack; by default, traffic passes through without filtering.
The following traffic types may be subject to rate limiting, but only while an attack of the same type is actively occurring. Clean traffic outside an attack window is not subject to any restriction.
| Traffic type | Restriction condition |
|---|---|
| TCP | Only during an active TCP attack |
| UDP | Only during an active UDP attack |
During a DNS-based attack, DNS traffic is only allowed from the following known public resolvers:
| Resolver | Provider |
|---|---|
1.1.1.1, 1.0.0.1 | Cloudflare DNS |
8.8.8.8, 8.8.4.4 | Google Public DNS |
9.9.9.9 | Quad9 |
DNS queries from resolvers not on this list may be dropped. If your application relies on a private or non-standard resolver, name resolution may fail for users behind such resolvers. For your own high-traffic resolver or a specialized DNS service, please coordinate with us in advance.
Under Extra Protection, TCP traffic undergoes authentication: the very first packet of a new TCP session receives a reset, and the client must complete a second handshake to establish the connection. In always-on protection mode, this applies to every new connection.
This behavior is intentional and not a sign of misconfiguration. Standard TCP clients automatically retry, and the impact is typically **under 1 second** - on the client side, it just looks like a brief retry.
Pay particular attention to the following, as the TCP reset can cause issues for them:
**CDN incompatibility:** Cloudflare and other CDN providers typically **do not retry** after a TCP reset. If your traffic arrives via a CDN, always-on protection **will break this path**. This is a known incompatibility. For services behind a CDN, choose dynamic sensor mode, or coordinate with us about a custom profile.
For critical TCP services (without a CDN), however, **always-on Extra Protection** is recommended: if protection only activates during an attack, the route change and TCP authentication can disrupt **existing** connections as well.
The following traffic types may be subject to rate limiting, but only while an attack of the same type is actively occurring. Clean traffic outside an attack window is not subject to any restriction.
| Traffic type | Restriction condition |
|---|---|
| TCP | Only during an active TCP attack |
| UDP | Only during an active UDP attack |
| ICMP | Restricted or blocked during an attack |
| DNS | Restricted to known public resolvers only (see the Protected mode section) |
By default, any UDP port not covered by a dedicated game or application filter is restricted to a per-destination-IP limit. If your service uses a non-standard UDP port or protocol, request a custom filter.
During an attack, ICMP traffic may be rate-limited or blocked. This means that ping / traceroute results cannot be used to draw accurate conclusions about the actual state of the service during an attack, so it's advisable to also use application-level monitoring.
For example, the well-known HetrixTools external monitoring service may report a false outage based on ping.
GRE and other protocols are blocked by default because, without knowing the expected source-destination pairs, they cannot be safely filtered.
Extra Protection operates primarily at the network and transport layers (L3/L4), so it cannot be considered full protection against:
These require application-side protection: rate limiting, CAPTCHA, queuing, login protection, or a custom L7 filter.
**FiveM L7 filter:** available on request, and represents stricter filtering - it caches the public JSON endpoints (`/info.json`, `/players.json`, `/dynamic.json`) for 1 minute (custom modded content is not cached), enforces a strict query limit, and **bans clients that exceed the limit for 8 hours**.
| Limitation | Protected | Extra Protected |
|---|---|---|
| Sensor mode (rules only during an attack) | ✅ | ✅ (in dynamic mode) / ❌ (in always-on mode) |
| Speedtest / intensive applications may stutter during an attack | ✅ | ✅ |
| Double TCP handshake on new connections | ❌ | ✅ (in always-on mode) |
| CDN (Cloudflare) incompatibility | ❌ | ✅ (in always-on mode) |
| ICMP limit/block during an attack | ❌ | ✅ |
| DNS resolver restriction | ✅ | ✅ |
| GRE blocked by default | ❌ | ✅ |
| L7 flood / bot protection | ❌ | ❌ (application-side solution required) |