PacketStreamRate Limiting
Rate limiting controls how many requests a client may make within a defined period or under a shared quota. A service can count requests by IP address, account, API key, session, route, or a combination of identifiers.
Common algorithms use fixed windows, sliding windows, leaky buckets, or token buckets to decide when capacity is available. When an HTTP service refuses a request because of a limit, it commonly returns status 429 Too Many Requests. A Retry-After header may state when to try again, though not every service supplies one. Some systems delay responses, require a challenge, or temporarily block an address instead.
A client should treat the limit as a signal to reduce pressure. Honor Retry-After when present, use exponential backoff with jitter, cap retries, and lower concurrency. Immediate retries from a new IP can turn a temporary quota response into broader blocking, particularly when the service also identifies an account or browser session.
For concrete recovery patterns, see how to fix Cloudflare error 1015 and reliable proxy retries, backoff, and session recovery.