s秒、m分钟
语法 | 释义 | |
---|---|---|
client_header_timeout |
获得请求头 | |
client_body_timeout |
获得请求体 | |
proxy_connect_timeout |
与下一层连接 | |
proxy_read_timeout |
两次reading操作的时间 | |
proxy_send_timeout |
两次write操作的时间 | |
proxy_timeout |
综合的超时时间 |
client_header_timeout
# 语法 client_header_timeout time
# 默认值 60s
# 上下文 http server(指可以放在http块和server块)
# 说明 指定等待client发送一个请求头的超时时间(例如:GET / HTTP/1.1).
# 仅当在一次read中,没有收到请求头,才会算成超时。
# 如果在超时时间内,client没发送任何东西,nginx返回HTTP状态码408(“Request timed out”)
client_body_timeout
# 语法 client_body_timeout time
# 默认值 60s
# 上下文 http server location
# 说明 该指令设置请求体(request body)的读超时时间。
# 仅当在一次readstep中,没有得到请求体,就会设为超时。
# 超时后,nginx返回HTTP状态码408(“Request timed out”)
keepalive_timeout (长连接类型)
# 语法 keepalive_timeout timeout [ header_timeout ]
# 默认值 75s
# 上下文 http server location
# 说明 第一个参数指定了与client的keep-alive连接超时时间。
# 服务器将会在这个时间后关闭连接。
# 可选的第二个参数指定了在响应头Keep-Alive: timeout=time中的time值。
# 这个头能够让一些浏览器主动关闭连接,这样服务器就不必要去关闭连接了。
# 没有这个参数,nginx不会发送Keep-Alive响应头(
# 尽管并不是由这个头来决定连接是否“keep-alive”)
# (服务器在返回数据给用户时,在头header文件中会添加keepalive字段,75s,浏览器在这个时间后能够主动关闭连接)
# 两个参数的值可并不相同
# 注意不同浏览器怎么处理“keep-alive”头
# MSIE和Opera忽略掉"Keep-Alive: timeout=<N>" header.
# MSIE保持连接大约60-65秒,然后发送TCP RST
# Opera永久保持长连接
# Mozilla keeps the connection alive for N plus about 1-10 seconds.
# Konqueror保持长连接N秒
lingering_timeout
# 语法 lingering_timeout time
# 默认值 5s
# 上下文 http server location
# 说明 lingering_close生效后,在关闭连接前,会检测是否有用户发送的数据到达服务器,
# 如果超过lingering_timeout时间后还没有数据可读,就直接关闭连接;
# 否则,必须在读取完连接缓冲区上的数据并丢弃掉后才会关闭连接。
resolver_timeout
# 语法 resolver_timeout time
# 默认值 30s
# 上下文 http server location
# 说明 该指令设置DNS解析超时时间
# proxy转发模块的超时设置:
proxy_connect_timeout
# 语法 proxy_connect_timeout time
# 默认值 60s
# 上下文 http server location
# 说明 该指令设置与upstream server的连接超时时间,有必要记住,这个超时不能超过75秒。
# 这个不是等待后端返回页面的时间,那是由proxy_read_timeout声明的。
# 如果你的upstream服务器起来了,但是hanging住了
# (例如,没有足够的线程处理请求,所以把你的请求放到请求池里稍后处理),
# 那么这个声明是没有用的,因为与upstream服务器的连接已经建立了。
proxy_read_timeout
# 语法 proxy_read_timeout time
# 默认值 60s
# 上下文 http server location
# 说明 该指令设置与代理服务器的读超时时间。
# 它决定了nginx会等待多长时间来获得请求的响应。
# 这个时间不是获得整个response的时间,而是两次reading操作的时间。
# (??什么是两次reading操作的时间)
proxy_send_timeout
# 语法 proxy_send_timeout time
# 默认值 60s
# 上下文 http server location
# 说明 这个指定设置了发送请求给upstream服务器的超时时间。
# 超时设置不是为了整个发送期间,而是在两次write操作期间。
# 如果超时后,upstream没有收到新的数据,nginx会关闭连接
proxy_upstream_fail_timeout(fail_timeout)
# 语法 server address [fail_timeout=30s]
# 默认值 10s
# 上下文 upstream
# 说明 Upstream模块下 server指令的参数,
# 设置了某一个upstream后端失败了指定次数(max_fails)后,
# 该后端不可操作的时间,默认为10秒
# 负载均衡配置时的2个参数:fail_timeout和max_fails
# 这2个参数一起配合,
# 来控制nginx怎样认为upstream中的某个server是失效的当在fail_timeout的时间内,
# 某个server连接失败了max_fails次,则nginx会认为该server不工作了。
# 同时,在接下来的 fail_timeout时间内,nginx不再将请求分发给失效的server。
# 个人认为,nginx不应该把这2个时间用同一个参数fail_timeout来控制,
# 要是能再增加一个fail_time,来控制接下来的多长时间内,不再使用down掉的server就更好了~
# 如果不设置这2个参数,fail_timeout默认为10s,max_fails默认为1。
# 就是说,只要某个server失效一次,则在接下来的10s内,就不会分发请求到该server上
send_timeout
# 默认:send_timeout 60;
# send_timeout 指定客户端的响应超时时间。
# 这个设置不会用于整个转发器,而是在两次客户端读取操作之间。
# 如果在这段时间内,客户端没有读取任何数据,nginx就会关闭连接。
# 一般看来, 这种情况可能是由于nginx默认的fastcgi进程响应的缓冲区太小造成的,
# 这将导致fastcgi进程被挂起, 如果你的fastcgi服务对这个挂起处理的不好,
# 那么最后就极有可能导致504 Gateway Time-out
# 现在的网站, 尤其某些论坛有大量的回复和很多内容的, 一个页面甚至有几百K
# 默认的fastcgi进程响应的缓冲区是8K, 我们可以设置大点
# 在nginx.conf里, 加入:
fastcgi_buffers 8 128k
# 这表示设置fastcgi缓冲区为8×128k
# 当然如果您在进行某一项即时的操作, 可能需要nginx的超时参数调大点, 例如设置成60秒:
send_timeout 60;