How to Fix 502 Bad Gateway in Nginx/Apache on Ubuntu 24.04
Quick Fix Summary
TL;DRRestart your backend application server (e.g., PHP-FPM, Gunicorn) and verify the upstream service is listening on the correct port.
A 502 Bad Gateway error indicates your web server (Nginx/Apache) successfully received a request but failed to get a valid response from the upstream application server it was configured to proxy to. This is a reverse proxy configuration or backend service failure.
Diagnosis & Causes
Recovery Steps
Step 1: Verify Backend Service Status and Restart
First, check if your application backend process is running. For common setups like PHP-FPM or Gunicorn, restarting it is the fastest recovery action.
# Check PHP-FPM status (common with Nginx)
sudo systemctl status php8.3-fpm
# Restart PHP-FPM if stopped
sudo systemctl restart php8.3-fpm
# For Python/Gunicorn
sudo systemctl restart gunicorn
# For Node.js/PM2
pm2 listStep 2: Check Web Server Error Logs for Upstream Details
The web server error log contains specific reasons for the 502. Tail the logs to see the exact upstream failure (connection refused, timeout, permission denied).
# For Nginx
sudo tail -f /var/log/nginx/error.log
# For Apache
sudo tail -f /var/log/apache2/error.log
# Look for lines containing 'upstream' or 'connect() failed'Step 3: Test Network Connectivity to the Backend
Manually test if the web server can reach the backend service on the configured port and socket. This isolates network/firewall issues.
# If backend is on localhost port 9000 (PHP-FPM default)
sudo curl -v http://localhost:9000/status
# Use netstat to confirm backend is listening
sudo netstat -tulpn | grep :9000
# Test socket connectivity (common for PHP-FPM)
sudo ls -la /run/php/php8.3-fpm.sockStep 4: Review and Fix Web Server Proxy Configuration
A misconfigured `proxy_pass` (Nginx) or `ProxyPass` (Apache) directive is a common root cause. Ensure the upstream address and port are correct.
# Example: Check Nginx site config for proxy_pass
sudo nginx -t
sudo cat /etc/nginx/sites-available/your_site | grep -A2 -B2 proxy_pass
# Ensure it points to a running service, e.g.:
# location / {
# proxy_pass http://localhost:3000;
# }Step 5: Increase Proxy Timeout Values
If the backend is slow, it may exceed default timeouts. Increase `proxy_read_timeout` (Nginx) or `ProxyTimeout` (Apache) in your web server config.
# For Nginx - Add inside location or server block
proxy_connect_timeout 300s;
proxy_send_timeout 300s;
proxy_read_timeout 300s;
# For Apache - Add in VirtualHost
ProxyTimeout 300Step 6: Inspect Backend Resource Limits (Memory, Workers)
A 502 can occur if the backend process hits memory limits or has no available worker threads. Check system resources and application server config.
# Check system memory and for OOM kills
free -h
sudo dmesg | grep -i kill
# Review PHP-FPM pool settings (pm.max_children)
sudo nano /etc/php/8.3/fpm/pool.d/www.conf
# Check Gunicorn worker count in service fileArchitect's Pro Tip
"For PHP-FPM on Ubuntu 24.04, the socket path changed to `/run/php/php8.3-fpm.sock`. Ensure your Nginx `fastcgi_pass` directive matches this exact path, not an older version like `php8.1`."
Frequently Asked Questions
I restarted PHP-FPM and the 502 error persists. What's next?
Immediately check the Nginx error log (`sudo tail -f /var/log/nginx/error.log`). The most common next culprit is an incorrect `fastcgi_pass` socket path (e.g., pointing to php8.1 instead of php8.3) or socket file permissions.
Should I always increase timeout values to fix a 502?
No. Increasing timeouts is a temporary workaround for a slow backend. First, diagnose *why* the backend is slow (high DB load, inefficient code, insufficient CPU) using `top`, `htop`, or application monitoring tools.
How do I differentiate between an Nginx and Apache 502 error?
The process is identical: both act as reverse proxies. The difference is in the config directive (`proxy_pass` vs `ProxyPass`) and log file location (`/var/log/nginx/error.log` vs `/var/log/apache2/error.log`).