> Normally timeouts results in 504, and if you see 500 this might > indicate that in fact request failed not due to a timeout, but > e.g. due too loop detected. This in turn might mean that there > were more than one request to the server X which failed. > > Try looking into error_log to see what's going on. You're correct - its a 504. [16/Nov/2012:12:40:48 +0100]by pliljenberg - Nginx Mailing List - English
The requests before (for more than 30sec) to the server X are ok, this is the diet request generating a 500 response (from the timeout). Son up til this point all looks good - which is why I don't understand why nginx considers the server inactive after the first fail :)by pliljenberg - Nginx Mailing List - English
Thanks for the reply. >> What we're actually seeing is that if a a request takes 300+ seconds, the >> backend is immediately set as disabled and all further requests are send to >> the other backend... >> Are we missing something or is this the correct behaviour for nginx? >Are you looking at the normally working backend server, or a >server which was alreadby pliljenberg - Nginx Mailing List - English
We're using nginx as a loadbalancer and we're seeing some strange behaviour when one of our backend servers takes a long time to respond to a request. We have a configuration like this: upstream handlehttp { ip_hash; server XXX max_fails=3 fail_timeout=30s; server YYY max_fails=3 fail_timeout=30s; } server { location / { try_files $uri @backend; }by pliljenberg - Nginx Mailing List - English