How are downed upstream servers detected as alive again?

Rt Ibmer rtibmx at
Thu Apr 24 08:29:40 MSD 2008

> This also explains, in the writing about fail_timeout, how long
> nginx considers a failed upstream server down for.Thank you for the clarification. Wow, I did not realize that is what the fail_timeout was for. I had seen that, but thought it was related to how long the timeout had to be before being considered down.

I really wish it worked differently.  For instance with Pound, you specify a retry interval and it automatically checks downed servers at that interval without first redirecting any requests to it. Any chance we may see that type of enhancement in the future?

For instance in my case I'll then want to keep the fail_timeout short, like 60 seconds.  So this means every 60 seconds nginx will assume the downed server is back up, and send requests to it only to find that it is not back up yet and causing users to experience the delays. I will use the other params to keep the delays short (like 3s).  However every minute some users will be experiencing a 3s delay.

I've recently switched to nginx from pound and let me just say that nginx is so much better in just about every other way its not even a contest.  However I must say that pound does have a clear advantage in this regarding, in that it will not direct clients to a downed box until some other background process it runs verifies it can get a response. At least, that is my understanding of how things went.

For as robust of a package that nginx is and performance oriented it is a bit surprising that it would blindly assume a downed box is back up just because x interval has passed.  Would love to see it verify things first before redirecting real users to it.  Thanks for the opportunity to provide feedback and a truly incredible tool!

Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

More information about the nginx mailing list