What a 502 Bad Gateway error means
Modern WordPress hosting often has several layers between a visitor and WordPress. A request might pass through a CDN, reverse proxy or web server before PHP runs the WordPress code. A 502 response tells you that a gateway or proxy reached the next layer but did not receive a valid response from it.
This is different from a 504 timeout. With a 502, the upstream response was invalid or the connection failed in a way the gateway could not use. The wording can vary between Nginx, a CDN and a hosting platform, but the HTTP status has the same basic meaning.
Take a full backup of the website files and database before changing WordPress files, plugins or configuration. Where possible, use staging for diagnostic changes.
Common causes of a WordPress 502 error
A frequent WordPress cause is a PHP process that crashes, restarts or becomes unavailable while the web server is waiting for it. Plugin or theme code can contribute by triggering fatal PHP errors, excessive memory use or unusually expensive requests.
A 502 can also originate outside WordPress. Reverse proxy configuration, an unavailable PHP-FPM service, a failed deployment, overloaded hosting, network problems between a CDN and the origin, or an origin server refusing a connection can all produce the same status.
Look at scope and timing before changing settings. If only one URL or WordPress action fails, application code is more likely. If every request fails at once, including static files, investigate the hosting, proxy and origin layers early. Intermittent 502 errors during traffic spikes can indicate capacity or worker exhaustion rather than a permanently broken configuration.
How to fix a 502 Bad Gateway error in WordPress
- Retest the site. Check several URLs and wp-admin. A short-lived restart or hosting event may clear without any WordPress change, while a repeatable failure gives you something useful to diagnose.
- Check recent changes. If the 502 began after updating a plugin, theme, PHP version, caching layer or server setting, reverse that specific change using a known working backup or configuration.
- Check the hosting status and logs. Look for PHP crashes, PHP-FPM worker failures, upstream connection errors, memory exhaustion or service restarts at the same time as the 502. Web server and PHP logs are more useful here than the error page itself.
- Isolate WordPress plugins. If wp-admin is available, deactivate recently changed plugins first. If it is unavailable, use SFTP or the host file manager to rename a suspected plugin directory under wp-content/plugins. If required, temporarily rename the main plugins directory to test all plugins, then restore it and reactivate them individually.
- Check WordPress debugging where PHP is still running. WP_DEBUG and WP_DEBUG_LOG can expose fatal errors generated before the upstream connection fails. Do not display debugging output publicly on a production site, and turn debugging back off after diagnosis.
- Check the proxy to origin path. If a CDN or reverse proxy is involved, verify that the origin server is reachable and that DNS, SSL and upstream addresses point to the intended server. Avoid disabling security controls permanently just to make the error disappear.
- Review capacity rather than simply increasing timeouts. If logs show exhausted PHP workers, memory pressure or repeated slow requests, identify which request or component is consuming the resources. Increasing proxy timeouts will not fix a PHP service that is crashing or unavailable.
When a WordPress 502 needs technical help
Get technical help if PHP-FPM is repeatedly restarting, the origin is unreachable from the proxy, server logs show resource exhaustion, or the error continues after recent WordPress changes have been rolled back. These faults often cross the boundary between WordPress and the hosting stack.
Our Emergency Fix is £249 per incident with response within 2 working hours. If you want ongoing maintenance, monitoring and backups, care plans start at £59 a month.