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大小不夠等原因造成

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。