“104: connection reset by peer”本质是tcp层rst包触发的强制断连，表明连接已建立但对端异常终止；需结合日志上下文（如upstream_status为空指向后端、ip分散指向客户端）、抓包确认rst源ip、检查四类超时与缓冲区配置、验证系统资源（ulimit、close_wait）及协议合规性。
Connection reset 不是连接失败，而是连接建立后被主动中断。Nginx 日志里出现 recv() failed (104: Connection reset by peer) 或 readv() failed (104: Connection reset by peer)，说明 TCP 层收到了 RST 包——对方“拔了电话线”，不是忙音，也不是没人接。
看日志，先分清 RST 来自哪一端
错误日志本身不指明谁发的 RST，但结合上下文能判断：
- 如果错误集中在特定 upstream（如
upstream: "http://backend"），且upstream_status字段为空或为 “–”，大概率是后端服务主动断开 - 如果错误出现在大量不同客户端 IP、不同 URL 上，且时间点分散，更可能是客户端侧（浏览器关闭、移动端切网、脚本异常退出）
- 如果错误集中爆发在压测开始后几分钟，且 CPU/内存无压力，基本可锁定 Nginx 自身配置触发了防御性熔断
查配置，重点盯住四类超时与缓冲区
Nginx 默认配置偏保守，高并发或长请求容易踩中“安全阀”：
- keepalive_timeout：设太短（如默认 75s）会导致空闲连接被 Nginx 主动 close，客户端复用时就收到 RST
- client_header_timeout / client_body_timeout：客户端发包慢（如大文件上传卡顿）、网络延迟高时，Nginx 等不及就 RST
- proxy_read_timeout / proxy_send_timeout：后端处理慢，Nginx 等超时后会断开与后端的连接，此时若客户端还在等，可能触发级联 RST
- client_max_body_size / client_header_buffer_size：请求体或头过大，超出限制未报 413 而是直接 RST，常见于 PUT/POST 带大 payload 场景
抓包确认 RST 发送方
仅靠日志无法 100% 定位 RST 源头，tcpdump 是关键验证手段：
- 在 Nginx 服务器上执行：
tcpdump -i any 'tcp[tcpflags] & (tcp-rst) != 0 and port 80 or port 443' -nn -c 20 - 观察输出中的 IP 和端口：若 RST 包源 IP 是后端服务地址（如 10.0.0.5:8080），说明后端应用层未读完数据就 close；若源 IP 是客户端，则问题出在调用方或中间网络设备
- 配合 Wireshark 查看 RST 前的交互：是否刚完成 TLS 握手就 RST？那可能是 SSL 协议不兼容（如 TLS 版本、SNI、cipher suite）
系统层检查不可跳过
配置没问题，RST 还持续，就要看底层资源是否被耗尽：
- 运行
ss -s查总连接数，对比worker_connections × worker_processes是否接近上限 - 检查
ulimit -n和worker_rlimit_nofile，若系统打开文件数限制低于并发连接需求，新连接会被内核拒绝并可能引发 RST - 留意
CLOSE_WAIT连接数是否持续升高：说明 Nginx 或后端没及时 close socket，句柄泄漏最终导致连接异常中断
