1 錯誤原因：檢查鏈接是否已經(jīng)close。
upstream發(fā)送了RST，將連接重置。

errno = 104錯誤表明你在對一個對端socket已經(jīng)關(guān)閉的的連接調(diào)用write或send方法，在這種情況下，調(diào)用write或send方法后，對端socket便會向本端socket發(fā)送一個RESET信號，在此之后如果繼續(xù)執(zhí)行write或send操作，就會得到errno為104，錯誤描述為connection reset by peer。如果對方socket已經(jīng)執(zhí)行了close的操作，本端socket還繼續(xù)在這個連接上收發(fā)數(shù)據(jù)，就會觸發(fā)對端socket發(fā)送RST報文。按照TCP的四次握手原理，這時候本端socket應(yīng)該也要開始執(zhí)行close的操作流程了，而不是接著收發(fā)數(shù)據(jù)。

2 可能原因
2.1 鏈接已經(jīng)斷開
這個應(yīng)該是最根本的原因。

2.2 數(shù)據(jù)長度不一致
發(fā)送端和接收端事先約定好的數(shù)據(jù)長度不一致導(dǎo)致的，接收端被通知要收的數(shù)據(jù)長度小于發(fā)送端實(shí)際要發(fā)送的數(shù)據(jù)長度。

2.3 Nginx緩存小，timeout太小
nginx的buffer太小，timeout太小。

nginx http模塊添加以下參數(shù)配置：

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 沒有設(shè)置keepalive
ngx_http_upstream_check_module這個模塊，在使用tcp檢測后端狀態(tài)時，只進(jìn)行了TCP的三次握手，沒有主動斷開這個連接，而是等待服務(wù)端來斷開。當(dāng)后端是nginx或者tomcat時（linux上），超時后后端會發(fā)fin包關(guān)閉這個連接。這個錯誤日志recv() failed (104: Connection reset by peer)是在后端為IIS的情況下拋出的，抓包發(fā)現(xiàn)IIS并不會發(fā)fin包來斷開鏈接，而是在超時后發(fā)RST包重置連接，所以導(dǎo)致了這個問題。
從這個問題也反應(yīng)出ngx_http_upstream_check_module這個模塊還是需要完善下檢測機(jī)制的，如果是在檢測后端狀態(tài)后主動關(guān)閉這個連接，應(yīng)該就不會出現(xiàn)connect reset這個問題

通過修改源代碼已經(jīng)解決了該問題

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即可，根據(jù)數(shù)據(jù)結(jié)構(gòu)分析可得知，這個1代表啟用keepalived，所以客戶端才不會主動斷開連接，因?yàn)檫@是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 設(shè)置lingering_close
即使你禁用了 http keepalive，nginx 仍然會嘗試處理 HTTP 1.1 pipeline 的請求。你可以配置
lingering_close off 禁用此行為，但這不是推薦的做法，因?yàn)闀`反 HTTP 協(xié)議。見

http://nginx.org/en/docs/http/ngx_http_core_module.html#lingering_close

3 nginx快速定位異常
“upstream prematurely（過早的） closed connection”

請求uri的時候出現(xiàn)的異常，是由于upstream還未返回應(yīng)答給用戶時用戶斷掉連接造成的，對系統(tǒng)沒有影響，可以忽略

“recv() failed (104: Connection reset by peer)”

（1）服務(wù)器的并發(fā)連接數(shù)超過了其承載量，服務(wù)器會將其中一些連接Down掉；

（2）客戶關(guān)掉了瀏覽器，而服務(wù)器還在給客戶端發(fā)送數(shù)據(jù)；

（3）瀏覽器端按了Stop

"(111: Connection refused) while connecting to upstream"用戶在連接時，若遇到后端upstream掛掉或者不通，會收到該錯誤"(111: Connection refused) while reading response header from upstream"用戶在連接成功后讀取數(shù)據(jù)時，若遇到后端upstream掛掉或者不通，會收到該錯誤"(111: Connection refused) while sending request to upstream"Nginx和upstream連接成功后發(fā)送數(shù)據(jù)時，若遇到后端upstream掛掉或者不通，會收到該錯誤"(110: Connection timed out) while connecting to upstream"nginx連接后面的upstream時超時"(110: Connection timed out) while reading upstream"nginx讀取來自upstream的響應(yīng)時超時"(110: Connection timed out) while reading response header from upstream"nginx讀取來自upstream的響應(yīng)頭時超時"(110: Connection timed out) while reading upstream"nginx讀取來自upstream的響應(yīng)時超時"(104: Connection reset by peer) while connecting to upstream"upstream發(fā)送了RST，將連接重置"upstream sent invalid header while reading response header from upstream"upstream發(fā)送的響應(yīng)頭無效"upstream sent no valid HTTP/1.0 header while reading response header from upstream"upstream發(fā)送的響應(yīng)頭無效"client intended to send too large body"用于設(shè)置允許接受的客戶端請求內(nèi)容的最大值，默認(rèn)值是1M，client發(fā)送的body超過了設(shè)置值"reopening logs"

用戶發(fā)送kill -USR1命令

“gracefully shutting down”,

用戶發(fā)送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大小不夠等原因造成

總結(jié)

以上是生活随笔為你收集整理的Nginx: 104: Connection reset by peer 错误的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。