If a site begins returning 502 after a PHP version switch or server change, record the changed setting and failure time before rolling back. The gateway received an invalid upstream response; the status alone does not identify the faulty WordPress component.
Use the maintenance history and service logs to recover the affected path and plan a verified compatibility repair.
Guide reviewed: October 8, 2026. Interface labels may vary by version, account and device.
Quick diagnosis
| Evidence | Investigation | Useful comparison |
|---|---|---|
| All dynamic pages fail after a PHP switch | PHP service startup and web-server routing | Previous and new service configuration. |
| One feature fails | Feature-specific upstream or application error | Same operation on staging. |
| Cached pages still load | Dynamic origin health | Dashboard or another uncached request. |
| Rollback restores service | Compatibility and deployment difference | One changed variable with matched logs. |
Keep the change and the failure time together
Write down what changed: a PHP version, a server configuration, a deployment, or the destination used by a proxy. Record when the change completed and when the first failed request was observed. Those times help the host compare the relevant logs.
Also note the scope. If every public page fails, the provider may investigate a shared upstream service. If only one feature fails, its request path deserves attention. Include an ordinary page that still works when you report a partial failure.
For example, a homepage that loads while a generated report returns 502 gives the developer a different starting point from a site that fails on every request. Neither case is explained by the number alone.
Ask which gateway returned the error
After a PHP change: have the host confirm the selected PHP service is running and that the web server points to its correct socket or destination. A logged application fatal error calls for a different repair from a failed connection to that service.
Your website may have several components between the visitor and WordPress. Ask the hosting provider which one produced the 502 and which upstream response it considered invalid. The answer should identify the failing connection or service rather than merely repeat the browser message.
After a PHP change, ask whether the intended PHP service started successfully and whether its configuration matches the web server’s routing. This is an investigation to be confirmed by the host, not an assumption that every 502 is a PHP fault.
Share a request identifier from the error page if one is available, along with the hostname and exact time with its time zone. Do not post account paths, credentials, or private logs publicly.
Review application compatibility when evidence points there
If the service logs connect the failure to an application error after the PHP change, have the developer review the named component and its supported environment. A theme or plugin may need a compatible version or a code correction.
Use the legitimate software source and preserve a backup before replacing files. A staging copy is useful for comparing the new environment with the previous working setup. It lets you test the relevant feature without repeatedly interrupting the live site.
Do not treat a temporary return to the previous environment as the whole plan. If that restores service, record the result and arrange the compatibility work needed for the intended environment. A rollback is evidence and a recovery measure; it does not explain every technical detail by itself.
Use a controlled recovery
- Keep the previous configuration and a usable backup.
- Identify the gateway, upstream and failed request.
- Reverse a confirmed suspect change when appropriate.
- Reproduce and fix compatibility on staging before another deployment.
If the outage affects the whole website, coordinate recovery with the host or maintainer who made the change. Keep the previous configuration available and agree which change can be reversed safely. Reversing several unrelated settings at once makes it harder to identify what restored service.
For a problem limited to one feature, avoid taking unrelated functions offline without a reason. Have the developer reproduce the failing request and compare its logs. A focused test may reveal a different upstream destination or a feature-specific error.
Increasing every timeout is not a direct response to an invalid upstream response. Ask what the logs show first. A different status such as 504 concerns a different failure, and the troubleshooting should follow the observed response.
Check the website’s actual work
After the correction, verify a public page and the action that originally failed. For a shop, use an appropriate test workflow for cart or checkout. For a report or form, inspect the expected output rather than checking only that the homepage opens.
If the issue was intermittent, watch a comparable period and keep any new failure time. The host can compare it with the earlier incident instead of starting from an unrelated log entry.
Finally, record the responsible component, the confirmed cause, and the recovery. A note such as “the PHP service did not start with the new configuration” is far more useful than “502 fixed after several changes.” It makes future maintenance easier to plan and verify.
Reference: MDN’s explanation of HTTP 502 Bad Gateway.
Confirm the repaired environment
Open a dynamic page and repeat the original failed feature. Inspect the expected output and fresh logs, then record the component and confirmed change that restored service. If a rollback was needed, keep the remaining upgrade work visible in maintenance notes.