Rate Limits

Rate limits cap how many requests each visitor can send to some of your paths within a time window. Sokol Edge agents enforce them locally, before the firewall runs, so floods of login attempts or scraping requests cost almost nothing to refuse.

Creating a limit

Open Edge › Rate limits in the console and choose Add rate limit. Start from a preset and adjust it:

  • Login protection: 10 POST requests per minute to /login, then a 429.
  • API burst: 300 requests per minute below /api, with a burst of 50.
  • Expensive search: 30 GET requests per minute to /search*, then a challenge.

While you edit, the drawer shows which sample paths and which of your busiest recent paths the rule would count, and a one-sentence summary such as “Each visitor can make 10 POST requests per minute to /login; extra requests get a 429.”

Matching requests

  • Exact path: /login matches only /login.
  • Path and below: /api matches /api and /api/…, but not /apiary.
  • Pattern: * matches any characters including /, the same syntax as challenge path patterns. /api/*/export matches /api/v1/users/export.

Paths never include the query string. Optionally restrict a rule to some HTTP methods or to one resource. Up to 16 paths per rule and 100 rules per site.

How counting works

Each rule is a token bucket: a visitor may send requests + burst requests at once, after which one request becomes available every window ÷ requests. Windows range from one second to one hour. Rejected requests do not use up tokens, so a visitor that waits is admitted again.

By default one visitor is one IPv4 address, or one IPv6 /64 network (so rotating IPv6 addresses do not reset the count). Both prefix lengths are configurable. With Verified browser keying, browsers that passed a Sokol challenge are counted by their trust cookie, so visitors behind the same NAT gateway do not share a limit; everyone else falls back to their address.

When a visitor goes over the limit

  • Slow down (429): the request is answered with 429 Too Many Requests and a Retry-After header.
  • Challenge: top-level page loads get a proof-of-work challenge. API calls, background requests and visitors that already passed a challenge get a 429 instead.
  • Block for a while: every request from the visitor that matches the rule is refused with 403 for the cooldown, with Retry-After set to the time remaining.

Exemptions and precedence

  • Networks listed under Never limit these networks are not counted.
  • Visitors that passed a challenge are skipped unless you turn that off.
  • An Always allow access rule skips rate limits entirely; block and challenge access rules apply first.
  • When several rules match, higher priority rules are checked first and the first rule a request exceeds decides the response.
Limits are per edge agent. Agents do not share counters. If several agents serve your site behind a load balancer, a visitor can reach a limit once on each agent: with three agents, a 10-per-minute limit admits up to 30 requests per minute in the worst case. Set limits with that in mind, or route a visitor consistently to one agent.

Monitoring

The Hits (24h) column counts every rejected request per rule. The first rejection of each burst also appears in Edge › Events; select the hit count to see them.