1. Did your nginx produce the error?
Look at the error page and its headers. A page styled by a CDN or load balancer, or naming another product, did not come from your nginx. The platform page explains how to tell.
- Move to step 2 only when the response has your nginx's own gateway error page or status.
- Foreign page: stop here and contact that service. Application error passed through: go to the application log.
2. Which stage failed, and does it match the code?
Read the error log entry for one known failing request and note its stage. The 502 and 504 guide holds the full reading.
- Connecting plus a 502: go to step 3 only after you have checked the application is running and listening at the address nginx uses.
- Connecting plus a 504: the network path or address is the problem; leave the proxy settings alone and check the host.
- Reading plus a 504: measure the route directly against the application; go to step 3 only if it is slower than the timeout in force.
- Mixed stages across routes: treat each route as its own case from here.
3. Which setting applies to this route?
Work out which location handled the request and what its proxy_pass does to the path. The proxy_pass and location guide holds the rules.
- Go to step 4 when you can name the one location, the proxy_pass form and the timeout or retry setting in force for it.
- If a different location than you expected handled the request, fix the location choice before touching any timeout.
4. Change one thing and prove it
The platform page and the 502 and 504 guide give the test, reload and 20-request routine. Stop and look at the application if the log shows it crashing, and at the host if disk or memory is exhausted.
- Done when the named URLs succeed repeatedly and the error log is quiet for the same window.
- Write down the cause and the old and new values.
5. When to ask for the fixed repair
If the site is behind your own nginx, the upstream is an HTTP service and up to three URLs fail, the fixed nginx repair covers steps 2 to 4 with a cause statement, tests and revert steps, at a published test price of £195. If the cause is the application, the right next step is a bug fix with a regression test. If a process keeps dying, supervising it with systemd is a separate fixed job.
- Prices are untested hypotheses; payment follows sign-off.
- Nothing here is a promise of uptime.
Sources and limits
- nginx: ngx_http_proxy_module Checked 2026-10-11.
- The proxy timeouts and proxy_pass behaviour referred to in the steps.
- nginx: controlling nginx Checked 2026-10-11.
- Reload behaviour and rollback on an invalid configuration.
- MDN: 502 Bad Gateway Checked 2026-10-11.
- The status definitions that start the sequence.