Trace WordPress 502 and 504 Errors Across the Proxy–PHP Boundary

A gateway error is reported by a server that waited for another server. A 502 commonly means the upstream response was invalid or unavailable; a 504 means the gateway waited too long. Both require timestamps from more than one log.

Use the sequence below as a diagnostic method, not as a promise that one setting fits every host; verify its example paths, privileges, and backup assumptions while working to distinguish an unavailable PHP upstream from a slow request and identify whether the proxy, PHP-FPM, database, or application exhausted its budget.

Likely failure paths

• PHP-FPM has no healthy workers, restarted, or uses a socket the web server cannot reach.
• A slow database query or external HTTP call exceeds the proxy timeout.
• Traffic or background work consumes workers until ordinary page requests queue behind it.

The branches are ordered to protect the strongest evidence around this possibility: pHP-FPM has no healthy workers, restarted, or uses a socket the web server cannot reach. The observed scope and logs—not a familiar-looking error screen—decide which one applies.

Runtime incidents cross several boundaries: the browser reports an HTTP result, the web server hands work to PHP, and WordPress then loads core, plugins, the theme, and data; evidence from the earliest failing boundary is more useful than the component visible on screen; in this guide, the practical goal is to distinguish an unavailable PHP upstream from a slow request and identify whether the proxy, PHP-FPM, database, or application exhausted its budget.

A controlled investigation

1. Compare the Server, status, and timing for a static asset, a simple PHP endpoint supplied by the host, and a WordPress page.
2. Read proxy and PHP-FPM logs for the same request ID or second; look for upstream timeout, connection refused, or worker exhaustion.
3. Check database latency and active connections before increasing timeouts.
4. Disable external calls only in staging and measure whether time to first byte changes.

The sequence moves from observation toward intervention. Preserve the result of the final check—disable external calls only in staging and measure whether time to first byte changes—because it provides a useful comparison after the repair.

Make the smallest durable change

1. Restore the upstream socket/service configuration if the proxy cannot connect.
2. Remove the slow operation from the web request or bound its external timeout.
3. Scale worker capacity only after measuring memory per worker and database limits; more workers can move the failure downstream.

Before applying “Restore the upstream socket/service configuration if the proxy cannot connect,” name its rollback point and the evidence that will count as success. Afterward, repeat the original request and specifically check whether you can repeat the exact slow route several times from outside the origin network; a changed symptom at that point is new evidence, not permission to make several more changes at once.

curl -sS -o /dev/null \
  -w 'status=%{http_code} connect=%{time_connect} ttfb=%{time_starttransfer} total=%{time_total}\n' \
  'https://example.com/slow-route/?bypass_test_cache=1'

Close the incident with evidence

• Repeat the exact slow route several times from outside the origin network.
• Confirm proxy, PHP, and database queues remain below their configured limits during the test.
• Check that the fix improves successful response time rather than merely extending the wait.

One successful refresh is not closure. Keep the incident open until you can also confirm proxy, PHP, and database queues remain below their configured limits during the test, adjacent paths have not regressed, temporary diagnostics are gone, and another operator can explain what changed.

Prepare a useful escalation if the boundary is outside your control

A hosting escalation should include the UTC timestamp, affected URL, response status, request or trace ID when available, PHP version, WordPress version, and the first relevant log entry; redact cookies, passwords, tokens, database credentials, and personal data; include the result of this first observation: compare the Server, status, and timing for a static asset, a simple PHP endpoint supplied by the host, and a WordPress page.

State what was tested, including the result of “Compare the `Server`, status, and timing for a static asset, a simple PHP endpoint supplied by the host, and a WordPress page,” and what changed between attempts; evidence tied to that observation is safer and more actionable than granting broad access or sending an unnecessary full database export.

Do not trade visibility for a green screen

• Do not set every timeout to several minutes; visitors and workers will remain trapped longer.
• Do not purge caches until uncached origin behavior is measured.

Primary references

• WordPress performance — official reference consulted for this guide.
• HTTP status reference — official reference consulted for this guide.

Editorial note: The scenario above illustrates how to approach “Restore the upstream socket/service configuration if the proxy cannot connect”; it is a documented example, not a claim about a reader’s server, so verify the cited documentation, take the appropriate backup, and follow the real environment’s access and change-control rules.