we need an explicit max_fails flag to allow origin error through?

Maxim Dounin mdounin at mdounin.ru
Thu Sep 15 17:36:18 UTC 2016


On Thu, Sep 15, 2016 at 02:55:47PM +0100, Mark McDonnell wrote:

> We have an upstream that we know is serving a 500 error.
> We've noticed that NGINX is serving up a nginx specific "502 Bad Gateway"
> page instead of showing the actual Apache origin error that we'd expect to
> come through.
> To solve this we've added `max_fail: 0` onto the upstream server (there is
> only one server inside the upstream block) and now the original apache
> error page comes through.
> I'm not sure why that is for two reasons:
>    1. because max_fail should have no effect on the behaviour of something
>    like proxy_intercept_errors (which is disabled/off by default, meaning any
>    errors coming from an upstream should be proxied 'as is' to the client)

When all servers in the upstream block are marked failed and/or 
nginx failed to get a valid answer from any of the working 
servers, nginx will just return 502 himself.  And this is probably 
what happens in your case.

>    2. because max_fail should (according to nginx's docs) be a no-op... "If
>    there is only a single server in a group, max_fails, fail_timeout and
>    slow_start parameters are ignored, and such a server will never be
>    considered unavailable"

The "max_fails" parameter is expected to be a nop with only one 
server in the upstream block and assuming standard balancers.

Note though, that:

- non-standard balancers may behave differently;

- backup servers are counted - if you have backup servers, nginx 
  will honor max_fails;

- if a name is used in the "server" directive, and the name 
  resolves to multiple addresses, this means multiple servers 
  from nginx point of view.

The latter can be easily hit by using names like "localhost" in 
the configuration.

Note well that just 500 error from an upstream server is not 
something that nginx will consider to be an error unless you've 
explicitly configured it using proxy_next_upstream, see 

The behaviour you describe suggests that your configuration has 
both "proxy_next_upstream http_500" and multiple servers.

Maxim Dounin

More information about the nginx mailing list