DEV Community

thestackunderflow
thestackunderflow

Posted on Originally published at thestackunderflow.com

Where NGINX 502 and 504 Actually Come From

I like to see all systems as a state machines. I drew open-source nginx (stable 1.30) as a hierarchical state machine and checked each step against nginx.org docs, CHANGES and the source:

  • Reload: the master checks and applies the new config; if that fails it rolls back and old workers keep serving; if it succeeds, new workers start and old ones finish their requests.
  • bind() failure is retried 5 times, 500 ms apart, before "still could not bind()".
  • 11 phases; a rewrite that changes the URI goes back to FIND_CONFIG, max 10 times, then 500.
  • Since 1.29.7 (so stable 1.30), proxy keepalive + HTTP/1.1 are the default and Connection isn't sent.
  • proxy_next_upstream defaults to "error timeout"; POST/LOCK/PATCH already sent aren't retried.
  • In ngx_http_upstream_next(), timeouts map to 504; connection errors, invalid headers and "no live upstreams" map to 502.
  • Passive health: max_fails 1 / fail_timeout 10 s by default; active health_check is NGINX Plus.

The full write-up, with every source, is on my site: https://thestackunderflow.com/tutorials/how-nginx-handles-a-request-502-vs-504/

Top comments (0)