Nginx '504 Gateway Time-out' / error log 'upstream timed out (110: Connection timed out) while reading response header from upstream'. How do I fix slow backends behind nginx?

Cause: nginx (as a reverse proxy) waited for the upstream application longer than its timeout and gave up. The default proxy_read_timeout is 60 seconds; if the backend (Node, Python, PHP-FPM, Java) takes longer to send a response, nginx returns 504. Typical reasons: a slow database query or external API call, a long report/export done inside the request, an overloaded or deadlocked app (all workers busy), or the upstream unreachable at connect time (proxy_connect_timeout). Fix: 1. Read nginx's error log: it names which timeout fired (connect vs reading response header) and which upstream address. Then check the application's own logs and metrics for the same request. 2. Fix the slowness when possible: add indexes, cache, or set timeouts on the app's outbound calls; make sure there are enough app workers/threads for the load. 3. Move genuinely long work out of the request: return 202 Accepted and process in a background job/queue, then poll or notify; stream progress if needed. 4. If a longer wait is legitimate for a specific route, raise the timeout only there, e.g. in a location block: proxy_read_timeout 300s; (and proxy_send_timeout if large uploads are slow). For FastCGI use fastcgi_read_timeout; for uWSGI uwsgi_read_timeout. Reload with nginx -t && nginx -s reload. 5. Keep every hop consistent: a load balancer or CDN in front of nginx (cloud load balancers, Cloudflare) has its own idle timeout that may be shorter and cut the request first. Verify: the slow endpoint returns normally, and nginx's error log no longer shows 'upstream timed out' for it; monitor latency so you notice regressions before they turn into 504s. Sources: https://nginx.org/en/docs/http/ngx_http_proxy_module.html https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/504