--- title: "Rate limiting" url: https://proxy.wiki/glossary/rate-limiting/ type: Glossary Term author: "proxy.wiki editorial" published: 2026-08-19 updated: 2026-08-29 site: proxy.wiki topics: ["Web scraping"] license: CC BY 4.0 — quote freely with attribution to https://proxy.wiki/ --- # Rate limiting > Capping how many requests a client may make in a period. The 429 status code is defined in RFC 6585. **Rate limiting restricts how many requests a client may make within a time window.** It protects infrastructure and is applied by nearly every substantial service. ## The 429 status code **429 Too Many Requests** indicates you have exceeded a limit. A well-behaved server includes a `Retry-After` header saying when to try again — either in seconds or as a date. ``` HTTP/1.1 429 Too Many Requests Retry-After: 30 ``` ## Reading it correctly A 429 usually means your rate is wrong, not your proxy. Rotating to a new address and continuing at the same speed treats the symptom, consumes [pool](/glossary/proxy-pool/) reputation, and often produces a harder block. Honour `Retry-After` when it is present. ## Backoff that works Exponential backoff with jitter. Without jitter, parallel workers that fail together retry together and recreate the burst that caused the limit. Cap the maximum delay and cap the retry count — an uncapped retry loop is an outage generator. ## Reference 429 is specified in [RFC 6585, section 4](https://www.rfc-editor.org/rfc/rfc6585.html#section-4). ## Reading the response correctly RFC 6585 defines 429 and states that the response may carry `Retry-After`. When it does, the value is an instruction, not a hint. Ignoring it is the fastest way to convert a temporary limit into a durable block. | Header | Meaning | | --- | --- | | Retry-After | Seconds to wait, or an HTTP date. Defined in RFC 9110 | | X-RateLimit-Limit | Convention, not a standard. The ceiling for the window | | X-RateLimit-Remaining | Convention. Requests left in the window | | X-RateLimit-Reset | Convention. When the window restarts | Only the first row is standardised. The others are widely used conventions with no agreed format, so read them defensively and never require them to be present. ## Backoff that works ``` delay = base * (2 ** attempt) # exponential delay = delay * (0.5 + random()) # jitter, so retries do not synchronise sleep(min(delay, ceiling)) # bounded, so it cannot grow forever ``` All three parts matter. Exponential growth gives the limit time to clear. Jitter stops parallel workers retrying in lockstep and recreating the burst. A ceiling stops a long outage producing an unbounded wait. Rotating an address to escape a limit is a fragile answer. If the limit is applied per account or per session, the new address changes nothing, and the burst simply moves. See [the status-code guide](/guides/403-vs-407-vs-429/). ## Frequently asked questions ### What is the difference between 429 and 403? A 429 says you asked too often and implies that waiting will help. A 403 says the request is refused as it stands, and repeating it unchanged will not succeed. Treat the first with backoff and the second with a change of approach. ### Should I honour Retry-After? Yes. It is standardised in RFC 9110 and it tells you exactly how long to wait. Ignoring it and retrying sooner is the most reliable way to turn a temporary limit into a lasting block. ### Can I avoid rate limits by rotating addresses? Only if the limit is applied per address. Limits applied per account, per session or per credential follow you across addresses, so the burst simply reappears from somewhere else. ## Sources 1. [RFC 6585: status code 429, Too Many Requests](https://www.rfc-editor.org/rfc/rfc6585.html) 2. [RFC 9110: HTTP Semantics, the Retry-After header](https://www.rfc-editor.org/rfc/rfc9110.html)