☰

104：从上游读取响应标头时对端重置连接（Nginx）

tag-icon • tag-icon nginx php http
104：从上游读取响应标头时对端重置连接（Nginx）

我有一台服务器，它一直运行正常，直到 2013 年 10 月 3 日上午 10:50，它开始间歇性地向客户端返回“502 Bad Gateway”错误。

大约 5 个浏览器请求中有 4 个会成功，但大约 5 个请求中有 1 个会失败并出现 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;
}

答案1

我总是会相信我的网络服务器告诉我的502 Bad Gateway。

  • 您的 FastCGI/NGINX 进程的正常运行时间是多少？
  • 您监控网络连接吗？
  • 您能否确认/否认当天游客数量的变化？

错误含义

NGINX 无法访问您的 FastCGI 进程；要么太慢，要么根本无法响应。坏网关意味着 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???

从我有限的观点来看，我建议：

  • 重新启动 FastCGI 进程或服务器
  • 检查您的access.log
  • 启用启用debug.log

答案2

我知道这个话题已经很老了，但它仍然会偶尔出现，因此，在网上寻找答案时，我想到了以下三种可能性：

  1. 编程错误有时会使 php-fpm 分段错误，这反过来意味着与 nginx 的连接将被切断。这通常会留下至少一些日志和/或核心转储，可供进一步分析。
  2. 由于某种原因，PHP 无法写入会话文件（通常是session.save_path = "/var/lib/php/sessions"：）。这可能是权限错误、所有权错误、用户/组错误，或者更深奥/晦涩的问题，例如该目录上的 inode 用完（甚至是磁盘已满！）。这通常会不是留下许多核心转储，甚至可能在 PHP 错误日志中没有任何内容。
  3. 调试起来更加棘手：扩展程序出现错误（偶尔达到某种内部限制，或者出现并非一直触发的错误），出现分段错误，并导致 php-fpm 进程崩溃 — 从而关闭与 nginx 的连接。通常的罪魁祸首是 APC、memcache/d 等（在我的情况下是 New Relic 扩展程序），因此这里的想法是关闭每个扩展程序，直到错误消失。

答案3

也一直遇到这个问题。通过增加opcache内存限制（如果使用内存限制，则可解决该问题（替代 APC））。似乎 PHP-FPM 会在缓存太满时断开连接。这也是 shgnInc 的答案在短时间内修复该问题的原因。

因此，找到该文件/etc/php5/fpm/php.ini（或发行版中的等效文件）并增加到memory_consumption您的站点所需的级别。禁用opcache也可能有效。

[opcache]
opcache.memory_consumption = 196

答案4

您可能需要考虑 github 上的这个 git： https://gist.github.com/amichaelgrant/90d99d7d5d48bf8f​​d209

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

相关内容