Hello!
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
http://nginx.org/r/proxy_next_upstream.
The behaviour you describe suggests that your configuration has
both "proxy_next_upstream http_500" and multiple servers.
--
Maxim Dounin
http://nginx.org/
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
