SECURITY WARNING: Never run commands you don't understand. Always review code before execution. Use at your own risk.
Proxy New Added 8 September 2026

Nginx: no live upstreams while connecting to upstream

Every server in the upstream block has been marked down by passive health checks. After max_fails failures within fail_timeout nginx stops sending traffic for that window, so one burst of errors can take out the whole pool and keep it out even after the backends recover.

Quick fix

Read the commands before running them. Anything that restarts a service, deletes data or changes permissions should be tried on a non-production system first.

Quick fix
# Confirm the backends are actually up from the proxy itself
curl -sv http://10.0.1.10:8080/healthz
tail -f /var/log/nginx/error.log | grep upstream

# Tune the passive check so a blip does not eject everything
upstream app {
    server 10.0.1.10:8080 max_fails=3 fail_timeout=10s;
    server 10.0.1.11:8080 max_fails=3 fail_timeout=10s;
    keepalive 32;
}

# A resolver is required for names that change, or nginx caches the IP
# from startup forever
resolver 10.0.0.2 valid=30s;
set $backend "app.internal";
proxy_pass http://$backend;

How to diagnose Proxy errors

A proxy error tells you about the proxy's relationship with the upstream, not about the upstream's business logic. nginx's 502 means it could not get a valid response; 504 means the upstream did not answer in time; Envoy's flag codes (UH no healthy upstream, UF upstream connection failure, NR no route) are far more precise than the status code. Reading those flags is the fastest path to a diagnosis.

If the quick fix above does not resolve it, work through these steps. They apply to this whole class of error, not just to this one message, which is usually what saves the time.

  1. Include upstream detail in the access log format: $upstream_addr, $upstream_status and $upstream_response_time in nginx turn a generic 502 into a specific one.
  2. Bypass the proxy and call the upstream directly from the proxy host. If that works, the issue is proxy configuration: timeouts, buffers, DNS caching or TLS to the backend.
  3. For Envoy, read the response flags in the access log rather than the status code. UH, UF, UO and NR each have distinct fixes.
  4. Check that the proxy re-resolves DNS. nginx caches upstream IPs at startup by default, which breaks when backends move. Use a resolver directive with a variable upstream.
  5. For header-size and body-size errors, raise the limit at every layer; CDN, load balancer and origin each enforce their own.

Tools worth reaching for

  • nginx -T
  • envoy access logs (response flags)
  • haproxy -c -f
  • curl --resolve
  • traefik dashboard

Authoritative references

Primary documentation for this error, worth reading before applying any fix in production.

nginx.org

Related Proxy errors

See all 17 Proxy errors →

Browse other categories

Something missing or wrong?

This entry is maintained by hand. If the fix is out of date, incomplete, or you have a better one, email a correction and it will be reviewed.