proxy_read_timeout vs proxy_next_upstream_timeout
gfrankliu at gmail.com
Thu Mar 31 16:54:39 UTC 2016
Given this config:
If upstream has issues causing connect timeout, nginx will re-try 5
upstream servers until hitting 50, then fail.
If one upstream has issues causing read timeout, nginx will keep wait to
read, until 100, then timeout, then checks the proxy_next_upstream_timeout
which is 50 and already passed, so nginx won't retry next upstream.
I am trying to setup nginx to only retry on connect timeout, not read
timeout, will above work?
On Tue, Mar 29, 2016 at 10:12 AM, B.R. <reallfqq-nginx at yahoo.fr> wrote:
> Those directives works at very different levels.
> allocates a time for nginx to find a proper upstream (configured with
> By default, there is no limit, making nginx attempting every upstream one
> after the other until finding one healthy or running out of valid
> upstreams, which could take a while (maybe even an infinite time with
> health checks? Speculating here).
> sets a timer 'between two read operations', say the docs, which is closer
> to your question.
> Those are to be defined, but I suppose that when there is nothing more to
> read in the buffer awaiting backend response, and the response is not
> complete, this timer kicks in and effectively close the connection,
> returning an error.
> They are not working at the same level at all: there is no way to mistake
> one for the other.
> *B. R.*
> On Tue, Mar 29, 2016 at 5:03 PM, Frank Liu <gfrankliu at gmail.com> wrote:
>> If you set read timeout 2 min and next upstream timeout 50 seconds, will
>> nginx break the current connection at 50 second or will it let the read
>> finish until 2min?
>> nginx mailing list
>> nginx at nginx.org
> nginx mailing list
> nginx at nginx.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the nginx