proxy_read_timeout vs proxy_next_upstream_timeout
B.R.
reallfqq-nginx at yahoo.fr
Thu Mar 31 22:32:35 UTC 2016
On Thu, Mar 31, 2016 at 6:54 PM, Frank Liu <gfrankliu at gmail.com> wrote:
> Given this config:
> proxy_next_upstream timeout;
> proxy_next_upstream_timeout 50;
> proxy_connect_timeout 10;
> proxy_read_timeout 100;
> If upstream has issues causing connect timeout, nginx will re-try 5
> upstream servers until hitting 50, then fail.
>
http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_next_upstream_timeout
'[...] hitting 50s [...]' (cf. http://nginx.org/en/docs/syntax.html)
> If one upstream has issues causing read timeout, nginx will keep wait to
> read, until 100, then timeout,
>
http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout
nginx will wait for a maximum of 100s between two successful read
operations (or before the first one) and will fail if exceeded.
> 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?
>
http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_next_upstream
The 'timeout' property regroups conneciton timeout and header read timeout.
Content read timeout is set by proxy_read_timeout
<http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout>
(default 60s)
---
*B. R.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20160401/3c2751c4/attachment.html>
More information about the nginx
mailing list