nginx和php-fpm连接超时之解决方法nginx和php-fpm连接超时之解决方法二丫风岚百家号前言现在线上系统的架构大致是这样的，除去cache的proxy机器外，还有项目的nginx proxy机器，后面跟nginx webserver + php-fpm。有时候，会看到proxy nginx的日志里面会有各种异常状态码，比如499，502，504等，这些都是什么情况导致的呢？架构示意nginx proxy => nginx webserver => php-fpm状态码说明499：客户端(或者proxy)主动断开连jie502：网关错误(Bad Gateway)504：网关超时：(Gateway Timeout)1 proxy和webserver不能连接1.1 proxy_pass ip不存在：这时候会重复发送arp解析协议，约3秒后超时，proxy返回码为502。1.2 proxy_pass ip存在：webserver机器上端口上没有对应服务；webserver所在机器的内核会直接返回RESET包，没有额外超时，proxy返回码为502。webserver机器端口上有服务，但是iptables DROP了proxy的包；因为webserver drop(iptables -I INPUT -s xxx.xxx.xxx.xxx -j DROP)了proxy的包，proxy会TCP连接不断重试，默认会重试60秒后proxy返回码504，这个重试时间60秒由参数proxy_connect_timeout指定，重试间隔就是TCP的重试间隔(1，2，4...)。如果在超时之前，客户端主动关闭连接(比如停止浏览器的请求)，这个时候proxy会记录 499状态码，而且$request_time 记录的是proxy已经处理的时间，而$upstream_response_time为-。客户端主动关闭后，proxy也不会再向webserver发送重试请求。但是如果你在proxy配置了proxy_ignore_client_abort on，那么即便客户端主动关闭，proxy还是会不停的发送重试请求到webserver，直至超时，记录的状态码为webserver返回的状态码。webserver机器端口有服务，但是iptables reject了proxy的包。因为webserver reject(iptables -I INPUT -s xxx.xxx.xxx.xxx -j REJECT)了proxy的包，与drop不同之处在于，这个时候webserver会返回一个端口不可达的ICMP包给proxy，proxy会重试一次后返回 502 给客户端，超时时间约为1秒。2 proxy和webserver连接正常(请求时间过长)proxy的nginx.conf中的proxy_read_timeout=60webserver的nginx.conf中fastcgi_read_timeout=300php-fpm中的 request_terminate_timeout=120nginx.conf配置文件2.1 php执行时间超过proxy的proxy_read_timeout：假设php-fpm有一个test.php执行时间为100秒，超过了默认的proxy_read_timeout=60，则到1分钟后proxy会关闭到webserver的连接，webserver记录的返回码为499，proxy的返回码为 504，客户端看到的返回码也就是 504。关于proxy_read_timeout要多说一句，在nginx文档中可以看到这个参数的含义是：The timeout is set only between two successive read operations,not for the transmission of the whole response.意思是说并非response的传输超时，而是两次读操作之间的间隔超时。比如在proxy中设置proxy_read_timeout=10，而测试的test.php 如下：这整个请求的响应时间是14秒，其实是不会超时的，因为相邻两次读操作的间隔是7秒小于10秒。注意代码中的ob_flush()和flush()两个函数，其中ob_flush()是为了刷php的缓存，flush()则是为了刷系统层面的缓存。将/etc/php5/fpm/php.ini中设置output_buffering=off，则可以不用调用ob_flush()了，但是flush()还是需要的。如果不flush的话，php会等到整个响应完成才会将数据返回给webserver，webserver再返回给proxy，在没有返回整个响应之前(14秒才能返回)，超过了 proxy_read_timeout的10秒，此时，proxy会关闭和webserver的连接，导致出现504错误。为了这个测试test.php不超时，webserver的nginx还要加一个配置fastcgi_buffering off，因为虽然我们的php返回了数据了，但是webserver的nginx还是缓存了fastcgi的返回，导致没有及时将数据返回给proxy，从而超时。php.ini文件在如上面配置好后，可以发现，浏览器输出了hahahaha after 7s那么问题来了，这两个字符串是同时输出的，并没有像代码中那样隔了7秒，那这个问题是什么导致的呢？答案是proxy的nginx也有缓存配置，需要关闭才能看到先后输出两个字符串的效果。nginx proxy的缓存配置为proxy_buffering off，这样你就能看到先后输出两个字符串的效果了。2.2 php执行时间超过webserver的fastcgi_read_timeout：设置fastcgi_read_timeout=10，test.php执行时间100秒，则10秒后webserver会关闭和PHP的连接，webserver记录日志的返回码为 504，proxy日志的返回码也是 504。2.3 php执行时间超过php-fpm的request_terminate_timeout：设置request_terminate_timeout=5，test.php还是执行100秒，可以发现5秒之后，php-fpm会终止对应的php子进程，webserver日志的状态码为 404，proxy的日志的状态码也是 404。注：经测试，在php-fpm模式中，php.ini中的max_execution_time参数没有什么效果。3 关于文件数问题Linux里面的一些限制参数可以通过ulimit -a查看，比如我的debian8.2系统的输出如下：# ulimit -acore file size (blocks, -c) 0data seg size (kbytes, -d) unlimitedscheduling priority (-e) 0file size (blocks, -f) unlimitedpending signals (-i) 96537max locked memory (kbytes, -l) 64max memory size (kbytes, -m) unlimitedopen files (-n) 1000000pipe size (512 bytes, -p) 8POSIX message queues (bytes, -q) 819200real-time priority (-r) 0stack size (kbytes, -s) 8192cpu time (seconds, -t) unlimitedmax user processes (-u) 96537virtual memory (kbytes, -v) unlimitedfile locks (-x) unlimited其中open files是一个进程可以同时打开的文件数，超过则会报too many open files错误，修改可以通过ulimit -n xxx来实现。而max user processes则是用户最多创建的进程数。另外，系统允许打开的最大文件数在配置file-max中。# cat /proc/sys/fs/file-max2471221修改file-max可以通过# sysctl -w fs.file-max=1000000修改，永久生效需要在/etc/sysctl.conf中加入这行fs.file-max=1000000然后sysctl -p即可。要针对用户限制文件数之类的，可以修改/etc/security/limits.conf，内容格式如下：
## 比如限制 bob这个用户的一个进程同时打开的文件数## Example hard limit for max opened filesbob hard nofile 4096## Example soft limit for max opened filesbob soft nofile 1024nginx配置中的worker_rlimit_nofile可以配置为open files这个值。ulimit -a命令sysctl.conf文件本文由百家号作者上传并发布，百家号仅提供信息发布平台。文章仅代表作者个人观点，不代表百度立场。未经作者许可，不得转载。二丫风岚百家号最近更新：简介:只想用自己的方式道尽世态炎凉，警示只用作者最新文章相关文章php python mysql linux 互联网开发 游戏运营 架构分享，工作QQ:
nginx中的超时设置
nginx使用proxy模块时，默认的读取超时时间是60s。1. send_timeout
syntax: send_timeout the time
default: send_timeout 60
context: http, server, location
Directive assigns response timeout to client. Timeout is established not on entire transfer of answer, but only between two operations of reading, if after this time client will take nothing, then nginx is shutting down the connection.
2. 负载均衡配置时的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上
3. proxy模块的 proxy_connect_timeout
syntax: proxy_connect_timeout timeout_in_seconds
context: http, server, location
This directive assigns a timeout for the connection to the proxyserver. This is not the time until the server returns the pages, this is the proxy_read_timeout statement. If your proxyserver is up, but hanging (e.g. it does not have enough threads to process
your request so it puts you in the pool of connections to deal with later), then this statement will not help as the connection to the server has been made. It is necessary to keep in mind that this time out cannot be more than 75 seconds.
4. proxy模块的proxy_read_timeout
syntax: proxy_read_timeout the_time
default: proxy_read_timeout 60
context: http, server, location
This directive sets the read timeout for the response of the proxied server. It determines how long NGINX will wait to get the response to a request. The timeout is established not for entire response, but only between two operations of reading.
In contrast to proxy_connect_timeout, this timeout will catch a server that puts you in it's connection pool but does not respond to you with anything beyond that. Be careful though not to set this too low, as your proxy server might take a longer time to
respond to requests on purpose (e.g. when serving you a report page that takes some time to compute). You are able though to have a different setting per location, which enables you to have a higher proxy_read_timeout for the report page's location.
If the proxied server nothing will communicate after this time, then nginx is shut connection.
另一个参考：504 Gateway Time-out问题
常见于使用nginx作为web server的服务器的网站
我遇到这个问题是在升级discuz论坛的时候遇到的
一般看来, 这种情况可能是由于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;
调整了这两个参数, 结果就是没有再显示那个超时, 可以说效果不错, 但是也可能是由于其他的原因, 目前关于nginx的资料不是很多, 很多事情都需要长期的经验累计才有结果。
proxy_set_header Host $
proxy_set_header X-Real-IP $remote_
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_
client_max_body_size 10m;
client_body_buffer_size 128k;
proxy_connect_timeout 90;
proxy_send_timeout 90;
proxy_read_timeout 90;
proxy_buffer_size 4k;
proxy_buffers 32 4k;
proxy_busy_buffers_size 64k;
没有更多推荐了，在 SegmentFault，学习技能、解决问题
每个月，我们帮助 1000 万的开发者解决各种各样的技术问题。并助力他们在技术能力、职业生涯、影响力上获得提升。
问题对人有帮助，内容完整，我也想知道答案
问题没有实际价值，缺少关键内容，没有改进余地
我用Nginx+Django+FastCGI跑一个服务，是要处理一个巨大的XML，犹豫文件太大，处理比较慢，爬到一半就超时了。
我改了Nginx的配置，原来是60，改到120，但貌似没效果，还是60s超时。location ^~ /api/ {
proxy_read_timeout 120;
proxy_connect_timeout 120;
fastcgi_pass 127.0.0.1:8080;
}还有别的哪里要改吗？
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
proxy是代理跟后端通信的时间，需要修改fastcgi超时时间
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
应该用:fastcgi_read_timeout 600;
fastcgi_send_timeout 600;这两个选项.
fastcgi_read_timeout是指fastcgi进程向nginx进程发送response的整个过程的超时时间
fastcgi_send_timeout是指nginx进程向fastcgi进程发送request的整个过程的超时时间这两个选项默认都是秒(s),可以手动指定为分钟(m),小时(h)等.
分享到微博？
关闭理由：
删除理由：
忽略理由：
推广（招聘、广告、SEO 等）方面的内容
与已有问题重复（请编辑该提问指向已有相同问题）
答非所问，不符合答题要求
宜作评论而非答案
带有人身攻击、辱骂、仇恨等违反条款的内容
无法获得确切结果的问题
非开发直接相关的问题
非技术提问的讨论型问题
其他原因（请补充说明）
我要该，理由是：
在 SegmentFault，学习技能、解决问题
每个月，我们帮助 1000 万的开发者解决各种各样的技术问题。并助力他们在技术能力、职业生涯、影响力上获得提升。高性能服务器 分布式 大数据 安全
nginx超时设置
nginx常用的超时配置说明
client_header_timeout
语法 client_header_timeout time
默认值 60s
上下文 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”）
两个参数的值可并不相同注意不同浏览器怎么处理“keep-alive”头MSIE和Opera忽略掉"Keep-Alive: timeout=&N&" header. MSIE保持连接大约60-65秒，然后发送TCP RSTOpera永久保持长连接Mozilla keeps the connection alive for N plus about 1-10 seconds. Konqueror保持长连接N秒lingering_timeout
语法 lingering_timeout time
上下文 http server location
说明 lingering_close生效后，在关闭连接前，会检测是否有用户发送的数据到达服务器，如果超过lingering_timeout时间后还没有数据可读，就直接关闭连接；否则，必须在读取完连接缓冲区上的数据并丢弃掉后才会关闭连接。resolver_timeout
语法 resolver_timeout time
默认值 30s
上下文 http server location
说明 该指令设置DNS解析超时时间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操作的时间。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秒
没有更多推荐了，> 设置nginx的超时时间
设置nginx的超时时间
上传者：chensm
我也要“”
& & 设置nginx的超时时间& & 使用nginx服务器如果遇到timeou情况时可以如下设置参数，使用fastcgi：& & [python]& & fastcgi_connect_timeout 75;& & fastcgi_read_timeout 600;& & fastcgi_send_……
声明：该文章系网友上传分享，此内容仅代表网友个人经验或观点，不代表本网站立场和观点；若未进行原创声明，则表明该文章系转载自互联网；若该文章内容涉嫌侵权，请及时向
上一篇：下一篇：
相关经验教程