Rate limiting and IP reputation
Scope rate counters, preserve client identity, stage enforcement, and diagnose false positives.
Rate limits constrain matching traffic at the protected edge. IP reputation adds intelligence context to a request; it does not replace application authentication or user-level authorization.
Configure a rule
Open Network protection → Policies → Edge policy → Rate limits → Add rule. Select services, HTTP match conditions, counter key, window, request threshold, and monitor or block mode. Supported windows are 1, 10, or 60 seconds; the threshold is an integer from 1 through 1000000 requests per window. Invalid values reject publication rather than being rounded.
Counter keys are client IP or a configured application key derived from a trusted edge-validated field. Do not accept an arbitrary client-supplied header as proof of identity. Configure trusted upstream proxies at Service → Client identity; otherwise the socket peer is the client. NAT can place many legitimate users in one IP counter.
A counter belongs to its service and rule revision. A published rule change can begin a new counter interval. Distributed edge enforcement can admit in-flight requests; a threshold is a protection control, not an exact accounting or spending cap. For request quotas requiring transactional precision, enforce a quota in the application.
Reputation and ordering
At Edge policy → Reputation, select the source, confidence threshold, action, and expiry handling. Explicit scoped exceptions are evaluated before the affected reputation or rate rule; they do not skip unrelated WAF rules unless those rules are explicitly included. Broad IP allows can cover compromised clients on the same network.
Publish in monitor mode, inspect Service → Traffic → Rule matches, then enable blocking after comparing expected client behavior. A blocked HTTP request receives 429 for a rate limit; reputation rejection is recorded separately. Network-layer drops do not produce an HTTP response.
Resolve a false positive
Find the rule ID, observed client identity, request path, counter key, and applied revision in the event. Correct proxy trust or overly broad match conditions first. If a temporary exception is needed, use Policy → Exceptions → Create with the affected service and expiry. Verify the new revision at the edge and test a normal transaction. See WAF controls for application-rule handling.