https://www.netdata.cloud/tags/http-status-codes/Recent content in HTTP Status Codes on NetdataHugoen-usSat, 22 Aug 2026 05:09:03 +0300https://www.netdata.cloud/academy/hidden-500-ngnix-series-errors/Sat, 16 Aug 2025 00:00:00 +0000https://www.netdata.cloud/academy/hidden-500-ngnix-series-errors/<p>Your NGINX instance is humming along, handling traffic flawlessly. Then, a sudden traffic spike or a deployment of a new feature that handles larger files occurs, and your monitoring dashboards light up with 500-series errors. You check the NGINX error logs, but find nothing conclusive—just generic <code>502 Bad Gateway</code> or <code>504 Gateway Timeout</code> messages that don&rsquo;t point to a root cause. These are the hidden, frustrating errors that often stem not from your application code, but from poorly tuned NGINX buffering and <code>keepalive</code> settings.</p>https://www.netdata.cloud/academy/how-to-fix-nginx-500-internal-server-error-simple-steps-for-troubleshooting/Thu, 31 Oct 2024 00:00:00 +0000https://www.netdata.cloud/academy/how-to-fix-nginx-500-internal-server-error-simple-steps-for-troubleshooting/<p>When managing a website or web application through NGINX, it&rsquo;s quite likely you&rsquo;ve stumbled upon the feared 500 Internal Server Error at least once. This error often causes a moment of panic as it typically indicates a problem lurking within the server&rsquo;s operations. Regrettably, one finds that the message falls short in offering sufficient context to aid in uncovering the underlying reason.</p> <p>No need to fret! This guide is here to take you step by step through the usual culprits behind a 500 error when using NGINX and, even better, how to solve it. If you&rsquo;re facing a problem like not having the right permissions, a setup mistake, or something different, don&rsquo;t worry—we have all the steps you need to fix it.</p>https://www.netdata.cloud/academy/how-to-diagnose-and-fix-504-gateway-timeout-errors-in-nginx/Mon, 27 May 2024 00:00:00 +0000https://www.netdata.cloud/academy/how-to-diagnose-and-fix-504-gateway-timeout-errors-in-nginx/<p>Encountering a &lsquo;504 Gateway Timeout&rsquo; error in Nginx can be frustrating, especially when it disrupts the availability of your web applications. This error indicates that the server, while acting as a gateway or proxy, did not receive a timely response from the upstream server. This guide will help DevOps and Site Reliability Engineers (SRE) diagnose and fix these errors efficiently.</p> <h2 id="tldr">TL;DR</h2> <ul> <li>A 504 Gateway Timeout means Nginx, acting as a proxy, didn&rsquo;t get a response from the upstream server in time, so the problem sits in the backend, the network, or your timeout settings rather than in Nginx itself.</li> <li>Diagnose before you change anything: check the Nginx and upstream logs, measure backend response time with curl, and test connectivity with ping, traceroute, or mtr.</li> <li>The fastest stopgap is raising Nginx&rsquo;s timeout directives, but the durable fix is making the upstream faster through resource scaling, query optimization, and load balancing.</li> <li>Adding Nginx caching reduces how often requests hit the upstream at all, which keeps a strained backend responsive and cuts down 504s.k.</li> </ul> <h2 id="understanding-the-504-gateway-timeout-error">Understanding The &lsquo;504 Gateway Timeout&rsquo; Error</h2> <p>The &lsquo;504 Gateway Timeout&rsquo; error typically occurs in Nginx when:</p>https://www.netdata.cloud/guides/nginx/nginx-413-request-entity-too-large/Mon, 01 Jan 0001 00:00:00 +0000https://www.netdata.cloud/guides/nginx/nginx-413-request-entity-too-large/<p>A <code>413 Request Entity Too Large</code> after adding <code>client_max_body_size 50m</code> to <code>nginx.conf</code> usually means a more specific context still overrides it, or the upstream application rejects the body after nginx accepts it. The directive applies to <code>http</code>, <code>server</code>, and <code>location</code> blocks. Raising it at the edge only moves the failure deeper if the rest of the stack is not adjusted. This guide covers how the directive inherits, when nginx fires the 413, how <code>proxy_request_buffering</code> changes the failure mode, and why you must verify every hop including the upstream application.</p>https://www.netdata.cloud/guides/nginx/nginx-499-client-closed-connection/Mon, 01 Jan 0001 00:00:00 +0000https://www.netdata.cloud/guides/nginx/nginx-499-client-closed-connection/<p>Status 499 in nginx access logs means the client closed the TCP connection before nginx finished responding. It is an nginx-specific code that never reaches the client, so it is easy to dismiss. In practice, a 499 surge is an early warning: users or intermediaries abandon requests before upstreams officially time out and before 5xx errors spike. Ignore 499s and you usually see 502s or 504s minutes later.</p> <p>This guide shows how to read 499s, separate real user pain from load-balancer noise, and fix the root cause.</p>https://www.netdata.cloud/guides/nginx/nginx-500-internal-server-error/Mon, 01 Jan 0001 00:00:00 +0000https://www.netdata.cloud/guides/nginx/nginx-500-internal-server-error/<p>A 500 from nginx tells you something failed in the request path, but not whether the failure originated in your application, FastCGI/uWSGI backend, or nginx itself. When 500s spike during an incident, first determine which side of the nginx boundary is breaking.</p> <p>Unlike 502 Bad Gateway or 504 Gateway Time-out, which point upstream, a 500 can be an application bug passed through by nginx, a configuration error, a permission failure, or resource exhaustion inside an nginx worker.</p>https://www.netdata.cloud/guides/nginx/nginx-502-bad-gateway/Mon, 01 Jan 0001 00:00:00 +0000https://www.netdata.cloud/guides/nginx/nginx-502-bad-gateway/<p>A 502 Bad Gateway means the upstream server returned an invalid response, refused the connection, or terminated before completing the response. Unlike 504, which signals upstream slowness, 502 means the upstream never produced a valid response or nginx could not reach it.</p> <p>Start with the error log. A single line like <code>connect() failed (111: Connection refused)</code> tells you the upstream is not listening. A line like <code>upstream prematurely closed connection</code> tells you the backend died mid-request. Match the exact message to the root cause.</p>https://www.netdata.cloud/guides/nginx/nginx-503-service-unavailable/Mon, 01 Jan 0001 00:00:00 +0000https://www.netdata.cloud/guides/nginx/nginx-503-service-unavailable/<p>A <code>503 Service Temporarily Unavailable</code> from nginx does not always mean the upstream application is broken. A healthy nginx process returns 503 by design when rate limits reject traffic, or when every backend in an upstream block is unavailable. The same status code covers three different failure paths: intentional throttling, upstream exhaustion, or resource saturation on the nginx host. The fix depends on which path the request took.</p> <p>Distinguishing rate-limit 503s from upstream 503s avoids chasing ghost backend failures. The <code>limit_req</code> and <code>limit_conn</code> modules default to status 503, not 429. This guide maps the three primary failure paths and gives commands to prove which one is active.</p>https://www.netdata.cloud/guides/nginx/nginx-504-gateway-timeout/Mon, 01 Jan 0001 00:00:00 +0000https://www.netdata.cloud/guides/nginx/nginx-504-gateway-timeout/<p>A 504 Gateway Time-out means nginx reached the upstream but the upstream did not finish its response before <code>proxy_read_timeout</code> expired. The default is 60 seconds. Unlike a 502 Bad Gateway, which means nginx never established a valid upstream connection, a 504 means the connection succeeded but the response did not complete in time.</p> <p>This guide covers isolating slow upstreams via access log variables, tuning timeouts and retries, and distinguishing 504 from 502.</p>