A WordPress 502 bad gateway error means a server acting as a gateway or proxy did not receive a valid response from the next server in the chain. Start by checking whether the failure affects every page, then test the origin without the CDN or proxy. If the origin also returns 502, move directly to hosting and PHP diagnostics.
Confirm where the 502 begins
Open these URLs in a private browser window:
- Your home page
/wp-admin/- A simple static file, such as an uploaded image
- Another website on the same hosting account, if available
If only one browser or network fails, clear the browser cache and try another connection. Do not change WordPress files until you have confirmed the error elsewhere.
A static file that loads while WordPress pages return 502 is a useful clue. The web server is reachable, but requests involving PHP may be failing. If every URL fails, including static files, the likely cause is farther upstream: the CDN, reverse proxy, web server, or hosting platform.
Also check your host’s status page for an active incident or maintenance window.
Check the CDN or reverse proxy
When Cloudflare or another CDN displays the error, determine whether the CDN or the origin server generated it. Test the origin through your hosting provider’s preview URL or ask the host to bypass the proxy for a controlled test.
Do not change DNS records unless you know the correct origin IP and understand the effect on email and other services. DNS changes may remain cached after you restore the previous value.
Cloudflare distinguishes between errors returned by the origin and errors generated by its own network. A Cloudflare-branded 502 or 504 page generally means the origin returned that status. An unbranded blank error page can indicate a Cloudflare-generated error. See Cloudflare’s 502 and 504 troubleshooting documentation for the current diagnostic details.
If the site works when the proxy is bypassed, review:
- The origin IP configured at the CDN
- Firewall rules that may block CDN address ranges
- SSL mode and the origin certificate
- Proxy connection and read timeouts
- Recent DNS or hosting migrations
If the origin still returns 502 without the CDN, restore any temporary proxy changes and continue with the server checks.
Check hosting and PHP-FPM
On managed WordPress hosting, contact support before restarting services yourself. Give them:
- The exact URL that fails
- The time of the latest failure, including your time zone
- Whether static files still load
- Whether bypassing the CDN changes the result
- Any request or error ID shown on the error page
Ask the host to check the reverse-proxy, web-server, PHP-FPM, and resource-limit logs for that timestamp. A useful question is whether PHP workers were unavailable, terminated, or waiting on a slow request.
If you administer the server, check service status and logs using the commands appropriate for your distribution and PHP version. Common examples are:
sudo systemctl status php-fpm
sudo systemctl status nginx
sudo systemctl status apache2The PHP-FPM service may include a version, such as php8.3-fpm. Find the installed unit rather than copying a service name blindly:
systemctl list-units --type=service | grep -E 'php.*fpm|nginx|apache'Restarting PHP-FPM may restore service when workers are stuck, but it also interrupts active PHP requests:
sudo systemctl restart php8.3-fpmUse the actual unit name from your server. If the 502 returns, a restart treated only the symptom. Check the logs for worker exhaustion, crashes, out-of-memory events, timeouts, or a mismatch between the web server’s configured PHP socket and the socket PHP-FPM uses.
Inspect logs before changing WordPress
Check the hosting control panel’s PHP and web-server logs first. Focus on entries recorded at the same second as a failed request.
Messages such as connection refused, upstream timed out, no live upstreams, or a missing Unix socket point to server or PHP-FPM configuration. Resolve those at the hosting layer rather than disabling WordPress plugins at random.
If the server reaches WordPress but a PHP fatal error occurs, enable WordPress debugging temporarily in wp-config.php:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );Add or update these constants above the line that says to stop editing. Reproduce the error once, then inspect wp-content/debug.log.
Debug logs can contain paths, query details, email addresses, and other sensitive data. Disable debugging after collecting the relevant entry:
define( 'WP_DEBUG', false );
define( 'WP_DEBUG_LOG', false );
define( 'WP_DEBUG_DISPLAY', false );The WordPress debugging documentation explains these settings in detail.
Isolate plugins only when PHP reaches WordPress
A plugin conflict is worth testing when logs identify plugin code, the error began after an update, or some WordPress requests still work. It is less likely to help when PHP-FPM is stopped or the proxy cannot connect to it.
If WP-CLI works, save the active plugin slugs before making changes:
wp plugin list --status=active --field=name > active-plugins.txtCheck that active-plugins.txt contains the expected plugins, then deactivate them:
wp plugin deactivate --allReload the failing page. If it works, activate plugins individually until the 502 returns:
wp plugin activate plugin-slugTo restore every plugin that was active before the test, run:
xargs wp plugin activate < active-plugins.txt
rm active-plugins.txtIf WP-CLI is unavailable, rename wp-content/plugins through SSH or the hosting file manager. Restore the original directory name immediately after the test. Renaming the directory can disrupt forms, checkout flows, security controls, and caching, so use a maintenance window on transactional sites.
WordPress includes plugin deactivation among its standard steps for diagnosing server-side failures in its common WordPress errors guide.
Test the active theme if logs point to it
Switch themes only after plugins have been ruled out or the PHP error names the active theme. First record the active theme:
wp theme list --status=activeWith a default WordPress theme already installed, activate it:
wp theme activate twentytwentysixReplace twentytwentysix with the slug of an installed default theme. After the test, reactivate the original theme:
wp theme activate original-theme-slugOn a live site, switching themes can alter layouts, widgets, menus, and template settings. Prefer a staging copy unless the site is completely unavailable and you have a current backup.
Escalate recurring or intermittent 502 errors
An intermittent 502 often needs server-level evidence. Send the host several exact timestamps and ask them to correlate those requests with:
- PHP-FPM worker limits
- CPU and memory exhaustion
- Killed PHP processes
- Slow database or external API calls
- Reverse-proxy timeouts
- PHP socket or port failures
- Firewall blocks between the proxy and origin
Do not increase PHP memory, worker counts, or proxy timeouts without identifying the constraint. Higher limits can hide a slow request and place more pressure on an already overloaded server.
Once the site is available again, undo temporary debugging, plugin, theme, CDN, and DNS changes. If restarting PHP-FPM was the only action that helped, keep the incident open with the host until the underlying worker or resource failure is identified.