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

1. nginx快速定位异常

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信号可以抓包看到，如下所示：

• 比如，当后端为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://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;

后台报错：recv() failed (104: Connection reset by peer) while reading response header from upstream

排查：

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 时第一个缓冲区的大小，不包含在前者中。所以总计能创建的最大内存缓冲区大小是 84K+4K = 36k。而这些缓冲区是根据实际的 Response 大小动态生成的，并不是一次性创建的。比如一个 8K 的页面，Nginx 会创建 24K 共 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

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 协议

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

Be extra sure to include proxy_http_version 1.1 or the web socket connection will fail.

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

4.2 问题背景:

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

4.3 问题分析:

1.一开始以为是代码问题,检查了代码,发现直接调用接口是可以下载成功的,那么问题就出在转发上面了.
2.然后查看nginx的error日志,发现报的错误是upstream sent invalid chunked response while reading upstream.之后就是google搜索问题,发现在nginx的location模块里面加上proxy_http_version 1.1就可以了.
3.也可以查看nginx官网对于proxy_http_version的描述,

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

4.4 问题总结:

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

proxy_http_version 1.1;

proxy_set_header Connection “”;

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