nginx: 104: connection reset by peer 错误 -凯发k8官方网

1 错误原因：检查链接是否已经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的操作流程了，而不是接着收发数据。

2 可能原因
2.1 链接已经断开
这个应该是最根本的原因。

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

2.3 nginx缓存小，timeout太小
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;

2.3 没有设置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 },

2.4 设置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

3 nginx快速定位异常
“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大小不够等原因造成

总结

以上是凯发k8官方网为你收集整理的nginx: 104: connection reset by peer 错误的全部内容，希望文章能够帮你解决所遇到的问题。

如果觉得凯发k8官方网网站内容还不错，欢迎将凯发k8官方网推荐给好友。