proxy_read_timeout vs proxy_next_upstream_timeout

[B.R.]

Those directives works at very different levels.

proxy_next_upstream_timeout
<http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_next_upstream_timeout>
allocates a time for nginx to find a proper upstream (configured with
proxy_next_upstream
<http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_next_upstream>
).
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).

proxy_read_timeout
<http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout>
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:

> Hi
>
> 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?
>
> Thanks
> Frank
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20160329/61f71eae/attachment.html>