502 Bad Gateway Error: Causes and Fixes

What Does Error 502 Mean

Error 502 Bad Gateway is an HTTP status indicating that a proxy server (such as Nginx, Apache in proxy mode, Cloudflare) received an invalid or empty response from the backend server it tried to connect to. In simple terms: the gateway between you and the application server could not obtain a meaningful response.

The error is typically displayed in the browser as:

502 Bad Gateway

or

HTTP Error 502

It occurs at the infrastructure level, not in your site's code, and is often related to server availability or configuration issues.

Common Causes

A 502 error occurs due to failures in the request chain. Here are the specific causes:

1. Backend server is not running or has crashed — The application service (e.g., PHP-FPM, Node.js, Python Gunicorn) is stopped, crashed, or failed to start after a reboot.
2. Backend server is overloaded and not responding in time — High CPU, memory, or network load leads to timeouts. The proxy server waits for a response, but the backend cannot respond quickly enough.
3. Incorrect proxy server configuration — Nginx or Apache has an incorrect address or port for proxy_pass (e.g., localhost:9000 instead of 127.0.0.1:9000), or the backend is listening on a different interface.
4. Network issues or firewalls — A firewall (iptables, ufw, cloud security groups) blocks traffic between the proxy and backend, or routing problems occur.
5. Insufficient system resources — The server runs out of memory (OOM killer terminates processes), disk space, or has too many open files.
6. Errors in backend application code — Fatal errors in the code (e.g., segmentation fault in PHP, unhandled exception in Node.js) cause the process to terminate abruptly.
7. Socket or queue issues — The backend server (e.g., PHP-FPM) has too few child processes or small queues, causing new connections to be rejected.

Troubleshooting Methods

It is recommended to perform steps sequentially, starting with the simplest and fastest.

Method 1: Check and Restart the Backend Service

Most often, the problem is that the backend service is not running. Ensure it is active.

For systemd (most modern Linux distributions):

# Check the service status, e.g., php-fpm
sudo systemctl status php-fpm

# If the service is inactive, start it
sudo systemctl start php-fpm

# Or restart it if already running
sudo systemctl restart php-fpm

For Node.js applications managed by PM2:

# Check the list of processes
pm2 list

# Restart a specific application
pm2 restart app-name

For Docker containers:

# Check if the container is running
docker ps

# If the container has crashed, view its logs
docker logs container_name

# Start the container again
docker start container_name

After restarting, wait for the service to fully start (usually 5-10 seconds) and check if the error has disappeared.

Method 2: Verify Proxy Server Configuration

Ensure the proxy server is correctly configured to connect to the backend.

For Nginx:

1. Locate your site's configuration file (usually in /etc/nginx/sites-available/ or /etc/nginx/conf.d/).
2. Check the location block with proxy_pass:

location / {
    proxy_pass http://backend_server:port; # Must point to the correct address
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    # ... other directives
}

3. Ensure backend_server:port is accessible from the server where Nginx runs. Test the connection:

# Replace backend_server:port with your values
curl -I http://backend_server:port

If curl returns a connection error or timeout, the issue is with backend availability or its configuration.

4. After making changes, test the Nginx configuration and reload:

sudo nginx -t
sudo systemctl reload nginx

For Apache (with mod_proxy):

In the configuration file (e.g., /etc/apache2/sites-available/your-site.conf), check the ProxyPass and ProxyPassReverse directives:

ProxyPass / http://backend_server:port/
ProxyPassReverse / http://backend_server:port/

Similarly, verify backend accessibility and reload Apache:

sudo apache2ctl configtest
sudo systemctl reload apache2

Method 3: Adjust Timeouts

If the backend server processes requests slowly (e.g., due to heavy computations), the proxy server may terminate the connection. Increase the timeouts.

In Nginx (within http, server, or location context):

proxy_connect_timeout 60s;   # Time to establish connection with backend
proxy_send_timeout 60s;      # Time to send request to backend
proxy_read_timeout 60s;      # Time to wait for backend response

In Apache (in virtual host configuration or globally):

ProxyTimeout 60

After changes, reload the corresponding service (Nginx or Apache). Start with 60 seconds, but if the application is genuinely slow, set a higher value (e.g., 300s). However, this masks the problem—optimizing the application is better.

Method 4: Check Error Logs

Logs are your best friends. They contain precise error messages.

Nginx logs (typically in /var/log/nginx/error.log):

sudo tail -f /var/log/nginx/error.log

Look for lines with 502, upstream, connect() failed. Example:

2026/02/17 10:30:45 [error] 1234#1234: *1 connect() failed (111: Connection refused) while connecting to upstream, client: 192.168.1.1, server: example.com, request: "GET / HTTP/1.1", upstream: "http://127.0.0.1:9000/", host: "example.com"

This indicates Nginx cannot connect to 127.0.0.1:9000.

Apache logs (e.g., /var/log/apache2/error.log):

sudo tail -f /var/log/apache2/error.log

Look for proxy: error reading response, Connection refused.

Backend service logs:

• PHP-FPM: /var/log/php-fpm/error.log or /var/log/php7.4-fpm.log.
• Node.js: depends on configuration, often logged to systemd journal or a file specified in the config.
• Python Gunicorn: logged via systemd or to a specified file.

By analyzing logs, you often immediately find the root cause: memory shortage, code error, permission issues.

Method 5: Check System Resources and Network Settings

Ensure the server has sufficient resources and no blockades.

Resource check:

# Memory and swap
free -h

# CPU load and processes
top
# Or htop, if installed

# Disk space
df -h

# Number of open files (ulimit)
ulimit -n

If memory is low, consider adding swap or optimizing the application. If there are many processes, you may need to increase limits in systemd (for services) or in backend configuration (e.g., pm.max_children for PHP-FPM).

Network settings check:

• Ensure the backend server listens on the correct interface. For example, PHP-FPM by default listens on 127.0.0.1:9000, but if Nginx uses localhost:9000, that should work. If the backend listens only on 127.0.0.1 and Nginx is on a different server, you need to bind to an external interface or use sockets.
• Check the firewall:

# For ufw
sudo ufw status

# For iptables
sudo iptables -L -n

Ensure the backend port (e.g., 9000) is open for local connections (if proxy and backend are on the same server) or for the proxy's IP (if on different servers).

Method 6: Contact Your Hosting Provider or Administrator

If you use shared hosting, a cloud service (e.g., AWS Elastic Beanstalk, Heroku), or a managed service (e.g., Cloudflare, AWS ALB), many infrastructure aspects are controlled by the provider. In this case:

• Check your hosting control panel for any issue notifications.
• Ensure the backend service (e.g., PHP application) is properly deployed and meets requirements (PHP versions, extensions).
• Contact support, providing the exact time the error occurred and any logs you have. The provider can check the status of their load balancers or network devices.

Prevention

To minimize the risk of a 502 error:

1. Monitoring and alerts — Set up monitoring for backend service availability (e.g., via Prometheus, Zabbix, or even a simple curl script). Configure alerts when a service goes down.
2. Automatic service restarts — Use systemd with Restart=on-failure or tools like supervisor for processes not managed by systemd. Example for a systemd unit:

   [Service]
   Restart=on-failure
   RestartSec=5
   

3. Performance optimization — Cache requests, use task queues for heavy operations, optimize SQL queries. This reduces load and response time.
4. Configure appropriate timeouts — Set timeouts in the proxy server and backend consistently. For example, if Nginx has proxy_read_timeout 60s, the backend should respond faster or have a longer timeout.
5. Regular software updates — Keep up with security updates and patches for Nginx, Apache, PHP, Node.js, and other components.
6. Testing in a staging environment — Before deploying changes to production, test them in a staging environment, especially proxy configuration and resource settings.

Following these recommendations will not only help you fix the current 502 error but also prevent it from recurring in the future.