Nginx · The edge of your stack
How do you debug a failing Nginx request in production?
Short answer
Work outward from the status code and error log: validate config, inspect upstream address and timing, test the backend directly, and correlate a request ID across Nginx and application logs.
Start with the exact response and the error log entry for the same timestamp. A 502 usually means Nginx could not get a valid response from the upstream, while a 504 means the upstream did not respond within the configured timeout.
nginx -t
nginx -T
curl -v --resolve example.com:443:127.0.0.1 https://example.com/health
curl -H "Host: example.com" http://127.0.0.1/health
tail -f /var/log/nginx/error.logMap the symptom
- 502 Bad Gateway: upstream refused the connection, closed it early or sent an invalid response
- 504 Gateway Timeout: connect, read or send timeout expired
- 413 Request Entity Too Large: client_max_body_size or a buffer limit is too small
- 499: the client closed the connection before Nginx finished
- 400 or SSL errors: malformed request, SNI mismatch, expired certificate or protocol mismatch
Use the upstream address and request ID from the access log to find the corresponding backend log line. Then confirm whether the problem is DNS, a firewall, TLS, application latency or a response header too large for the configured buffer.
Follow-ups you should expect
Interviewers use these to check whether the first answer was understanding or memorisation.
- 1What are the common causes of a 502 from Nginx?
- 2How do you distinguish an upstream timeout from a client timeout?
- 3Why would curl work on the host but requests fail through the load balancer?
- 4How do you correlate Nginx logs with application logs?
Say it in the interview
I start from the status code and the error log. A 502 means the upstream could not produce a valid response, while a 504 is a timeout. I validate config, confirm the effective settings, and curl the local Nginx with a Host header to bypass DNS and the external load balancer. Then I use the upstream address and request ID to find the backend log line, enabling debug logging only narrowly.
Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.
Related questions
Reading is step one
Now say it out loud.
Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live Nginx mock interview and get scored feedback on depth, clarity and confidence.