429 Too Many Requests: What It Means and How to Fix It

Applies to: websites and APIs on any web server; server examples tested with Nginx 1.31.6

429 Too Many Requests means that the server, or a service in front of it such as a firewall, CDN or API gateway, is limiting how many requests one client may send in a period of time, and you went over that limit. It is defined in RFC 6585. The response may include a Retry-After header that says how many seconds to wait.

If you see it as a visitor

• Wait a minute and try again. Refreshing again and again makes it worse, because every refresh counts as a request.
• If you are on a VPN, a company network or public Wi-Fi, many people may share your IP address; try another connection.
• If a program or script shows the error, it is sending requests too fast; slow it down (see below).

If it is your website: find what is limiting

First see who answers, and whether a wait time is given:

curl -sI https://example.com/ | grep -iE "^HTTP|^retry-after|^server"

• A CDN or firewall, such as a Cloudflare rate-limiting rule (the header shows server: cloudflare). Adjust or relax the rule there.
• A WordPress security or login-protection plugin that limits login attempts or requests per IP.
• The web server itself, for example Nginx rate limiting or Apache mod_evasive (configure mod_evasive).
• An API your site calls (payment gateway, maps, mail service) that returns 429 to your server. Your application log shows this.

Nginx rate limiting (and why you may see 503 instead)

limit_req_zone $binary_remote_addr zone=perip:10m rate=5r/s;

server {
    location /api/ {
        limit_req zone=perip burst=20 nodelay;
        limit_req_status 429;
        # ... your proxy_pass or fastcgi settings
    }
}

In our test with a limit of 1 request per second, four quick requests returned 200 429 429 429. Without limit_req_status 429; the same requests returned 200 503 503 503: Nginx uses 503 by default. Rejected requests are logged in the error log as limiting requests, excess: ... by zone "perip". Nginx does not add a Retry-After header on its own.

Fix it without opening the door to abuse

1. Check the logs to see whether the blocked requests are real visitors or bots.
2. For real traffic, raise the rate or the burst value, and exclude your own office IP, monitoring and payment-gateway callbacks.
3. For bots, keep the limit and block the worst sources.
4. Cache pages so fewer requests reach PHP; the same visitors then use far fewer “expensive” requests.

If your code calls an API

• Read Retry-After and wait that long before retrying.
• Retry with increasing pauses (1, 2, 4, 8 seconds) instead of immediately.
• Cache answers you need often and send requests in batches where the API allows it.

Behind Cloudflare: enable Cloudflare on your website. Need help finding the source? Hire an expert.

Official documentation: RFC 6585 (429 Too Many Requests).