nginx php fastcgi Connection reset by peer的原因及解决办法

Connection reset by peer

这个错误是在nginx的错误日志中发现的,为了更全面的掌握nginx运行的异常,强烈建议在nginx的全局配置中增加

error_log   logs/error.log notice;

这样,就可以记录nginx的详细异常信息。

nginx的错误日志中会出现Connection reset by peer) while reading response header from upstream, client: 1.1.1.1, server: 102.local, request: "GET / HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000

后来反复检查,发现这是因为php运行较慢,并超出php-fpm.conf的request_terminate_timeout设置的秒数。

request_terminate_timeout用于设置当某个php脚本运行最长时间,若超出php-fpm进程管理器强行中止当前程序,并关闭fastcgi和nginx的网络连接,然后nginx中就会出现Connection reset by peer的错误了。

也就是说,产生这个错误的原因是:

php 程序的运行时间超出request_terminate_timeout设置的值。

在php-fpm环境下,在php的安装目录的etc/php-fpm.conf中有此值的设置项,可将其设置为0或更大的值。

提示,在php.ini中存在一项max_execution_time,也用于设置php脚本的最长执行时间。但在php-fpm环境下,我发现max_execution_time的设置是无效的,只有request_terminate_timeout产生了作用。

总结:请将request_terminate_timeout设置为较大的值或0,可减少因php脚本执行时行过长导致nginx产生Connection reset by peer错误。

时间: 2024-08-05 15:15:58

nginx php fastcgi Connection reset by peer的原因及解决办法的相关文章

nginx错误分析 `104: Connection reset by peer`

故障描述 应用从虚拟机环境迁移到kubernetes环境中,有些应用不定时出现请求失败的情况,且应用没有记录任何日志,而在NGINX中记录502错误.我们查看了之前虚拟机中的访问情况,没有发现该问题. 基础信息 # 请求流程 client --> nginx(nginx-ingress-controller) --> tomcat(容器) # nginx版本 $ nginx -V nginx version: nginx/1.15.5 built by gcc 8.2.0 (Debian 8.

uWSGI uwsgi_response_write_body_do(): Connection reset by peer 报错的解决方法

服务器架构是:Nginx+uWSGI+Django 某一天,发现服务器返回的response不完整,例如文档大小是200K的,但是只返回了100K给浏览器. 查了一下uWSGI的日志,发现以下错误: Mon May 16 18:01:02 2016 - uwsgi_response_write_body_do(): Connection reset by peer [core/writer.c line 322] during GET /access?gid=5&action=edit&r

ssh远程报错ssh_exchange_identification: read: Connection reset by peer

ssh远程登录报错: [[email protected] ~]$ ssh     198.44.241.34 ssh_exchange_identification: read: Connection reset by peer 初步原因锁定: 1-服务器防火墙限定, 2-是否达到ssh的最大连接数,超过之后会服务器端会拒绝新的连接,直到有新的连接释放出来 3-/etc/hosts.allow和/etc/hosts.deny配置文件限定ip登录 解决方案: 1 firewall-cmd --l

Connection reset by peer问题分析

extremetable导出excel,弹出一个下载窗口,这时不点下载而点取消,则报下面的异常: ClientAbortException Caused by: java.net.SocketException: Connection reset by peer: socket write error 查了下TOMCAT的文档,解释如下: Wrap an IOException identifying it as being caused by an abort of a request by

recv() failed (104: Connection reset by peer) while reading response header from upstream

场景: 为了得到用户在线等信息,在客户端做了个ajax轮训: 于是问题就来了, 日志文件 [[email protected] web]# tail -f /data/log/nginx_error.log 2017/06/16 19:20:28 [error] 230555#0: *10228041 recv() failed (104: Connection reset by peer) while reading response header from upstream,client:

Connection reset by peer 的常见原因:

Connection reset by peer的常见原因: 1)服务器的并发连接数超过了其承载量,服务器会将其中一些连接关闭: 如果知道实际连接服务器的并发客户数没有超过服务器的承载量,则有可能是中了病毒或者木马,引起网络流量异常.可以使用netstat -an查看网络连接情况. 2)客户关掉了浏览器,而服务器还在给客户端发送数据: 3)浏览器端按了Stop: 这两种情况一般不会影响服务器.但是如果对异常信息没有特别处理,有可能在服务器的日志文件中,重复出现该异常,造成服务器日志文件过大,影响

CentOS7 yum的一次报错" 14: curl#56 - "Recv failure: Connection reset by peer" "

1.故障现象 [[email protected] src]# yum update Loaded plugins: fastestmirror, langpacks Could not retrieve mirrorlist   7&arch=x86_64&repo=os&infra=stock error was 14: curl#56 - "Recv failure: Connection reset by peer" One of the configu

Netty 中 IOException: Connection reset by peer 与 java.nio.channels.ClosedChannelException: null

最近发现系统中出现了很多 IOException: Connection reset by peer 与 ClosedChannelException: null 深入看了看代码, 做了些测试, 发现 Connection reset 会在客户端不知道 channel 被关闭的情况下, 触发了 eventloop 的 unsafe.read() 操作抛出 而 ClosedChannelException 一般是由 Netty 主动抛出的, 在 AbstractChannel 以及 SSLHand

ssh_exchange_identification: read: Connection reset by peer

连接SSH报错:ssh_exchange_identification: read: Connection reset by peer 查看没有使用防火墙,怀疑是在hosts.deny中设置了拦截 果不其然 将这一行注释,默念三声“信春哥得永生”后,问题恢复了,so easy