CC protection: counting and statistics
How nodes count for CC rules: fixed window and leaky bucket, per-node and per-tenant counters, failure behaviour, and what the statistics page counts.
How it works
Each request is checked against the site's CC rules in order. A rule whose conditions hold counts the request by its counting object (client IP, network, URI, JA4 and so on); above the threshold it takes its action: log only, answer 429, ban temporarily or verify.
Decision rules
| Item | Rule | Range |
|---|---|---|
| Fixed window | Time is cut into fixed segments of the window length (aligned to absolute time); the (N+1)-th request in a segment exceeds the limit, and the next segment starts from zero | Window 1–3600 s, 1–1,000,000 requests |
| Leaky bucket | The bucket holds the burst size and refills at the per-second rate; a request finding it empty exceeds the limit and does not enter it | Rate and burst 1–1,000,000 |
| Verification | Fixed window only; above the limit the visitor gets a verification page, and after passing is not asked again for the pass duration | Pass duration 60 s–7 days |
| Temporary ban | During the ban every request of the counting object gets 429 with Retry-After; a ban by client IP is also applied in the node's kernel firewall | 1–86,400 s |
| Counting scope | Each node counts on its own, nodes never add up their counts; on one node, counters, bans and passes of different tenants never mix | — |
| Counter failure | When the node's counter memory is full, an entry is forcibly evicted or a lock times out: log-only rules let the request through and log an error, rules with other actions answer 503 | — |
Why counting is per node
Counting locally means no network round trip per decision, and nodes keep working when the control plane is unreachable. The cost: when one source spreads its requests over K nodes, each node lets the threshold through, so up to about K times the threshold passes.
For tighter overall control:
- use attack auto-escalation or line scheduling to concentrate an attacked site on fewer nodes;
- turn on automatic defense, which learns each site's normal traffic instead of relying on a fixed threshold;
- a temporary ban by client IP also goes into the node's kernel firewall, so that IP's connections to the node are dropped during the ban.
Insight and logs
Nodes report the Statistics tab of CC rules every 10 seconds, counted per rule:
| Field | Meaning |
|---|---|
| Matched | The request met the rule's conditions and was counted |
| Triggered | The count exceeded the threshold, or the counting object was already banned |
| Challenged | Triggered, and a verification page was returned |
| Blocked | Triggered, and 429 or a ban page was returned |
| Passed | Under a verification rule, the visitor had a valid pass or just passed |
| No TLS fingerprint | The rule counts by JA4 but the request has none (plain HTTP, HTTP/3), so it was not counted |
Triggered = challenged + blocked + the overruns of log-only rules. "Top triggering client IPs / paths" count triggers only. Temporary bans go into the site's block log; 429 and verification page records are merged per minute into one line with a count.
Common questions
The threshold is 100 but far more get through
Check how many nodes the requests reach: each node counts on its own, so the total is about the node count times the threshold. A fixed window can let the threshold through on both sides of a segment boundary, so up to about twice in a short time.
Many matches but no triggers
The conditions match, but no counting object exceeds the threshold. Observe with log only for a while, then tune the threshold by the top triggering clients.
Ordinary visitors suddenly get 503
Look for CC counter state failures in the node's error log. When counter memory runs out, rules other than log only refuse requests so a failure never lets an attack through; ask your administrator to give the node more memory or to reduce high-cardinality counting objects.