Nginx: Connection reset by peer 错误定位

我会带着你远行 2022-02-23 14:54 865阅读 0赞

最近Nginx反向代理遇到了“104: Connection reset by peer”错误，google了一下，这里记录一下。

**本文根据众多互联网博客内容整理后形成，引用内容的版权归原始作者所有，仅限于学习研究使用。**

# 1. nginx快速定位异常 #

<table> 
 <thead> 
  <tr> 
   <th>错误信息</th> 
   <th>错误说明</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>"upstream prematurely（过早的） closed connection"</td> 
   <td>请求uri的时候出现的异常，是由于upstream还未返回应答给用户时用户断掉连接造成的，对系统没有影响，可以忽略</td> 
  </tr> 
  <tr> 
   <td>"recv() failed (104: Connection reset by peer)"</td> 
   <td>（1）服务器的并发连接数超过了其承载量，服务器会将其中一些连接Down掉； （2）客户关掉了浏览器，而服务器还在给客户端发送数据； （3）浏览器端按了Stop</td> 
  </tr> 
  <tr> 
   <td>"(111: Connection refused) while connecting to upstream"</td> 
   <td>用户在连接时，若遇到后端upstream挂掉或者不通，会收到该错误</td> 
  </tr> 
  <tr> 
   <td>"(111: Connection refused) while reading response header from upstream"</td> 
   <td>用户在连接成功后读取数据时，若遇到后端upstrream挂掉或者不通，会收到该错误</td> 
  </tr> 
  <tr> 
   <td>"(111: Connection refused) while sending request to upstream"</td> 
   <td>Nginx和upstream连接成功后发送数据时，若遇到后端upstream挂掉或者不通，会收到该错误</td> 
  </tr> 
  <tr> 
   <td>"(110: Connection timed out) while connecting to upstream"</td> 
   <td>nginx连接后面的upstream时超时</td> 
  </tr> 
  <tr> 
   <td>"(110: Connection timed out) while reading upstream"</td> 
   <td>nginx读取来自upstream的响应时超时</td> 
  </tr> 
  <tr> 
   <td>"(110: Connection timed out) while reading response header from upstream"</td> 
   <td>nginx读取来自upstream的响应头时超时</td> 
  </tr> 
  <tr> 
   <td>"(110: Connection timed out) while reading upstream"</td> 
   <td>nginx读取来自upstream的响应时超时</td> 
  </tr> 
  <tr> 
   <td>"(104: Connection reset by peer) while connecting to upstream"</td> 
   <td><strong>upstream发送了RST，将连接重置</strong></td> 
  </tr> 
  <tr> 
   <td>"upstream sent invalid header while reading response header from upstream"</td> 
   <td>upstream发送的响应头无效</td> 
  </tr> 
  <tr> 
   <td>"upstream sent no valid HTTP/1.0 header while reading response header from upstream"</td> 
   <td>upstream发送的响应头无效</td> 
  </tr> 
  <tr> 
   <td>"client intended to send too large body"</td> 
   <td>用于设置允许接受的客户端请求内容的最大值，默认值是1M，client发送的body超过了设置值</td> 
  </tr> 
 </tbody> 
</table>

# 2. 错误信息 #

Connection reset by peer

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

## 2.1 日志查看方法 ##

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

error\_log logs/error.log notice;

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

# 3. 错误原因 #

## 3.1 连接已经被上游close。 ##

readv() failed (104: Connection reset by peer) while reading **upstream**

服务端确实已经关闭了连接： upstream发送了RST，将连接重置。

**      errno = 104 错误表明你在对一个对端socket已经关闭的的连接调用write或send方法**，在这种情况下，调用write或send方法后，对端socket便会向本端socket发送一个RESET信号，在此之后如果继续执行write或send操作，就会得到errno为104，错误描述为connection reset by peer。

如果对方socket已经执行了close的操作，本端socket还继续在这个连接上收发数据，就会触发对端socket发送RST报文。按照TCP的四次握手原理，这时候本端socket应该也要开始执行close的操作流程了，而不是接着收发数据。

抓包确认下

**`tcpdump -i any -s0 -A port`**

RESET信号可以抓包看到，如下所示：![SouthEast][]

*  **比如，当后端为php程序时**，如果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的request\_terminate\_timeout设置为较大的值或0，可减少因php脚本执行时行过长导致nginx产生Connection reset by peer错误。

*  **比如，当后端为java 程序时**，

java 的也类似，不能Java端主动关闭连接。 如果上游的tomcat 或者 netty 已经关闭连接， 那么nginx 肯定就是 Connection reset by peer

## 3.2：数据长度不一致 ##

发送端和接收端事先约定好的数据长度不一致导致的，接收端被通知要收的数据长度小于发送端实际要发送的数据长度。

## **3.3 nginx的buffer太小，timeout太小。** ##

### 参考： ###

[https://juejin.cn/post/6844904084021968909][https_juejin.cn_post_6844904084021968909]

[https://cloud.tencent.com/developer/article/1521256][https_cloud.tencent.com_developer_article_1521256]

### 3.3.1： FastCGI 缓存小，timeout太小。 ###

**nginx的buffer太小，timeout太小。**

主要指php的环境，nginx如果要解析php脚本语言，就必须通过配置fastcgi模块来提供对php支持。

**问题概述：**图片bit 64生成数据流太大，导致小程序分享弹窗的二维码图片生成失败

nginx http模块添加以下参数配置：

fastcgi\_buffer\_size 128k;

fastcgi\_buffers 4 128k;

fastcgi\_busy\_buffers\_size 128k;

fastcgi\_temp\_file\_write\_size 128k;

**后台报错：**

[![img][]][img]

**排查：**

Client------>nginx------->h5------>nginx---------->client

客户端通过h5的nginx页面点击，nginx反向代理到h5 \[无异常\]

h5通过客户端请求调取相应接口 \[无异常\]

接口返回数据通过nginx展示给客户端 \[异常\]

Ps: 图片通过bit 64解析生成返回给客户端，由于数据长度太长导致

**解决方法：**

调整nginx配置文件参数，修改后参数：

fastcgi\_buffer\_size 256k;

fastcgi\_buffers 4 256k;

fastcgi\_busy\_buffers\_size 256k;

fastcgi\_temp\_file\_write\_size 256k;

先简单的说一下 Nginx 的 buffer 机制，对于来自 FastCGI Server 的 Response，Nginx 将其缓冲到内存中，然后依次发送到客户端浏览器。缓冲区的大小由 fastcgi\_buffers 和 fastcgi\_buffer\_size 两个值控制。

比如如下配置：

fastcgi\_buffers 8 4K;

fastcgi\_buffer\_size 4K;

fastcgi\_buffers 控制 nginx 最多创建 8 个大小为 4K 的缓冲区，而 fastcgi\_buffer\_size 则是处理 Response 时第一个缓冲区的大小，不包含在前者中。所以总计能创建的最大内存缓冲区大小是 8*4K+4K = 36k。而这些缓冲区是根据实际的 Response 大小动态生成的，并不是一次性创建的。比如一个 8K 的页面，Nginx 会创建 2*4K 共 2 个 buffers。

当 Response 小于等于 36k 时，所有数据当然全部在内存中处理。如果 Response 大于 36k 呢？fastcgi\_temp 的作用就在于此。多出来的数据会被临时写入到文件中，放在这个目录下面。同时你会在 error.log 中看到一条类似 warning。

显然，缓冲区设置的太小的话，Nginx 会频繁读写硬盘，对性能有很大的影响，但也不是越大越好，没意义，呵呵！

### FastCGI缓冲设置主要参数 ###

fastcgi\_buffers 4 64k

这个参数指定了从FastCGI进程到来的应答，本地将用多少和多大的缓冲区读取，假设一个PHP或JAVA脚本所产生页面大小为256kb，那么会为其分配4个64kb的缓冲来缓存；若页面大于256kb，那么大于256kb的部分会缓存到fastcgi\_temp指定路径中，这并非是个好办法，内存数据处理快于硬盘，一般该值应该为站点中PHP或JAVA脚本所产生页面大小中间值，如果站点大部分脚本所产生的页面大小为256kb，那么可把值设置为16 16k,4 64k等。

fastcgi\_buffer\_size=64k

读取fastcgi应答第一部分需要多大缓冲区，该值表示使用1个64kb的缓冲区读取应答第一部分(应答头),可以设置为fastcgi\_buffers选项缓冲区大小。

fastcgi\_connect\_timeout=300

连接到后端fastcgi超时时间，单位秒，下同。

fastcgi\_send\_timeout=300

向fastcgi请求超时时间(这个指定值已经完成两次握手后向fastcgi传送请求的超时时间)

fastcgi\_reAd\_timeout=300

接收fastcgi应答超时时间，同理也是2次握手后。

### 3.3.2： proxy\_buffer缓存小 ###

原因就是请求的头文件过大导致502错误

解决方法就是提高头部的缓存：

http\{

client\_header\_buffer\_size 5m;

location / \{

proxy\_buffer\_size 128k;

proxy\_busy\_buffers\_size 192k;

proxy\_buffers 4 192k;

**另外可能：**

nginx的buffer太小，timeout太小。

nginx http模块添加以下参数配置：

client_header_buffer_size 64k;
    large_client_header_buffers 4 64k;
    client_body_buffer_size 20m;
    fastcgi_buffer_size 128k;
    fastcgi_buffers 4 128k;
    fastcgi_busy_buffers_size 256k;
    gzip_buffers 16 8k;
    proxy_buffer_size 64k;
    proxy_buffers 4 128k;
    proxy_busy_buffers_size 256k;
    
    keepalive_timeout 240;
    fastcgi_connect_timeout 600;
    fastcgi_send_timeout 600;
    fastcgi_read_timeout 600;
    
    proxy_connect_timeout 600s;
    proxy_send_timeout 1200;
    proxy_read_timeout 1200;

### 3.3.3 proxy\_max\_temp\_file\_size太小 ###

比如服务器架构是nginx + tomcat 提供下载上传以及其他服务，nginx上配置proxy\_max\_temp\_file\_size=200m，在前后端速度不对等的时候提供数据缓存。**但是实际运行中发现，当客户端下载速度比较慢时，大文件下到200多M时就会失败**。

针对这个问题，主要是由于客户端下载速度比较慢，而nginx和tomcat之间高速传输，两端速度不对等，导致nginx和tomcat之间的连接一直处于idle状态，一定时间(tomcat的keepalive时间)后tomcat主动断开连接，客户端下载失败。

## 3.4 没有设置keepalive ##

ngx\_http\_upstream\_check\_module这个模块，在使用tcp检测后端状态时，只进行了TCP的三次握手，没有主动断开这个连接，而是等待服务端来断开。当后端是nginx或者tomcat时（linux上），超时后后端会发fin包关闭这个连接。**这个错误日志recv() failed (104: Connection reset by peer)是在后端为IIS的情况下抛出的，抓包发现IIS并不会发fin包来断开链接，而是在超时后发RST包重置连接，所以导致了这个问题。**

从这个问题也反应出ngx\_http\_upstream\_check\_module这个模块还是需要完善下检测机制的，如果是在检测后端状态后主动关闭这个连接，应该就不会出现connect reset这个问题

通过修改源代码已经解决了该问题

static ngx\_check\_conf\_t ngx\_check\_types\[\] = \{  
\{ NGX\_HTTP\_CHECK\_TCP,  
ngx\_string("tcp"),  
ngx\_null\_string,  
0,  
ngx\_http\_upstream\_check\_peek\_handler,  
ngx\_http\_upstream\_check\_peek\_handler,  
NULL,  
NULL,  
NULL,  
0,  
**1** \},

将最后一行的1改为0即可，根据数据结构分析可得知，这个1代表启用keepalived，所以客户端才不会主动断开连接，因为这是tcp的端口连通性检查，不需要keepalived，将其改为0禁止keepalived即可。

修改之后的代码如下：  
static ngx\_check\_conf\_t ngx\_check\_types\[\] = \{  
\{ NGX\_HTTP\_CHECK\_TCP,  
ngx\_string("tcp"),  
ngx\_null\_string,  
0,  
ngx\_http\_upstream\_check\_peek\_handler,  
ngx\_http\_upstream\_check\_peek\_handler,  
NULL,  
NULL,  
NULL,  
0,  
**0** \},

如果使用了 proxy\_pass upstream，可以配置keepalive

upstream gateway{
                server 192.168.88.31:8081;
                server 192.168.88.44:8081;
                server 192.168.88.115:8081;
                server 192.168.88.80:8081;
                #以下是新增配置
                keepalive 100;
    }
    
    location / {
               proxy_pass http://gateway;
               proxy_set_header   Host             $host;
               proxy_set_header   X-Real-IP        $remote_addr;
               proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
               #以下是新增配置
               proxy_connect_timeout      120;   
               proxy_send_timeout         300;    
               proxy_read_timeout         300; 
               proxy_http_version 1.1;    
               proxy_set_header Connection ""; 
    }

## 3.5：设置lingering\_close ##

即使你禁用了 http keepalive，nginx 仍然会尝试处理 HTTP 1.1 pipeline 的请求。你可以配置  
lingering\_close off 禁用此行为，但这不是推荐的做法，因为会违反 HTTP 协议。见

[http://nginx.org/en/docs/http/ngx\_http\_core\_module.html\#lingering\_close][http_nginx.org_en_docs_http_ngx_http_core_module.html_lingering_close]

#  #

# 4. upstream sent invalid chunked response while reading upstream解决 #

## 4.1  http1.0 对keepalive是不支持 ##

默认http\_version是1.0，http1.0对keepalive是不支持的，所以导致了此问题。

**proxy\_http\_version 1.1;**

**proxy\_set\_header Connection "";**

**两条规则缺一不可，都是为了支持后端请求 HTTP1.1 协议**

![2feed21148df695cae68986f40acc8f8.png][]

反向代理配置这里不展开，参考2中重点提到一句：

**Be extra sure to include proxy\_http\_version 1.1 or the web socket connection will fail.**

对比自己的NGINX配置，确实少了此配置项。

## 4.2 问题背景: ##

一开始是一个下载文件的需求,但是不能直接下载,需要通过nginx做代理转发后,才能将文件流输出给合作方.然后我们将url的请求通过nginx代理到真实去下载文件流的服务器发现并不能下载到文件.(是通过请求浏览器去下载的,浏览器会显示此网页无法正常运作)

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAenpob25nY3k_size_20_color_FFFFFF_t_70_g_se_x_16][]

##    4.3 问题分析: ##

1.一开始以为是代码问题,检查了代码,发现直接调用接口是可以下载成功的,那么问题就出在转发上面了.

2.然后查看nginx的error日志,发现报的错误是upstream sent invalid chunked response while reading upstream.之后就是google搜索问题,发现在nginx的location模块里面加上proxy\_http\_version 1.1就可以了.

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAenpob25nY3k_size_20_color_FFFFFF_t_70_g_se_x_16 1][]

3.也可以查看nginx官网对于proxy\_http\_version的描述,

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAenpob25nY3k_size_20_color_FFFFFF_t_70_g_se_x_16 2][]

如果不填写http的版本的话,**默认是http1.0.从nginx的error日志上看出原始请求是使用的http1.1的版本,而且下载文件是使用的分块传递,http1.0是不支持这个特性的**.可以简单的了解一下分块传递.

![这里写图片描述][70]

http1.0是建立连接,发送请求信息,接收请求信息,断掉连接.不支持分块传递,所以nginx报错了.

## 4.4 问题总结: ##

这个问题与其说是nginx报错,不如说是不了解http不同版本之间特性的差异.而且要记住一点的是nginx代理后的默认http版本是1.0.如果原始请求是长连接或者分块传递,记得加上http1.1的参数.

**proxy\_http\_version 1.1;**

**proxy\_set\_header Connection "";**

**两条规则缺一不可，都是为了支持后端请求 HTTP1.1 协议**

# 5. 参考： #

[https://github.com/alibaba/tengine/issues/901][https_github.com_alibaba_tengine_issues_901]

[https://my.oschina.net/u/1024107/blog/1838968][https_my.oschina.net_u_1024107_blog_1838968]

[https://blog.csdn.net/zjk2752/article/details/21236725][https_blog.csdn.net_zjk2752_article_details_21236725]

[http://nginx.org/en/docs/http/ngx\_http\_core\_module.html\#lingering\_close][http_nginx.org_en_docs_http_ngx_http_core_module.html_lingering_close 1]

[https://blog.csdn.net/crj121624/article/details/79956283][https_blog.csdn.net_crj121624_article_details_79956283]

[https://www.jianshu.com/p/319791e8cd37][https_www.jianshu.com_p_319791e8cd37]

[https://blog.csdn.net/sc9018181134/article/details/82055225][https_blog.csdn.net_sc9018181134_article_details_82055225]

# 请我喝咖啡 #

**如果觉得文章写得不错，能对你有帮助，可以扫描我的微信二维码请我喝咖啡哦～~哈哈~~**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmd5YW5neWU_size_16_color_FFFFFF_t_70][]

[SouthEast]: /images/20220223/ec9f6b68abc3492c880f068c6b2126ae.png
[https_juejin.cn_post_6844904084021968909]: https://juejin.cn/post/6844904084021968909
[https_cloud.tencent.com_developer_article_1521256]: https://cloud.tencent.com/developer/article/1521256
[img]: /images/20220223/4cce5e45c49e464a9dc9d0136cab9e30.png
[http_nginx.org_en_docs_http_ngx_http_core_module.html_lingering_close]: http://www.google.com/url?q=http%3A%2F%2Fnginx.org%2Fen%2Fdocs%2Fhttp%2Fngx_http_core_module.html%23lingering_close&sa=D&sntz=1&usg=AFQjCNGVYpQnW3OO74J6It45Ihkm72A4ig
[2feed21148df695cae68986f40acc8f8.png]: /images/20220223/efec457f13024e0dbe9051a93fd26b9c.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAenpob25nY3k_size_20_color_FFFFFF_t_70_g_se_x_16]: /images/20220223/eab127e7fa094aefb744315ba3ce6508.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAenpob25nY3k_size_20_color_FFFFFF_t_70_g_se_x_16 1]: /images/20220223/31f5afc3b97b43afaeefc4ee6303147f.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAenpob25nY3k_size_20_color_FFFFFF_t_70_g_se_x_16 2]: /images/20220223/1d8ee791ad8d48ccad31a37c59667375.png
[70]: /images/20220223/ab200c155eff45fca543113b26b1b41a.png
[https_github.com_alibaba_tengine_issues_901]: https://github.com/alibaba/tengine/issues/901
[https_my.oschina.net_u_1024107_blog_1838968]: https://my.oschina.net/u/1024107/blog/1838968
[https_blog.csdn.net_zjk2752_article_details_21236725]: https://blog.csdn.net/zjk2752/article/details/21236725
[http_nginx.org_en_docs_http_ngx_http_core_module.html_lingering_close 1]: http://nginx.org/en/docs/http/ngx_http_core_module.html#lingering_close
[https_blog.csdn.net_crj121624_article_details_79956283]: https://blog.csdn.net/crj121624/article/details/79956283
[https_www.jianshu.com_p_319791e8cd37]: https://www.jianshu.com/p/319791e8cd37
[https_blog.csdn.net_sc9018181134_article_details_82055225]: https://blog.csdn.net/sc9018181134/article/details/82055225
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmd5YW5neWU_size_16_color_FFFFFF_t_70]: /images/20220223/b4706606adb540d782272897c91419d9.png