{"id":87,"date":"2026-07-18T00:00:00","date_gmt":"2026-07-18T00:00:00","guid":{"rendered":"http:\/\/\/var\/www\/html\/?p=87"},"modified":"2026-07-19T16:42:00","modified_gmt":"2026-07-19T16:42:00","slug":"nginx-rate-limit-exceeded-redirecting-requests-status-503-on-ubuntu-2004-lts","status":"publish","type":"post","link":"https:\/\/staging.butitworkedlocal.com\/?p=87","title":{"rendered":"Troubleshooting Nginx 503 Service Unavailable Due to Rate Limit Exceeded on Ubuntu 20.04 LTS"},"content":{"rendered":"\n

Resolve Nginx 503 errors caused by rate limiting. Learn to diagnose, adjust limit_req_zone, and optimize Nginx configuration on Ubuntu 20.04 LTS.<\/strong><\/p>\n\n\n

When your Nginx web server starts returning HTTP 503 Service Unavailable<\/code> errors, especially during periods of high traffic or suspicious activity, it often indicates that Nginx's built-in rate limiting mechanism has been triggered. This guide delves into diagnosing and resolving "Nginx rate limit exceeded" issues, specifically on Ubuntu 20.04 LTS, ensuring your services remain available and performant under load.<\/p>\n\n

Symptom & Error Signature<\/h3>\n\n

Users attempting to access your web application will receive an HTTP 503 Service Unavailable<\/code> response. The browser might display a generic Nginx 503 page or your custom error page, stating that the service is temporarily unavailable.<\/p>\n\n

Upon inspecting Nginx access logs (typically \/var\/log\/nginx\/access.log<\/code>), you will observe numerous entries with a 503<\/code> status code for affected requests:<\/p>\n\n

192.168.1.1 - - [18\/Jul\/2026:10:30:05 +0000] "GET \/api\/data HTTP\/1.1" 503 197 "-" "Mozilla\/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit\/537.36 (KHTML, like Gecko) Chrome\/100.0.4896.75 Safari\/537.36"\n192.168.1.2 - - [18\/Jul\/2026:10:30:06 +0000] "POST \/submit HTTP\/1.1" 503 197 "-" "User-Agent: MyBot\/1.0"<\/code><\/pre>\n\n
Crucially, the Nginx error log (typically \/var\/log\/nginx\/error.log<\/code>) will contain specific messages indicating rate limiting:<\/p>\n\n
2026\/07\/18 10:30:05 [error] 12345#12345: *67890 limiting requests, excess: 5.000 by zone "api_rate_limit", client: 192.168.1.1, server: example.com, request: "GET \/api\/data HTTP\/1.1", host: "example.com"\n2026\/07\/18 10:30:06 [error] 12346#12346: *67891 limiting requests, excess: 3.500 by zone "api_rate_limit", client: 192.168.1.2, server: example.com, request: "POST \/submit HTTP\/1.1", host: "example.com", referrer: "http:\/\/example.com\/"<\/code><\/pre>\n\n
The key phrase here is limiting requests, excess: X.XXX by zone "yourzone<\/em>name"<\/code>, which confirms that the Nginx limit_req<\/code> module is actively rejecting or delaying requests.<\/p>\n\n
Root Cause Analysis<\/h3>\n\n
The HTTP 503 Service Unavailable<\/code> status, accompanied by "limiting requests" messages in the error log, directly points to Nginx's limit_req<\/code> module. This module is designed to control the rate of requests for specific keys (typically client IP addresses) and is configured using two primary directives:<\/p>\n\n
  1.  limitreq<\/em>zone<\/code><\/strong>: Defined in the http<\/code> context, this directive creates a shared memory zone to store request states. It specifies:<\/li>
  2.     *   Key<\/strong>: The variable to track (e.g., $binaryremote<\/em>addr<\/code> for client IP).<\/li>
  3.     *   Zone Name & Size<\/strong>: A unique name for the zone and its memory allocation (e.g., zone=apirate<\/em>limit:10m<\/code>).<\/li>
  4.     *   Rate<\/strong>: The maximum average request rate allowed (e.g., rate=5r\/s<\/code> for 5 requests per second, or rate=300r\/m<\/code> for 300 requests per minute).<\/li>
  5.  limitreq<\/code><\/strong>: Applied within http<\/code>, server<\/code>, or location<\/code> contexts, this directive references a limit<\/em>req_zone<\/code> and specifies:<\/li>
  6.     *   Zone Name<\/strong>: Which shared memory zone to use.<\/li>
  7.     *   Burst<\/strong>: How many requests a client can make in excess of the defined rate without being immediately rejected. These excess requests are queued and processed with a delay.<\/li>
  8.        Nodelay<\/strong>: An optional parameter that, if present, tells Nginx to process requests without delay once the burst limit is reached, potentially leading to server overload but avoiding client delays. If nodelay<\/code> is <\/em>not* used, requests exceeding the rate but within the burst limit are delayed. If burst<\/code> itself is exceeded (or nodelay<\/code> is present and the rate is exceeded), Nginx returns a 503 (or 500 depending on limitreq<\/em>status<\/code>).<\/li><\/ol>\n\n
    Common Scenarios Leading to Rate Limit Exceedance:<\/strong><\/p>\n\n
    •   Legitimate High Traffic:<\/strong> A sudden surge in user activity, viral content, or successful marketing campaigns can push legitimate traffic beyond the configured limits.<\/li>
    •   Malicious Activity\/DDoS:<\/strong> Bots, scrapers, or Distributed Denial of Service (DDoS) attacks can generate an extremely high volume of requests, intentionally triggering rate limits.<\/li>
    •   Misconfigured Clients\/Scripts:<\/strong> Automated scripts, monitoring tools, or even poorly implemented AJAX calls can make excessive requests, especially if there's a bug causing a loop.<\/li>
    •   Overly Aggressive Configuration:<\/strong> The limitreq<\/em>zone<\/code> and limit_req<\/code> parameters might be set too low for the actual expected traffic patterns of your application.<\/li><\/ul>\n\n
      Step-by-Step Resolution<\/h3>\n\n
      1. Identify the Active Nginx Rate Limit Configuration<\/h4>\n\n
      Your first step is to locate where limitreq<\/em>zone<\/code> and limit_req<\/code> are defined in your Nginx configuration. Nginx configurations on Ubuntu 20.04 LTS are typically found in \/etc\/nginx\/nginx.conf<\/code> and files included from conf.d<\/code> or sites-enabled<\/code>.<\/p>\n\n
      # Search for limit_req_zone and limit_req directives across Nginx configuration files\ngrep -R "limit_req_zone" \/etc\/nginx\/\ngrep -R "limit_req" \/etc\/nginx\/<\/code><\/pre>\n\n
      You'll likely find something similar to this structure:<\/p>\n\n
      \/etc\/nginx\/nginx.conf<\/code> (or an included file like \/etc\/nginx\/conf.d\/ratelimit.conf<\/code>):<\/strong><\/p>\n\n
      http {\n    # ... other http settings ...\n    # Defines a 10MB zone named 'api_rate_limit' tracking client IPs, allowing 5 requests\/second\n    limit_req_zone $binary_remote_addr zone=api_rate_limit:10m rate=5r\/s;\n    # ...\n}<\/code><\/pre>\n\n
      \/etc\/nginx\/sites-enabled\/your_site.conf<\/code> (or within a location block inside a server config):<\/strong><\/p>\n\n
      server {\n    listen 80;<\/code><\/pre>\n\n
      location \/api\/ {\n        # Applies the 'apirate<\/em>limit' zone, allowing a burst of 10 requests, with no delay\n        limitreq zone=api<\/em>rate_limit burst=10 nodelay;\n        # … proxy_pass or root directives …\n    }<\/p>\n\n
      location \/admin\/ {\n        # Potentially a different limit for admin panel\n        limitreq zone=api<\/em>rate_limit burst=5 nodelay; \n        # …\n    }\n}\n<\/code>`<\/p>\n\n
      [!IMPORTANT]\nNote the zone=<\/code> name (e.g., apirate<\/em>limit<\/code>). This name is crucial as it links the limitreq<\/em>zone<\/code> definition (where the rate and zone size are set) to the limit_req<\/code> application (where burst and nodelay are set).<\/p><\/blockquote>\n\n
      2. Analyze Nginx Error Logs for Specifics<\/h4>\n\n
      Re-examine \/var\/log\/nginx\/error.log<\/code> for recent limiting requests<\/code> messages. This will confirm the specific zone being hit, the client IP addresses that are exceeding the limit, and the excess<\/code> value.<\/p>\n\n
      sudo tail -f \/var\/log\/nginx\/error.log | grep "limiting requests"<\/code><\/pre>\n\n
      Look for the excess: X.XXX<\/code> value. A high excess<\/code> value indicates that requests are coming in much faster than the configured rate and burst limits. This helps you understand the magnitude of the problem.<\/p>\n\n
      3. Adjust limitreq<\/em>zone<\/code> Parameters (Rate and Burst)<\/h4>\n\n
      This is the most common and direct resolution: increasing the allowed request rate or burst capacity to accommodate legitimate traffic.<\/p>\n\n
      Edit the Nginx configuration file where your limitreq<\/em>zone<\/code> is defined (e.g., \/etc\/nginx\/nginx.conf<\/code> or a custom .conf<\/code> in conf.d<\/code>).<\/p>\n\n
      sudo nano \/etc\/nginx\/nginx.conf<\/code><\/pre>\n\n
      Understanding the Parameters to Adjust:<\/strong><\/p>\n\n
      •   rate<\/code><\/strong>: Defines the average request processing rate Nginx attempts to maintain.<\/li>
      •   *   rate=5r\/s<\/code>: Allows 5 requests per second.<\/li>
      •   *   rate=300r\/m<\/code>: Allows 300 requests per minute (equivalent to 5r\/s).<\/li>
      •   *   Recommendation:<\/strong> If you suspect legitimate traffic is being blocked, consider increasing the rate. A good starting point is to double the current rate (e.g., from 5r\/s<\/code> to 10r\/s<\/code>) and monitor.<\/li>
      •   burst<\/code><\/strong>: Specifies how many requests a client can send in excess<\/em> of the defined rate<\/code> before Nginx returns a 503. These excess requests are put into a queue and processed as capacity becomes available.<\/li>
      •   *   burst=10<\/code>: Allows 10 requests to be queued.<\/li>
      •   *   Recommendation:<\/strong> Increase this value to accommodate momentary spikes in traffic. A higher burst<\/code> allows more flexibility and reduces 503 errors during brief peaks but consumes more shared memory for the queue.<\/li>
      •   zone<\/code> size<\/strong>: The memory allocated for the shared memory zone (e.g., zone=apirate<\/em>limit:10m<\/code>). Each state for an IP address takes about 32 bytes. 10m<\/code> can store ~320,000 active IP addresses. If you significantly increase the burst or expect many unique IPs, you might need to increase the zone size.<\/li><\/ul>\n\n
        Example Modification:<\/strong><\/p>\n\n
        Original (potentially too restrictive):<\/p>\n\n
        # In http block:<\/code><\/pre>\n\n
        In server\/location:\nlimitreq zone=api<\/em>rate_limit burst=10 nodelay; \n<\/code>`<\/h1>\n\n
        Modified (more permissive):<\/p>\n\n
        # In http block:\n# Increased rate to 10 requests\/sec and zone size to 20MB<\/code><\/pre>\n\n
        In server\/location:\n# Increased burst to 20 requests\nlimitreq zone=api<\/em>rate_limit burst=20 nodelay; \n<\/code>`<\/h1>\n\n
        [!WARNING]\nIncreasing rate<\/code> and burst<\/code> too aggressively without understanding your server's underlying capacity (CPU, memory, backend application limits) can lead to backend overload and system instability. Always monitor server resource usage after making changes.<\/p><\/blockquote>\n\n
        4. Consider Whitelisting Specific IPs<\/h4>\n\n
        If you have specific IP addresses (e.g., your own monitoring systems, trusted partners, or internal tools) that legitimately need to make high volumes of requests without being rate-limited, you can whitelist them using the geo<\/code> or map<\/code> directives.<\/p>\n\n
        Using geo<\/code> directive (in http<\/code> block):<\/strong><\/p>\n\n
        http {\n    # ...\n    # Define a variable '$whitelist' that is 0 for whitelisted IPs, and 1 for others\n    geo $whitelist {\n        default 1;           # By default, enable rate limiting\n        127.0.0.1 0;         # Whitelist localhost\n        192.168.1.0\/24 0;    # Whitelist a subnet (e.g., internal network)\n        203.0.113.10 0;      # Whitelist a specific public IP<\/code><\/pre>\n\n
        Now, define your rate limit zone, potentially referencing the whitelist variable\n    limitreq<\/em>zone $binaryremote<\/em>addr zone=apirate<\/em>limit:10m rate=5r\/s;\n}\n<\/code>`<\/h1>\n\n
        Then, in your server<\/code> or location<\/code> block, apply the limit_req<\/code> only if the client is not whitelisted:<\/p>\n\n
        server {\n    # ...\n    location \/api\/ {\n        if ($whitelist = 1) { # Only apply rate limit if client is not whitelisted\n            limit_req zone=api_rate_limit burst=10 nodelay;\n        }\n        # ... Other directives for \/api\/\n    }\n}<\/code><\/pre>\n\n
        5. Test Nginx Configuration and Reload<\/h4>\n\n
        After making any changes to Nginx configuration files, it is critical<\/strong> to test the syntax before reloading. This prevents Nginx from failing to start due to misconfigurations.<\/p>\n\n
        sudo nginx -t<\/code><\/pre>\n\n
        If the test is successful, you'll see messages like:<\/p>\n\n
        nginx: the configuration file \/etc\/nginx\/nginx.conf syntax is ok\nnginx: configuration file \/etc\/nginx\/nginx.conf test is successful<\/code><\/pre>\n\n
        Then, reload Nginx to apply the changes gracefully:<\/p>\n\n
        sudo systemctl reload nginx<\/code><\/pre>\n\n
        [!IMPORTANT]\nAlways use sudo systemctl reload nginx<\/code> instead of sudo systemctl restart nginx<\/code> in production environments. reload<\/code> allows Nginx to gracefully shut down old worker processes and start new ones with the updated configuration, minimizing downtime by keeping existing connections active during the transition.<\/p><\/blockquote>\n\n
        6. Monitor and Iterate<\/h4>\n\n
        After applying the changes, it's crucial to continuously monitor your Nginx error logs, access logs, and overall server resource utilization.<\/p>\n\n
        •   Check error.log<\/code><\/strong>: Ensure limiting requests<\/code> messages have significantly reduced or disappeared for legitimate traffic patterns.<\/li>
        •   Check access.log<\/code><\/strong>: Verify that 503<\/code> responses are no longer being served by Nginx for requests that should be allowed.<\/li>
        •   System Monitoring<\/strong>: Use tools like htop<\/code>, netdata<\/code>, atop<\/code>, or integrated solutions like Prometheus\/Grafana<\/code> to observe CPU, memory, network I\/O, and active connection counts. If these resources spike dangerously after increasing limits, your backend application or database might be the actual bottleneck, not just Nginx's rate limit.<\/li><\/ul>\n\n
          You may need to iterate on these changes, gradually adjusting rate<\/code> and burst<\/code> until you find a balanced configuration that protects your server resources while allowing legitimate traffic to flow freely.<\/p>\n\n
          7. Consider External Solutions (Advanced)<\/h4>\n\n
          For high-volume websites or those frequently targeted by sophisticated DDoS attacks, Nginx's built-in rate limiting might not be sufficient on its own. Consider implementing additional layers of protection:<\/p>\n\n
          •   Content Delivery Networks (CDNs) with WAF<\/strong>: Services like Cloudflare, Akamai, or AWS CloudFront with Web Application Firewall (WAF) capabilities can absorb and filter malicious traffic and bot requests before they ever reach your Nginx server, significantly reducing the load.<\/li>
          •   Dedicated Web Application Firewalls (WAFs)<\/strong>: Standalone or cloud-based WAFs can provide more sophisticated rule sets, behavioral analysis, and threat intelligence for advanced attack detection and mitigation.<\/li>
          •   Fail2Ban<\/strong>: While Nginx rate limiting deals with requests per second, Fail2Ban can be configured to parse Nginx logs and automatically ban (at the firewall level) IP addresses that repeatedly trigger rate limit errors or other suspicious activities, effectively blocking persistent attackers.<\/li><\/ul>\n\n
            By carefully diagnosing the cause and making informed adjustments to your Nginx rate limiting configuration, you can effectively manage traffic spikes and protect your web services from overload on Ubuntu 20.04 LTS.<\/p>","protected":false},"excerpt":{"rendered":"
            Resolve Nginx 503 errors caused by rate limiting. Learn to diagnose, adjust limit_req_zone, and optimize Nginx configuration on Ubuntu 20.04 LTS.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[223,40,55,91,34,18],"class_list":["post-87","post","type-post","status-publish","format-standard","hentry","category-web-server","tag-503-error","tag-devops","tag-nginx","tag-rate-limit","tag-sysadmin","tag-ubuntu-20-04"],"_links":{"self":[{"href":"https:\/\/staging.butitworkedlocal.com\/index.php?rest_route=\/wp\/v2\/posts\/87","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/staging.butitworkedlocal.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/staging.butitworkedlocal.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/staging.butitworkedlocal.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/staging.butitworkedlocal.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=87"}],"version-history":[{"count":1,"href":"https:\/\/staging.butitworkedlocal.com\/index.php?rest_route=\/wp\/v2\/posts\/87\/revisions"}],"predecessor-version":[{"id":206,"href":"https:\/\/staging.butitworkedlocal.com\/index.php?rest_route=\/wp\/v2\/posts\/87\/revisions\/206"}],"wp:attachment":[{"href":"https:\/\/staging.butitworkedlocal.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=87"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/staging.butitworkedlocal.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=87"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/staging.butitworkedlocal.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=87"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}