Connectionresetbypeer全解
⽂章很长，建议收藏起来，慢慢读! 为⼩伙伴奉上以下珍贵的学习资源：
疯狂创客圈经典图书：⾯试必备 + ⼤⼚必备 + 涨薪必备
疯狂创客圈经典图书：⾯试必备 + ⼤⼚必备 + 涨薪必备
疯狂创客圈价值1000元百度⽹盘资源⼤礼包随便取 GO->【】
独孤九剑：本地 100W连接⾼并发实验，
价值连城：2021春招⽉薪过5万⾯试题总系列
搞定下⾯这些⾯试题，2021春招⽉薪过5万(猛！)阿⾥、京东、美团、头条.... 随意挑、横着⾛
Java基础
1： JVM⾯试题（史上最强、持续更新、吐⾎推荐）
2：Java基础⾯试题（史上最全、持续更新、吐⾎推荐）
3：死锁⾯试题（史上最强、持续更新）[]
4：设计模式⾯试题（史上最全、持续更新、吐⾎推荐）
5：架构设计⾯试题（史上最全、持续更新、吐⾎推荐）
还有 10 ⼏篇篇价值连城的⾯试题具体..... 请参见【】
万字长⽂：疯狂创客圈 springCloud ⾼并发系列
springCloud ⾼质量博⽂
还有 10 ⼏篇万字长⽂的⾼质量博⽂具体..... 请参见【】
1错误信息
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
⽇志查看⽅法
这个错误是在nginx的错误⽇志中发现的，为了更全⾯的掌握nginx运⾏的异常，强烈建议在nginx的全局配置中增加
error_log logs/error.log notice;
这样，就可以记录nginx的详细异常信息。
2 原因⼀：连接已经被上游close。
服务端确实已经关闭了连接： 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的操作流程了，⽽不是接着收发数据。
⽐如，当后端为php程序时，如果php运⾏较慢，并超出f的request_terminate_timeout设置的秒数。request_terminate_timeout⽤于设置当某个php脚本运⾏最长时间，若超出php-fpm进程管理器强⾏中⽌当前程序，并关闭fastcgi和nginx的⽹络连接，然后nginx中就会出现Connection reset by peer的错误了。
也就是说，产⽣这个错误的原因是：php 程序的运⾏时间超出request_terminate_timeout设置的值。
在php-fpm环境下，在php的安装⽬录的f中有此值的设置项，可将其设置为0或更⼤的值。这样将php的request_terminate_timeout设置为较⼤的值或0，可减
少因php脚本执⾏时⾏过长导致nginx产⽣Connection reset by peer错误。
⽐如，当后端为java 程序时，
java 的也类似，不能Java端主动关闭连接。 如果上游的tomcat 或者 netty 已经关闭连接， 那么nginx 肯定就是 Connection reset by peer
3 原因⼆：数据长度不⼀致
发送端和接收端事先约定好的数据长度不⼀致导致的，接收端被通知要收的数据长度⼩于发送端实际要发送的数据长度。
4 原因三： 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;
后台报错：
排查：
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次握⼿后。
5 原因四： proxy_buffer缓存⼩
原因就是请求的头⽂件过⼤导致502错误
解决⽅法就是提⾼头部的缓存
http{
client_header_buffer_size 5m;
location / {
proxy_buffer_size 128k;
proxy_busy_buffers_size 192k;
peerproxy_buffers 4 192k;
}
}
原因五：没有设置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 },
原因六：设置lingering_close
即使你禁⽤了 http keepalive，nginx 仍然会尝试处理 HTTP 1.1 pipeline 的请求。你可以配置
lingering_close off 禁⽤此⾏为，但这不是推荐的做法，因为会违反 HTTP 协议。见nginx 快速定位异常
参考：
回到◀▶
疯狂创客圈 - Java⾼并发研习社，为⼤家开启⼤⼚之门错误信息
错误说明"upstream prematurely （过早的） closed
connection"
请求uri 的时候出现的异常，是由于upstream 还未返回应答给⽤户时⽤户断掉连接造成的，对系统没有影响，可以忽略"recv() failed (104: Connection reset by peer)"
（1）服务器的并发连接数超过了其承载量，服务器会将其中⼀些连接Down 掉； （2）客户关掉了浏览器，⽽服务器还在给客户端发送数据； （3）浏览器端按了Stop "(111: Connection refused) while connecting to
upstream"
⽤户在连接时，若遇到后端upstream 挂掉或者不通，会收到该错误"(111: Connection refused) while reading
response header from upstream"
⽤户在连接成功后读取数据时，若遇到后端upstream 挂掉或者不通，会收到该错误"(111: Connection refused) while sending request
to upstream"
Nginx 和upstream 连接成功后发送数据时，若遇到后端upstream 挂掉或者不通，会收到该错误"(110: Connection timed out) while connecting to
upstream"
nginx 连接后⾯的upstream 时超时"(110: Connection timed out) while reading
upstream"
nginx 读取来⾃upstream 的响应时超时"(110: Connection timed out) while reading
response header from upstream"
nginx 读取来⾃upstream 的响应头时超时"(110: Connection timed out) while reading
upstream"
nginx 读取来⾃upstream 的响应时超时"(104: Connection reset by peer) while
connecting to upstream"
upstream 发送了RST ，将连接重置"upstream sent invalid header while reading
response header from upstream"
upstream 发送的响应头⽆效"upstream sent no valid HTTP/1.0 header while
reading response header from upstream"
upstream 发送的响应头⽆效"client intended to send too large body"
⽤于设置允许接受的客户端请求内容的最⼤值，默认值是1M ，client 发送的body 超过了设置值"reopening logs"
⽤户发送kill -USR1命令"gracefully shutting down",
⽤户发送kill -WINCH 命令"no servers are inside upstream"
upstream 下未配置server "no live upstreams while connecting to upstream"
upstream 下的server 全都挂了"SSL_do_handshake() failed"
SSL 握⼿失败"ngx_slab_alloc() failed: no memory in SSL
session shared cache"
ssl_session_cache ⼤⼩不够等原因造成"could not add new SSL session to the session
cache while SSL handshaking"ssl_session_cache ⼤⼩不够等原因造成
版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。
发表评论