nginx错误“从上游读取响应头时，recv（）失败（104：由对等方重置连接）

我有一台服务器工作正常，直到2013年10月3日上午10点50分，当它开始间歇地返回“502坏门户”错误到客户端。

5个浏览器请求中大约有4个成功，但是大约有5个失败，502个。

nginx错误日志包含数百个这些错误;

2013/10/05 06:28:17 [error] 3111#0: *54528 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 66.249.66.75, server: www.bec-components.co.uk request: ""GET /?_n=Fridgefreezer/Hotpoint/8591P;_i=x8078 HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "www.bec-components.co.uk"

但是，PHP错误日志不包含任何匹配的错误。

有没有办法让PHP给我更多关于为什么重置连接的信息？

这是nginx.conf ;

 user www-data; worker_processes 4; error_log /var/log/nginx/error.log; pid /var/run/nginx.pid; events { worker_connections 1024; } http { include /etc/nginx/mime.types; access_log /var/log/nginx/access.log; sendfile on; keepalive_timeout 30; tcp_nodelay on; client_max_body_size 100m; gzip on; gzip_types text/plain application/xml text/javascript application/x-javascript text/css; gzip_disable "MSIE [1-6]\.(?!.*SV1)"; include /gvol/sites/*/nginx.conf; }

这是这个网站的.conf 。

 server { server_name www.bec-components.co.uk bec3.uk.to bec4.uk.to bec.home; root /gvol/sites/bec/www/; index index.php index.html; location ~ \.(js|css|png|jpg|jpeg|gif|ico)$ { expires 2592000; # 30 days log_not_found off; } ## Trigger client to download instead of display '.xml' files. location ~ \.xml$ { add_header Content-disposition "attachment; filename=$1"; } location ~ \.php$ { fastcgi_read_timeout 3600; include /etc/nginx/fastcgi_params; keepalive_timeout 0; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; } } ## bec-components.co.uk ## server { server_name bec-components.co.uk; rewrite ^/(.*) http://www.bec-components.co.uk$1 permanent; }

我一直相信，如果我的networking服务器告诉我： 502 Bad Gateway

fastcgi / nginx进程的正常运行时间是多less？
你监测networking连接？
你可以确认/否定游客的变化 – 在那一天呢？

这是什么意思：

你的fastcgi进程不能被nginx访问; 要么减慢，要么根本不对应。坏的网关意味着：nginx不能将fastcgi_pass定义为资源127.0.0.1:9000; 在那个特定的时刻 。
你的初始错误日志告诉了这一切：

。

 recv() failed -> nginx failed (104: Connection reset by peer) while reading response header from upstream, -> no complete answer, or no answer at all upstream: "fastcgi://127.0.0.1:9000", -> who is he, who failed???

从我有限的pov我会build议：

重新启动你的fastcgi_process /服务器
检查你的访问日志
启用debugging日志

我知道这个话题已经老了，但偶尔也会popup来，所以在网上寻找答案，我提出了以下三种可能：

一个编程错误有时会中断php-fpm，这意味着与nginx的连接将被切断。这通常会留下至less一些原木周围和/或堆芯，这可以进一步分析。
出于某种原因，PHP不能写会话文件（通常是： session.save_path = "/var/lib/php/sessions" ）。这可能是不好的权限，坏的所有权，不良的用户/组，或者更多的深奥/晦涩的问题，如在该目录（甚至一个完整的磁盘！这通常不会在PHP错误日志中留下许多核心转储，甚至可能没有。
debugging更加棘手：扩展是行为不当（偶尔会遇到某种内部限制，或者一直没有触发的错误），segfaulting，并将php-fpm进程closures – 从而closures与nginx的连接。通常的罪魁祸首是APC，memcache / d等（在我的情况下是New Relic扩展），所以这里的想法是closures每个扩展，直到错误消失。

保持得到这个。如果使用它（通过replaceAPC），则通过增加opcache内存限制来解决这个问题。似乎PHP-FPM在caching过满时断开连接。这也是shgnInc的答案在短时间内解决这个问题的原因。

所以find文件/etc/php5/fpm/php.ini （或者你的发行版中的等价物）并且增加memory_consumption到你的网站需要的任何级别。禁用opcache也可能工作。

 [opcache] opcache.memory_consumption = 196

你可能想在github上考虑这个git： https ： //gist.github.com/amichaelgrant/90d99d7d5d48bf8fd209

我遇到了类似的情况，当我检查我的上游服务器的错误日志，他们报告了一些ulimit错误，所以我增加了1000000（在上游和nginx框），一切工作正常

在我的情况下，同样的问题，我只是重新启动php-fpm服务，所以它解决了。

 sudo service php5-fpm restart

或者有些时候这个问题是由于大量的请求而发生的。默认情况下，php5-fpm中的pm.max_requests可能是100或更低。

为了解决它的价值取决于你的网站的要求，例如500。

之后，你必须重新启动服务

在我的情况下，禁用xdebug扩展确实有帮助。