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 [email protected] http://mailman.nginx.org/mailman/listinfo/nginx
