Introduction

The Nginx no live upstreams error means Nginx has decided none of the configured backend servers are currently usable. That can happen because every upstream is actually down, but it can also happen when health assumptions, fail counts, or network reachability make healthy backends look dead. The fix is to confirm whether the problem is backend availability, upstream configuration, or how Nginx is marking servers unavailable.

Symptoms

  • Nginx returns 502 or similar gateway failures with no live upstreams in the error log
  • Requests fail only for routes served through a specific upstream block
  • The problem started after a deploy, backend restart, or infrastructure change
  • Some origin servers look healthy from their own logs, but Nginx still refuses to send traffic
  • Restarting Nginx helps briefly or not at all

Common Causes

  • All backend servers in the upstream group are actually down or refusing connections
  • Nginx upstream definitions point at the wrong hostnames, IPs, or ports
  • Fail counts or timeout settings mark every backend as unavailable too aggressively
  • DNS or service discovery changed and Nginx is still routing to unreachable targets
  • Firewalls or network rules block Nginx from reaching the upstream servers

Step-by-Step Fix

  1. Identify the exact upstream block and failing routes so you know which backends Nginx has marked unavailable.
  2. Test each configured upstream target directly from the Nginx host to confirm whether it is reachable on the expected host and port.
  3. Review recent backend deploys, restarts, or scaling events that may have removed or replaced the upstream instances.
  4. Check the upstream configuration for wrong ports, stale IPs, DNS resolution drift, or hostnames that no longer map to healthy services.
  5. Inspect fail timeout and max fail settings to see whether Nginx is declaring all backends dead too quickly during transient errors.
  6. Verify any firewall, security group, or network policy change that could block Nginx-to-origin traffic.
  7. Reload Nginx only after the upstream targets and routing definitions are corrected.
  8. Re-test the affected routes and confirm Nginx is once again distributing traffic to healthy backends.
  9. Keep backend health visibility and upstream inventory current so scaling or service changes do not silently leave Nginx with no usable targets.