A 502 response means a gateway or proxy did not obtain a valid upstream response. Trace the exchange involved: CDN to host, web server to PHP, or another service. Cached public pages can still load while dynamic requests fail, so compare the original action with server logs rather than relying on the homepage alone.
Guide reviewed: October 8, 2026. Interface labels may vary by version, account and device.
Quick diagnosis
| Pattern | Inspect | Evidence |
|---|---|---|
| Every dynamic request fails | PHP or upstream service health | Web-server and PHP logs at the same time |
| Only a large job fails | Operation and workload stage | Size, duration and resource evidence |
| After migration | Origin destination and hostname/TLS setup | Provider-confirmed configuration |
| Cached pages work | Uncached request path | Representative public and admin requests |
Identify the layer producing the response
The error page, response headers and request identifier may point toward a CDN, reverse proxy or host. Compare that information with the provider’s logs and current documentation.
A site can use more than one gateway: a CDN may contact a host’s web server, which then contacts PHP-FPM. A failure at either exchange can ultimately appear to the visitor as a gateway error.
For that reason, removing the CDN or editing WordPress URLs is not a sensible first response. Find out whether the origin returned a failure or whether the gateway could not obtain a usable response from it.
Compare ordinary pages with the failing operation
Try an ordinary public page and the relevant admin action once, without repeatedly restarting the workload. Cached public pages can work while uncached requests fail, so a working homepage does not rule out an application problem.
If only an import fails, note its size and stage. If all dynamic requests fail, ask the host about PHP service health, upstream connectivity and worker availability at that time.
Other error codes need their own interpretation. A timeout may be reported as 504 by some layers. An origin connectivity problem may produce a provider-specific code. Use the response you actually received rather than assuming all server errors are identical.
Use server logs to explain the exchange
Ask for the upstream finding: refused connection, early closure, invalid response or another logged condition. Match it with PHP errors and the exact request time. A restart can restore service temporarily, but the repeated failure needs its recorded cause.
Messages about connection refusal, an upstream closing early or an invalid response can help locate the failure. A PHP memory error or crash at the same time may explain why the upstream did not complete normally.
On managed hosting, ask the provider to inspect the web-server and PHP logs together. Restarting a service might restore access temporarily, but repeated restarts do not explain why it keeps failing.
Keep timestamp comparisons consistent. A log in another time zone can make an apparently unrelated event look like the cause or hide the actual event.
Check workload and recent changes
Record the job stage, recent deployment and resource activity during failure. Test a suspected feature on a suitable staging copy where possible. If the operation is too large for one request, investigate its supported batching or background design rather than increasing unrelated settings.
Backups, image processing, imports and store activity can compete for resources. Compare the failure with CPU, memory, worker queues and database activity rather than increasing every limit.
A recently changed plugin is a useful lead. Test it on a staging copy when possible and preserve the existing configuration. Disabling live payment or order components can interrupt the business even when the goal is diagnosis.
If logs identify a particular operation, investigate that operation’s settings and implementation. A batch import may need smaller batches or a background process rather than one long browser request.
After a migration, check the origin configuration
Confirm that the proxy points to the current origin and uses the connection settings the host expects. Hostname routing and TLS settings can matter as well as the IP address.
Ask the host to compare origin responses with the correct hostname. Directly opening an IP address can test a different virtual host and produce a misleading result. Avoid publicly exposing an origin just to perform a casual comparison.
Verify recovery before clearing the evidence
Once the underlying problem is corrected, refresh any relevant cached error response if necessary. Clearing every cache before inspecting logs can remove useful context without fixing the upstream failure.
Repeat the original operation and check ordinary public and admin requests. A successful small action does not establish that the previously failing import now completes. If the error persists, provide the host with the URL, request identifier, timestamps and workload details, with credentials and customer information removed.
Further reading
- WordPress Memory Exhausted Error
- WordPress Maximum Execution Time Exceeded
- WordPress 500 Internal Server Error
- WordPress 503 Service Unavailable
- WordPress 504 Gateway Timeout
- Cloudflare: 502 and 504 errors
Confirm dynamic requests and the original job
After correcting the identified exchange, verify public and admin requests and the representative workload that failed. Refresh a relevant cached error only when needed. Keep the confirmed gateway, upstream condition and correction in the incident record.