How to Fix 502 Bad Gateway on Nginx with WordPress

A 502 Bad Gateway error on Nginx with WordPress means the web server (Nginx) couldn’t get a valid response from the upstream server (usually PHP-FPM) that processes WordPress code. This guide walks you through the most common causes and fixes, from simple restarts to configuration tweaks, so you can get your site back online quickly.

What You’ll Need

• SSH access to your server (command line)
• sudo or root privileges
• Basic familiarity with the command line
• Your server’s OS (Ubuntu/Debian or CentOS/RHEL examples provided)

Step-by-Step

1. Restart PHP-FPM and Nginx. Often a temporary glitch causes the 502. Restart both services:

   sudo systemctl restart php8.1-fpm
   sudo systemctl restart nginx

   (Adjust the PHP version to match yours, e.g., php8.2-fpm, php7.4-fpm). If you’re on CentOS/RHEL, the service might be named php-fpm instead. After restarting, reload your site. If it works, you’re done.

2. Check if PHP-FPM is running. If the restart didn’t help, verify the process is active:

   sudo systemctl status php8.1-fpm

   You should see “active (running)”. If it’s inactive or failed, start it with sudo systemctl start php8.1-fpm. Check the logs for errors: sudo tail -50 /var/log/php8.1-fpm.log (or the appropriate path).

3. Check Nginx error logs. Nginx logs exactly why it couldn’t connect. Look at:

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

   Common messages include “connect() failed (111: Connection refused)” – meaning PHP-FPM isn’t listening on the expected socket/port, or “upstream sent too big header” – meaning a plugin or theme is sending too many cookies/headers.

4. Verify the PHP-FPM socket path matches Nginx config. The most frequent cause is a mismatch between where PHP-FPM listens and where Nginx expects it. Check your PHP-FPM pool config (e.g., /etc/php/8.1/fpm/pool.d/www.conf) for the listen directive. It might be listen = /run/php/php8.1-fpm.sock or listen = 127.0.0.1:9000. Then check your Nginx server block (e.g., /etc/nginx/sites-available/your-site) for the fastcgi_pass directive. They must match exactly. If they differ, update one to match the other and restart both services.
5. Increase PHP memory limit. A memory-exhausted PHP process can cause 502s. Edit your php.ini (find it with php --ini) and set memory_limit = 256M (or higher). Also check your wp-config.php for define('WP_MEMORY_LIMIT', '256M');. Restart PHP-FPM after changes.
6. Disable a problematic plugin or theme. A plugin or theme can crash PHP. Rename the plugins folder to disable all plugins:

   cd /var/www/your-site/wp-content
   mv plugins plugins_old
   mkdir plugins

   If the site loads, one of your plugins was the culprit. Rename the folder back, then re-enable plugins one by one (via wp-admin) to find the bad one. Similarly, rename your active theme folder (e.g., mv themes/yourtheme themes/yourtheme_old) – WordPress will fall back to a default theme.

7. Check file permissions. Wrong ownership/permissions can block PHP-FPM from reading files. Typically, files should be owned by www-data:www-data (Debian/Ubuntu) or nginx:nginx (CentOS). Run:

   sudo chown -R www-data:www-data /var/www/your-site
   sudo find /var/www/your-site -type d -exec chmod 755 {} \;
   sudo find /var/www/your-site -type f -exec chmod 644 {} \;

   (Adjust the user/group to your setup).

8. Check for a corrupted .htaccess (if using Nginx + Apache hybrid). Some setups use Nginx as a reverse proxy for Apache. If so, a broken .htaccess can cause a 502. Temporarily rename it: mv .htaccess .htaccess_old. If the site loads, regenerate it via Settings → Permalinks in wp-admin.
9. Restart MySQL/MariaDB. If the database is down, WordPress can’t load, and PHP-FPM might return an error that Nginx sees as a 502. Check with sudo systemctl status mysql (or mariadb). Restart if needed.
10. Increase Nginx timeout settings. If your site legitimately takes too long to respond (e.g., a slow script), Nginx gives up. Add to your Nginx server block:

    proxy_read_timeout 300;
    proxy_connect_timeout 300;
    fastcgi_read_timeout 300;

    Restart Nginx.

Common Mistakes

• Mismatched socket paths – the #1 cause. Always verify both sides.
• Forgetting to restart PHP-FPM after config changes – changes only take effect after a restart.
• Copy-pasting commands without adjusting paths – your site’s location may differ from examples.
• Ignoring error logs – they tell you exactly what’s wrong; skipping them leads to guesswork.
• Disabling plugins by deleting them – rename instead, so you can restore.

Tips

• Use a staging environment to test plugin updates before pushing to production.
• Keep regular backups of your site files and database.
• Monitor your server’s resource usage (CPU, memory) – a 502 can be a symptom of resource exhaustion.
• If you use a caching plugin, clear its cache after fixing the issue.
• Set up log rotation so logs don’t fill your disk.

Troubleshooting

If you’ve gone through the steps and still see a 502:

• Check all Nginx configs – run sudo nginx -t to test for syntax errors. If it reports an error, fix it and reload.
• Look at PHP-FPM slow log – enable slowlog in the pool config to see which script is hanging.
• Check system resources – run free -h and df -h. If memory or disk is full, PHP-FPM may crash.
• Review WordPress debug.log – add define('WP_DEBUG', true); and define('WP_DEBUG_LOG', true); to wp-config.php, then check wp-content/debug.log for PHP errors.
• Try a default PHP-FPM pool – if your custom pool is misconfigured, temporarily use the default www.conf to see if it resolves.
• Check SELinux (CentOS/RHEL) – if SELinux is enforcing, it may block Nginx from connecting to the socket. Run sudo setsebool -P httpd_can_network_connect 1 or sudo setsebool -P httpd_can_network_relay 1.
• Reinstall PHP-FPM – as a last resort, purge and reinstall the package (backup configs first).

Frequently Asked Questions

Why does my 502 happen only on certain pages?

That usually points to a specific plugin or theme function that crashes PHP on those pages. Check the PHP-FPM error log for the exact script, then disable the suspected plugin.

What’s the difference between 502 and 504?

A 502 means the upstream server (PHP-FPM) returned an invalid response. A 504 Gateway Timeout means Nginx waited too long for the upstream to respond. Both share similar fixes, but 504 often needs timeout increases.

Can a CDN cause a 502?

Yes, if the CDN can’t reach your origin server, it may show a 502. Check your CDN’s logs and ensure your origin is accessible from the internet.

How do I find my PHP version to know which service to restart?

Run php -v on the command line. If that doesn’t match your web server’s version, check with phpinfo() in a test file or look in your Nginx config for the fastcgi_pass socket name (e.g., php8.1-fpm.sock).

Will changing file permissions break my site?

If you use the standard 755 for directories and 644 for files, it’s safe. Avoid using 777, which is insecure. If you’re unsure, just change ownership first.

My site works with a static page but 502s on the WordPress blog – why?

Static pages are served directly by Nginx, so they don’t involve PHP-FPM. If WordPress fails, the issue is in PHP-FPM or WordPress itself, not Nginx.

Related

• Access Google Music from Desktop: Full Guide
• Wipe Cache Moto Z2 Play: Steps & What It Does
• GeForce Experience Scanning Failed: Fixes That Work