Cloudflare's per-IP counter hands a whole carrier NAT pool one shared budget

A Rate Limiting Rule has two parts: a matching expression that picks which requests the rule applies to, and a list of characteristics that defines the counting key ^[7]. Key on ip.src alone and every request from that address increments one number. Twenty requests per ten seconds is two requests a second ^[1]. Everyone the carrier put behind that address shares those two requests a second.

Read "several hundred players" as three hundred, each sending one join call inside the window. The counter reads 300 against a budget of 20, fifteen times the limit ^[2]. None of that traffic is abusive, and the rule has no field that would show it. Cloudflare answers with a 429 or a challenge, and an entire region's worth of legitimate players gets treated as one abusive client ^[4]. The post says support tickets "can pile up faster than the on-call engineer can read Cloudflare's analytics dashboard" ^[5].

The characteristic that fixes this is gated by plan. Free and Pro count by IP only. Business adds the "IP with NAT support" characteristic. Counting by request header, cookie or query value requires Enterprise with Advanced Rate Limiting ^[6]. The replacement rule the post publishes counts on cf.colo.id, ip.src and http.request.headers["x-player-session"] ^[10], so it deploys only on Enterprise ^[4].

Check which address Cloudflare sees before writing any threshold ^[9]. It counts the client IP as seen at its own edge ^[8]. A load balancer at your origin, behind Cloudflare, changes nothing about the count. A proxy, a VPN or another CDN in front of Cloudflare replaces the client address with that hop's egress address, and every player behind it becomes one counted entity ^[8].

The published threshold is 15 requests per 10 seconds, which is 1.5 a second for each key ^[3] and 25 percent below the per-key allowance in the rule it replaces ^[5]. That number holds only if the client attaches the session header to every call on the matched path, one value per player, with no retry loop that exceeds a call and a half a second. The header is client-generated ^[12], so a caller who rotates it mints a fresh counter on each rotation. Keeping ip.src in the key does not bound that, because a new header value is a new key.

Game servers are a common DDoS target and an unprotected matchmaking endpoint is a real risk, the post says ^[13]. What it proposes is verification: Logpush or the Security Events view, so rule impact is checked against real traffic and not guesses ^[14], and on Enterprise a deployment with the Log action before the switch to Block ^[15]. The write-up is a configuration walkthrough and does not report traffic figures from a named outage ^[16]. It describes the shared-IP lockout as "a well-known failure mode, not a rare edge case" ^[17].