{"id":16253,"date":"2026-03-16T02:00:25","date_gmt":"2026-03-16T02:00:25","guid":{"rendered":"https:\/\/greenwebpage.com\/community\/?p=16253"},"modified":"2026-03-16T02:00:28","modified_gmt":"2026-03-16T02:00:28","slug":"troubleshooting-nginx-502-bad-gateway-errors-on-linux","status":"publish","type":"post","link":"https:\/\/greenwebpage.com\/community\/troubleshooting-nginx-502-bad-gateway-errors-on-linux\/","title":{"rendered":"Troubleshooting Nginx 502 Bad Gateway Errors on Linux"},"content":{"rendered":"\n

The 502 Bad Gateway error occurs in Nginx when the server does not receive a valid response back from a downstream service, such as PHP-FPM or Node.js. Check Nginx logs and those of the backend services. Correct configuration and monitoring will prevent 502 errors from occurring on Linux VPS environments. Understanding this error is crucial for maintaining performance and uptime, whether you’re running a WordPress website, a Laravel application, a Node.js application, an API, or a Docker container.<\/p>\n\n\n\n

This guide will show you how to resolve the Nginx 500 Bad Gateway error.<\/p>\n\n\n\n

<\/a>Troubleshooting Nginx 502 Bad Gateway Errors on Linux VPS<\/h2>\n\n\n\n

Nginx 502 Bad Gateway errors on Linux VPSs occur when Nginx is unable to receive a valid response from a backend service upstream, such as PHP-FPM or Node.js. It can be resolved by checking Nginx logs and the application logs. You will also need to verify service status, fix socket or port mismatches, and correct permissions. Monitoring and configuration can help to prevent 502 errors from recurring.<\/p>\n\n\n\n

\"502<\/figure>\n\n\n\n

<\/p>\n\n\n\n

<\/a>Step 1: Check Nginx Error Logs<\/h3>\n\n\n\n

You should always check the Nginx logs before changing any configuration. These logs contain detailed information on why Nginx was unable to communicate with upstream services, including connection issues and permission errors.<\/p>\n\n\n\n

The error logs can often be used to pinpoint the exact cause of an issue, saving you time and preventing configuration changes that are not necessary.<\/p>\n\n\n\n

\n

sudo tail -f \/var\/log\/nginx\/error.log<\/p>\n<\/th><\/tr><\/thead><\/table><\/figure>\n\n\n\n

\"sudo<\/figure>\n\n\n\n

<\/p>\n\n\n\n

<\/a>Step 2: Verify That Nginx Is Running<\/h3>\n\n\n\n

The Nginx server itself cannot send requests to the backend. This can occur after a system upgrade, configuration error, or an unexpected crash.<\/p>\n\n\n\n

The service status will confirm if Nginx has been listening to incoming requests and is active.<\/p>\n\n\n\n

\n

sudo systemctl status nginx<\/p>\n<\/th><\/tr><\/thead><\/table><\/figure>\n\n\n\n

\"sudo<\/figure>\n\n\n\n

<\/p>\n\n\n\n

<\/a>Step 3: Check Backend Application Status<\/h3>\n\n\n\n

Nginx is completely dependent on the backend application to process requests. Nginx cannot forward requests if the backend service does not run. This results in a 502 Error. This ensures that your application server is responding properly and is active.<\/p>\n\n\n\n

PHP-FPM<\/p>\n\n\n\n

\n

sudo systemctl status php-fpm<\/p>\n<\/th><\/tr><\/thead><\/table><\/figure>\n\n\n\n

Node.js (PM2)<\/p>\n\n\n\n

\n

pm2 status<\/p>\n<\/th><\/tr><\/thead><\/table><\/figure>\n\n\n\n

Python (Gunicorn)<\/p>\n\n\n\n

\n

sudo systemctl status gunicorn<\/p>\n<\/th><\/tr><\/thead><\/table><\/figure>\n\n\n\n

<\/a>Step 4: Restart Backend Services<\/h3>\n\n\n\n

Backend services may crash because of memory exhaustion or due to temporary bugs. Restarting the services clears out stuck processes and reloads settings.<\/p>\n\n\n\n

This is the fastest and most effective way to fix Nginx error 502.<\/p>\n\n\n\n

\n

sudo systemctl restart php-fpm<\/p>\n<\/th><\/tr><\/thead><\/table><\/figure>\n\n\n\n

<\/a>Step 5: Restart Nginx Service<\/h3>\n\n\n\n

Nginx must reinitialize and reconnect with backend services after restarting. Nginx can keep stale connections upstream that lead to persistent gateway errors.<\/p>\n\n\n\n

Communication problems can be resolved immediately by a clean restart.<\/p>\n\n\n\n

\n

sudo systemctl restart nginx<\/p>\n<\/th><\/tr><\/thead><\/table><\/figure>\n\n\n\n

\"sudo<\/figure>\n\n\n\n

<\/p>\n\n\n\n

<\/a>Step 6: Verify Nginx Upstream Configuration<\/h3>\n\n\n\n

Nginx needs to be configured with the right backend port or socket. A 502 error will be generated if there is even a slight mismatch between the upstream configured and the actual listener.<\/p>\n\n\n\n

This ensures that Nginx points to the correct endpoint.<\/p>\n\n\n\n

\n

sudo nano \/etc\/nginx\/sites-available\/default<\/p>\n<\/th><\/tr><\/thead><\/table><\/figure>\n\n\n\n

Example:<\/p>\n\n\n\n

\n

fastcgi_pass unix:\/run\/php\/php8.3-fpm.sock;<\/p>\n<\/th><\/tr><\/thead><\/table><\/figure>\n\n\n\n

\"fastcgi_pass<\/figure>\n\n\n\n

<\/p>\n\n\n\n

<\/a>Step 7: Confirm PHP-FPM Socket or Port<\/h3>\n\n\n\n

PHP-FPM will listen to either a Unix Socket or a TCP port. Nginx should use the same communication protocol as defined in PHP-FPM.<\/p>\n\n\n\n

Nginx will not be able to establish a connection if these values do not match.<\/p>\n\n\n\n

\n

sudo nano \/etc\/php\/8.3\/fpm\/pool.d\/www.conf<\/p>\n<\/th><\/tr><\/thead><\/table><\/figure>\n\n\n\n

\"sudo<\/figure>\n\n\n\n

<\/p>\n\n\n\n

<\/a>Step 8: Fix File and Socket Permissions<\/h3>\n\n\n\n

Nginx may be unable to access backend sockets and application files if the ownership or permissions are incorrect. This happens a lot after manual uploads and migrations.<\/p>\n\n\n\n

By ensuring that Nginx is properly configured, it can communicate with the backend services securely.<\/p>\n\n\n\n

\n

sudo chown -R www-data:www-data \/var\/www\/html<\/p>\n

sudo chmod -R 755 \/var\/www\/html<\/p>\n<\/th><\/tr><\/thead><\/table><\/figure>\n\n\n\n

\"sudo<\/figure>\n\n\n\n

<\/p>\n\n\n\n

<\/a>Step 9: Increase Nginx Timeout Settings<\/h3>\n\n\n\n

Some applications can take longer to respond, particularly during high traffic or complex operations. The default timeout values are too low, and Nginx may return an error 502 prematurely.<\/p>\n\n\n\n

Increased timeout values give backend services additional time to respond.<\/p>\n\n\n\n

\n

proxy_read_timeout 300;<\/p>\n

fastcgi_read_timeout 300;<\/p>\n<\/th><\/tr><\/thead><\/table><\/figure>\n\n\n\n

\"fastcgi_read_timeout<\/figure>\n\n\n\n

<\/p>\n\n\n\n

<\/a>Step 10: Check System Resource Usage<\/h3>\n\n\n\n

Backend services can crash suddenly due to low memory, CPU overload, or full disks. Nginx will not respond and return a 502 error when this occurs.<\/p>\n\n\n\n

Monitoring system resources can help identify performance bottlenecks.<\/p>\n\n\n\n

\n

free -h<\/p>\n

df -h<\/p>\n<\/th><\/tr><\/thead><\/table><\/figure>\n\n\n\n

\"free<\/figure>\n\n\n\n

<\/p>\n\n\n\n

<\/a>Step 11: Review Firewall and Security Policies<\/h3>\n\n\n\n

Communication between Nginx services and backend services can be blocked by firewalls or security policies such as SELinux. This can happen on hardened servers or after firewall rule modifications.<\/p>\n\n\n\n

Silent failures can be prevented by ensuring that the required ports and connections are available.<\/p>\n\n\n\n

\n

sudo ufw status<\/p>\n<\/th><\/tr><\/thead><\/table><\/figure>\n\n\n\n

\"sudo<\/figure>\n\n\n\n

<\/p>\n\n\n\n

<\/a>Step 12: Validate Nginx Configuration<\/h3>\n\n\n\n

Even if the services are running, configuration syntax errors can cause upstream communication to be broken. Test the configuration before reloading to avoid unnecessary downtime.<\/p>\n\n\n\n

This step will ensure that your Nginx configuration has been applied correctly and safely.<\/p>\n\n\n\n

\n

sudo nginx -t<\/p>\n<\/th><\/tr><\/thead><\/table><\/figure>\n\n\n\n

\"sudo<\/figure>\n\n\n\n

<\/p>\n\n\n\n

<\/a>Step 13: Inspect Application-Level Logs<\/h3>\n\n\n\n

Nginx can sometimes be the problem, but it could also be the application. Nginx 502 errors are often caused by application errors, crashes, or uncaught errors.<\/p>\n\n\n\n

You can fix the issue by checking your application logs.<\/p>\n\n\n\n

Examples:<\/p>\n\n\n\n