HTTP 429 Too Many Requests — Reverse Proxy & Gateway Troubleshooting
HTTP 429 Too Many Requests throttles clients that exceed permitted request-per-second (RPS), token-per-minute (TPM), or concurrent connection quotas within a sliding or token-bucket window.
| Status Code | 429 Too Many Requests |
|---|---|
| Specification / Origin | RFC 6585 ยง4 |
| Failure Layer | API Rate Limiter / Edge WAF |
| Retry Safety | Safe for idempotent GET/HEAD with exponential backoff + jitter |
Interactive HTTP 429 Live Probe & Log Command Builder
Enter your target endpoint below to generate copy-ready curl latency breakdown probes and origin bypass tests:
Related diagnostics: Nginx & Caddy Proxy Generator → · X.509 SSL Certificate Decoder → · Offline JWT Expiry Inspector →
Production Root Causes & Remediation Guide
In cloud architectures, unintentional 429 storms often occur when an entire office or Kubernetes cluster shares a single NAT Gateway IP, or when Nginx limit_req_zone hashes $remote_addr instead of $http_x_forwarded_for behind a CDN, lumping all global users into one bucket!
Step-by-Step Engineering Fix
Configure real_ip_header (CF-Connecting-IP / X-Forwarded-For) from trusted proxy CIDRs before applying limit_req_zone, emit standard Retry-After headers, and implement exponential backoff with jitter in API clients.
Recommended Nginx / Reverse-Proxy Configuration Snippet
limit_req_zone $binary_remote_addr zone=api_limit:10m rate=20r/s;
location /api/ {
limit_req zone=api_limit burst=40 nodelay;
limit_req_status 429;
}
Frequently Asked Questions (HTTP 429)
Why did enabling Nginx limit_req behind Cloudflare suddenly return 429 to every visitor?
Without set_real_ip_from and real_ip_header CF-Connecting-IP, Nginx sees Cloudflare's edge IP as $binary_remote_addr and throttles all visitors under one shared quota.
Which infrastructure layer generates HTTP 429 Too Many Requests?
HTTP 429 (RFC 6585 ยง4) typically originates at the API Rate Limiter / Edge WAF layer. HTTP 429 Too Many Requests throttles clients that exceed permitted request-per-second (RPS), token-per-minute (TPM), or concurrent connection quotas within a sliding or token-bucket window.
Should API clients automatically retry HTTP 429 responses?
HTTP 429 is safe to retry ONLY for idempotent methods (such as GET or HEAD) using exponential backoff with random jitter.
Browse All 25 Gateway, Proxy & Cloud HTTP Error Guides
HTTP 400 (Bad Request) HTTP 401 (Unauthorized) HTTP 403 (Forbidden) HTTP 404 (Not Found) HTTP 405 (Method Not Allowed) HTTP 408 (Request Timeout) HTTP 413 (Content Too Large) HTTP 422 (Unprocessable Content) HTTP 429 (Too Many Requests) HTTP 431 (Request Header Fields Too Large) HTTP 499 (Client Closed Request) HTTP 500 (Internal Server Error) HTTP 501 (Not Implemented) HTTP 502 (Bad Gateway) HTTP 503 (Service Unavailable) HTTP 504 (Gateway Timeout) HTTP 507 (Insufficient Storage) HTTP 511 (Network Authentication Required) HTTP 520 (Web Server Returned an Unknown Error) HTTP 521 (Web Server Is Down) HTTP 522 (Connection Timed Out) HTTP 523 (Origin Is Unreachable) HTTP 524 (A Timeout Occurred) HTTP 525 (SSL Handshake Failed) HTTP 526 (Invalid SSL Certificate)