What a 504 tells you — and what it does not
A 504 Gateway Timeout means a gateway or proxy did not receive a timely response from a server it needed upstream. It does not prove that the VPS is down, that NGINX itself is broken, or that increasing a timeout is the right repair. A 502 reports a different upstream failure; if a 502 followed a PHP-FPM or VPS restart, use the VPS PHP-FPM 502 guide.
First identify which gateway generated the response. A CDN, load balancer or other proxy can return a 504 before a request reaches NGINX on your VPS. Record the full hostname, failing path, HTTP method, response time, UTC timestamp and any request identifier. Compare a safe public GET with a second known-working path. Do not repeat a checkout, payment, form submission or other action that could be processed even though its response timed out.
Match the failed request to the right logs
If the customer is authorised to inspect the VPS, find the active NGINX error and access log locations for the relevant virtual host. They vary by installation and configuration; do not assume that /var/log/nginx/error.log is the only log. The error log may name an upstream and say whether it timed out while connecting, sending a request or reading a response header or body. Correlate that line with the same path and timestamp in the access log and with the application log. A 504 shown by an external edge but absent from the VPS access log points to another layer or a logging gap; it does not prove the app was never contacted.
Preserve a small, redacted excerpt and the time zone. Remove cookies, query-string tokens, customer data and internal addresses before sharing it. An optional NGINX access-log format can record upstream connection, header and response timings, but those fields cannot be inferred when they were not configured.
Find the upstream and timeout stage
Inspect the NGINX server and location that handle the failing request. An HTTP application behind proxy_pass uses proxy timeouts; a PHP-FPM FastCGI application behind fastcgi_pass uses FastCGI timeouts. An authorised administrator can use nginx -T to test and display the configuration files that invocation would load. Confirm that its binary and configuration path match the running instance, and check for edits not yet reloaded, before treating the output as the live configuration. Do not publish the full output because it can expose internal names or credentials. Follow the configured upstream address, port or socket rather than a guessed default. Compare the exact NGINX error with the upstream service status and its own logs for that request.
- Connection stage: check whether the expected service is listening on the configured address and whether a network or socket permission problem blocks it. The VPS application-port guide covers that path.
- Response stage: check whether the app accepted the request but waited on a database, storage operation, external API, worker queue or lock. A slow or saturated upstream may be alive yet unable to answer before the gateway waits out its interval.
- Intermittent failures: compare failing and working requests, deployment time, application errors and resource pressure. Avoid attributing a single 504 to CPU, memory or disk without matching evidence.
Repair the cause before changing a timeout
Fix the confirmed bottleneck or broken dependency within the service owner’s authority. If a recent deployment introduced a hanging request, use the application’s reviewed rollback or repair path. If workers are saturated, identify the workload and queue before changing capacity. If storage is slow, use the disk I/O diagnosis rather than restarting services at random.
Only consider a scoped timeout change when the response is intentionally long-running, the upstream is healthy, and the owner accepts the client and resource impact. NGINX documents proxy_read_timeout and fastcgi_read_timeout as waits between successive reads, not maximum total request durations. The actual configured value can differ from the documented default. A larger limit can make visitors wait longer while concealing a stalled query or dependency; a background job with progress feedback may fit a genuinely long task better. Test any authorised change with configuration validation and a reversible deployment.
Verify recovery and send a useful hand-off
Repeat the original safe request through the same public hostname, then check its status and response time together with the gateway and application logs. Confirm a second representative path still works. If a client request may have changed state, inspect the application outcome before retrying it. Watch for repeated timeouts during the agreed observation window; a single successful reload does not show that the intermittent cause is gone.
If Novasean or another operator needs to help, provide the hostname, UTC incident window, safe failing path and method, the gateway that produced the 504, a redacted NGINX error line, the configured upstream type and any matching application/resource evidence. State which layer you can access and what changed shortly before the fault. Novasean can investigate only the components included in the accepted service; an external CDN, application or third-party API may require its own owner.
Common questions
Should I increase proxy_read_timeout immediately? No. First establish that this NGINX proxy generated the 504 and locate the stalled upstream. A longer wait can mask the underlying failure.
Does a 504 mean my VPS is offline? No. A gateway might be reachable while one upstream request times out. Check the service and request path separately.
Is 504 the same as 502? No. HTTP defines 504 as an untimely upstream response and 502 as an invalid upstream response. The NGINX log narrows the actual failure.
Can I share my entire log with support? Share only the relevant redacted lines; logs can contain personal data, secrets and internal paths.
Sources and technical references
Related guides
Was this guide helpful?
If you accepted optional analytics, your Yes/No answer and this guide’s page address are sent to Google Analytics. No written feedback is collected. Read our privacy statement or change your choice in .
Need help with your service?
Open your client area or contact Novasean. Describe the symptom and checks you have performed. Keep passwords, recovery codes and private keys out of your message.