How do you troubleshoot a 502 Bad Gateway error in Nginx?
A step-by-step guide to fixing Nginx 502 Bad Gateway errors: read the error log, check the backend, verify proxy_pass, and tune timeouts and buffers.
Expected Interview Answer
A 502 Bad Gateway in Nginx means Nginx acted as a proxy but got an invalid or no response from the upstream (backend) server, so you troubleshoot by checking whether the upstream is running, reachable, and responding within timeouts.
Start by reading the Nginx error log, which usually names the exact cause: connection refused, upstream timed out, or no live upstreams. Then verify the backend process is up and listening on the expected host, port, or socket, confirm proxy_pass points to the right address, and check that firewalls or SELinux are not blocking the connection. Common fixes include restarting the crashed backend, correcting the upstream address, raising proxy_read_timeout for slow responses, and increasing buffer sizes when the backend sends large headers.
- Pinpoints whether the fault is Nginx or the backend
- The error log usually names the exact cause
- Distinguishes crashes from timeouts and blocked ports
- Guides concrete config fixes like timeouts and buffers
- Reduces downtime with a repeatable checklist
AI Mentor Explanation
A 502 is like a runner sprinting to the non-striker's end only to find no partner there to complete the run. Nginx is the batter relaying the ball onward, but the upstream teammate never responded, so the run collapses. Troubleshooting is checking the scorecard notes (the error log) to see whether the partner was run out (crashed), too slow to arrive (timeout), or was standing at the wrong crease (wrong address) before you fix the pairing.
Step-by-Step Explanation
Step 1
Read the error log
Check /var/log/nginx/error.log for the exact reason: connection refused, upstream timed out, or no live upstreams.
Step 2
Verify the backend is running
Confirm the app or FastCGI/PHP-FPM/uWSGI process is up and listening on the expected port or socket.
Step 3
Check proxy_pass and upstream
Make sure proxy_pass or the upstream block points to the correct host, port, or socket path.
Step 4
Test connectivity
Use curl to the backend directly and check firewall, SELinux, and socket permissions between Nginx and the app.
Step 5
Tune timeouts and buffers
Raise proxy_read_timeout for slow apps and increase proxy_buffer_size / fastcgi_buffers if headers are too large.
What Interviewer Expects
- Knows 502 means a bad upstream response
- Checks the Nginx error log first
- Verifies the backend process and port or socket
- Considers timeouts, buffers, and connectivity
- Distinguishes crashes from slow responses
Common Mistakes
- Assuming the fault is always in Nginx, not the backend
- Ignoring the error log which names the cause
- Forgetting to check the upstream port or socket path
- Overlooking firewall or SELinux blocking the connection
- Not raising timeouts for legitimately slow backends
Best Answer (HR Friendly)
“A 502 Bad Gateway means Nginx passed a request to the backend server but got a bad or missing reply. You fix it by checking the error log, making sure the backend is running and reachable on the right port, and adjusting timeouts if the app is just slow.”
Code Example
# 1. Read the most recent errors
tail -n 50 /var/log/nginx/error.log
# 2. Is the backend process up and listening?
sudo ss -ltnp | grep 8080
# 3. Hit the backend directly, bypassing Nginx
curl -v http://127.0.0.1:8080/
# 4. Example fix: raise the read timeout for a slow app
# location / {
# proxy_pass http://127.0.0.1:8080;
# proxy_read_timeout 120s;
# proxy_buffer_size 16k;
# proxy_buffers 4 16k;
# }Follow-up Questions
- What is the difference between a 502 and a 504 Gateway Timeout?
- How do you increase proxy timeouts in Nginx?
- What does 'upstream sent too big header' mean and how do you fix it?
- How does an upstream block with multiple servers affect 502s?
- How would you check if SELinux is blocking Nginx from connecting?
MCQ Practice
1. A 502 Bad Gateway in Nginx primarily indicates a problem with?
502 means Nginx received an invalid or no response from the upstream server it proxied to.
2. Where should you look first to find the cause of a 502?
The error log records the specific upstream failure, such as connection refused or upstream timed out.
3. Which fix helps when the backend is legitimately slow to respond?
Raising proxy_read_timeout gives a slow but healthy upstream more time to respond before Nginx gives up.
Flash Cards
What does 502 Bad Gateway mean? — Nginx got an invalid or no response from the upstream/backend server it proxied to.
First step to debug a 502? — Read /var/log/nginx/error.log — it names the cause like connection refused or upstream timed out.
502 vs 504? — 502 is a bad/broken upstream reply; 504 is the upstream not replying within the timeout.
Fix for large upstream headers causing 502? — Increase proxy_buffer_size and proxy_buffers (or fastcgi_buffers).