Find whether the upstream PHP application, database or external network call exceeds the reverse proxy timeout.
Recognize the symptoms before changing settings
The same visible error can originate in different layers. Your first objective is to identify whether the failure is specific to a route, a user action, a hosting component or a recent change. Do not treat a browser message as a complete diagnosis.
- The browser receives HTTP 504 instead of a completed page.
- Slow admin screens or WooCommerce checkout may time out at a consistent threshold.
- A CDN shows 504 while origin sometimes loads.
Record the original URL, time of failure, browser or HTTP error and the last change that occurred before the issue began. These observations make later comparisons reliable, especially when caching or multiple servers are involved.
Before you change anything
If the site is taking payments or sending messages, confirm whether an operation may have already completed before resubmitting it. Make one isolated change at a time, then test the original failure again.
Diagnosis: find the layer that actually failed
Work through these plausible causes in evidence-first order. More than one can coexist, but fixing the first confirmed cause is safer than making several speculative adjustments.
Common underlying causes
- PHP-FPM worker stalls or request queue buildup.
- Slow database query or remote API request.
- Load balancer/edge cannot reach healthy origin promptly.
- Misconfigured upstream network or restrictive timeout.
Three checks that narrow the problem
- Identify which proxy generated the 504.
- Compare origin logs with proxy total/upstream response time.
- See whether static content succeeds while dynamic routes time out.
The relevant response, request log and configuration source together provide better evidence than a generic error screenshot. If you cannot access logs, gather the failing URL and timestamp and request the corresponding records from your hosting provider.
How to interpret conflicting results
If the first check points toward php-fpm worker stalls or request queue buildup, focus on reproducing that condition without changing unrelated settings. A quick improvement after a targeted test is useful evidence but not yet proof that the root cause is removed.
If your second check suggests slow database query or remote api request, collect the corresponding service or application log and compare what happens immediately before and after the failed request. This prevents mistaking correlation for cause.
If neither case fits, consider misconfigured upstream network or restrictive timeout. Work from the outside in: DNS and connection, web server and proxy, PHP/WordPress runtime, then the affected plugin, theme or data. When a check gives inconclusive results, record that uncertainty instead of labelling it a confirmed fix.
Step-by-Step Troubleshooting
Choose the safest method for your access level. Use the Beginner tab for recovery and the Advanced tab for log-based diagnosis and targeted fixes.
Capture the exact timed-out request
Record URL, HTTP method, request time and what user action caused it. Avoid reproducing expensive checkout or payment submissions repeatedly.
Check hosting health and slow events
Look for worker saturation, slow PHP requests, database spikes and external call timeouts. If only one admin action fails, prioritize that request path.
Reduce the slow work
Temporarily pause the confirmed excessive background task or shrink a batch on staging. Retest the identical operation.
Inspect upstream response timing
Correlate web-server error log and PHP-FPM slow log to find what phase blocked. Use appropriate access metrics.
curl -o /dev/null -sS -w 'HTTP %{http_code} total %{time_total}s\n' https://example.com/Check queue pressure and database contention
Identify max-children reached notices, locked queries and slow external dependencies. Resolve the original contention rather than only increasing proxy_read_timeout.
Set realistic per-layer timeouts
Only after optimizing, align proxy, load balancer, PHP and application timeouts so authorized bounded operations complete safely.
How to verify the repair
Do not call a problem solved solely because one browser reload succeeds. Retest the exact workflow that failed, then include a normal public request and one administrator action. Keep the site cache and authenticated/anonymous behavior in mind.
- The original request finishes before its planned service timeout.
- No new 504 errors or duplicate transaction effects appear in logs.
Complete the checklist below as you test. The progress indicator belongs to this article and is intended as a reading aid, not a guarantee of server health.
Solution Checklist
If it still fails: rollback and escalation
If the symptom remains, stop repeating the same changes. Save the newest error evidence and compare it with the pre-change state; the unchanged behavior is a useful clue that the current hypothesis was wrong.
- Revert changed proxy timeouts if worker use rises.
- Rollback newly deployed code that caused the slow request.
When escalating to your provider or developer, send the time, affected URL, relevant status/log excerpt, environment version and the specific changes already tried. Remove passwords, session cookies, personal information and secret keys from the report.
How to prevent the error from returning
- Apply explicit network timeouts to external calls.
- Use background jobs and monitor p95/p99 origin latency.
After a successful fix, make a brief incident note: symptom, root cause, effective change, verification test and rollback instructions. This is much more useful than keeping a list of unverified tweaks.
Further reading: official documentation
This guide explains diagnostic choices rather than guaranteeing that one setting will work on every host. Verify the actual software versions, hosting environment and provider restrictions before applying examples.