A 502 Bad Gateway error means the web server received an invalid response from an upstream service. With WordPress, that upstream service is often PHP-FPM, which runs the PHP code that loads WordPress.
The error can affect the whole site or appear only when you open /wp-admin, save a post, upload media, place a WooCommerce order, or perform another resource-intensive action. Common causes include a failed PHP-FPM service, exhausted server resources, incompatible code, and requests that exceed configured timeouts.
Create a backup before changing server or WordPress files. If you use cPanel, follow this guide to create and restore a WordPress backup. Then work through the checks below in order.
What causes a WordPress 502 error?
The most common causes are a stopped or overloaded PHP-FPM service, a PHP request that runs longer than the web server allows, insufficient memory or CPU, an incompatible plugin or theme, and incorrect proxy or reverse-proxy settings.
A 502 can also be temporary. A traffic spike, scheduled backup, image-processing task, WooCommerce job, or hosting maintenance event may briefly use all available PHP workers. If the error keeps returning, look for the action that triggers it instead of repeatedly refreshing the page.
Start with a few quick checks
Confirm whether the problem is temporary
Open the site in a private browser window and test both the front end and /wp-admin. Record the URL and action that produces the error. If every site on the same hosting account is unavailable, the problem is more likely to be at the server or hosting level.
Check your hosting provider’s status page. You can also ask support whether PHP-FPM is running, whether the account has reached a CPU or process limit, and whether the server has reported recent errors. Include the domain and approximate time of the failure rather than simply reporting that “WordPress is down.”
Clear caches carefully
Clear the WordPress, server, and CDN caches after recording the error. A cached 502 response can make a resolved problem appear to continue. Purging the cache may remove that response, but it does not fix the underlying PHP or server problem.
Check PHP-FPM and web-server logs
Logs often identify the failing part of the request chain. In cPanel, check Metrics > Errors, the domain error log, or any PHP-FPM section provided by your host. On a server you manage, inspect the Nginx or Apache error log and the PHP-FPM pool log. The exact paths depend on the operating system and server configuration.
Search for messages such as:
connect() to unix:/...php-fpm.sock failedcan indicate a stopped service, incorrect socket path, or permissions problem.upstream timed outpoints to a slow PHP request or an insufficient timeout.server reached pm.max_childrenmeans all PHP-FPM workers were busy.Primary script unknowncan indicate an incorrect document root or PHP-FPM configuration.
If you do not administer the server, send the exact log messages to your hosting provider. Restarting PHP-FPM may restore access, but recurring failures still need an explanation.
Review PHP-FPM workers and timeouts
PHP-FPM handles requests through a pool of worker processes. When pm.max_children is too low, requests queue and may time out. Setting it too high for the available memory can make the server unstable.
On a managed VPS, an administrator might review settings similar to:
pm = dynamic
pm.max_children = 20
pm.start_servers = 3
pm.min_spare_servers = 3
pm.max_spare_servers = 8
request_terminate_timeout = 120sThese values are examples, not universal recommendations. The appropriate limits depend on available RAM, PHP version, traffic, and the memory consumed by each request. Increase worker capacity only after checking memory usage; a larger pool can cause an already overloaded server to fail more quickly.
Timeouts must also be compatible across the stack. Nginx, Apache, a proxy, PHP-FPM, and a CDN may each have their own limit. Raising one timeout rarely fixes a slow query or inefficient plugin.
Check PHP memory and hosting resource limits
A PHP memory failure can produce a 502 when the process is terminated before it returns a valid response. WordPress’s WP_MEMORY_LIMIT is not the same as the total memory available to the server or hosting account.
Review your hosting dashboard for RAM, CPU, entry processes, I/O, and concurrent PHP-process limits. Also check the PHP error log for Allowed memory size exhausted. This related guide explains the issue in more detail: How to Fix the WordPress “Allowed Memory Size Exhausted” Error.
If you control wp-config.php, settings may look like this:
define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );Use values supported by your host. Increasing WordPress’s requested limit cannot create memory that the hosting plan does not provide.
Test for plugin and theme conflicts
A plugin that runs a large database query, calls a remote API, converts images, performs a backup, or calculates checkout data can exhaust PHP workers or exceed a timeout. Recent updates deserve attention, although older plugins can also conflict with a newer PHP version.
If you can access the dashboard
Deactivate recently updated plugins first and test the failing action. If the error remains, deactivate all plugins and reactivate them one at a time. Switch temporarily to a default WordPress theme to rule out theme code.
If you cannot access the dashboard
Using your hosting File Manager or SFTP, rename wp-content/plugins to plugins-disabled. WordPress will treat the plugins as inactive. If the site loads, restore the original folder name and test the plugins individually through the dashboard.
Do not delete plugin folders. Keep a record of each change, and do not leave security or caching plugins disabled without a replacement plan.
Investigate WooCommerce-specific triggers
If the 502 occurs during checkout, cart updates, or order administration, inspect payment, shipping, tax, subscription, and product-feed plugins. A slow external payment or shipping request can occupy a PHP worker until the upstream timeout is reached.
Test on a staging copy where possible, enable only the required WooCommerce components, and review logs under WooCommerce > Status > Logs. For a broader checkout troubleshooting process, see How to Fix WooCommerce Checkout Problems.
Enable logging without displaying errors
For a short diagnostic period, WordPress debugging can record PHP errors without showing them to visitors:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );Review wp-content/debug.log, reproduce the problem once, and then disable debugging. Protect or remove the log afterward because it may contain file paths, plugin details, or sensitive request data.
When to contact your hosting provider
Contact support when PHP-FPM repeatedly stops, logs show exhausted account limits, you cannot change pool settings, or multiple sites fail together. Provide the domain, exact URL, timestamp and time zone, recent changes, relevant log messages, and whether the issue affects the front end, admin, or checkout.
For ongoing performance work, this guide to speeding up WordPress without breaking the site can help reduce slow requests and unnecessary load.
FAQ
Is a 502 error caused by DNS?
Usually not. DNS problems commonly produce resolution or connection errors. A 502 generally means the web server connected to an upstream service but received an invalid response.
Will restarting PHP-FPM permanently fix the problem?
It may restore access temporarily, but recurring errors require investigation of worker limits, memory, slow requests, and plugin or theme code.
Can a WordPress plugin cause a 502?
Yes. Resource-heavy queries, remote requests, background jobs, and incompatible PHP code can make PHP-FPM workers fail or remain busy for too long.
Should I increase every timeout?
No. Higher timeouts can hide slow code and keep workers occupied longer. Identify the slow operation first, then adjust compatible limits when appropriate.
Conclusion
Fixing a WordPress 502 Bad Gateway error means finding where the request chain breaks. Check the logs, confirm PHP-FPM health, review memory and worker limits, isolate plugins and themes, and test WooCommerce operations separately. Make one change at a time and keep a current backup so troubleshooting does not create a second problem.