connection-reset-by-peer

连接被对端重置（connection reset by peer）的定位与修复

现象

客户端报 read: connection reset by peer、Connection reset by peer、ECONNRESET，Go 程序还可能看到 unexpected EOF，写操作则可能报 broken pipe。它和 Connection refused、连接超时都不同：refused 是目标端口没有监听或被明确拒绝，超时是数据包被静默丢弃，而 RST 表示对端或中间设备主动发送了重置包。

RST 可能发生在 TLS 握手、请求发送、等待响应或空闲连接复用时。定位的关键不是只看报错文本，而是确认“谁发的 RST、发生在哪个阶段、当时连接处于什么状态”。

快速定位

先复现并观察连接状态：

curl -v --no-keepalive https://<host>/
curl -v https://<host>/ https://<host>/ https://<host>/
ss -tin state established '( dport = :<port> or sport = :<port> )'

抓包确认 RST 的来源和阶段：

tcpdump -ni any -vvv 'host <host> and port <port>'
nstat -az | grep -i -E 'reset|abort|overflow|drop'
journalctl -u <service> --since '30 min ago'
dmesg -T | tail -50

Kubernetes 场景同时看副本重启和端点变化：

kubectl get pod -n <ns> -o wide
kubectl describe pod <pod> -n <ns>
kubectl logs <pod> -n <ns> --previous
kubectl get endpointslice -n <ns> -o wide
kubectl get events -n <ns> --sort-by=.lastTimestamp | tail -30

NAT 或负载均衡场景检查会话表：

conntrack -S
sysctl net.netfilter.nf_conntrack_tcp_timeout_established
sysctl net.ipv4.tcp_abort_on_overflow

tcpdump 里看 RST 的源地址：源是服务端，说明服务进程、内核队列或服务端防火墙主动重置；源是客户端，则可能是客户端超时放弃、连接池关闭或客户端侧设备拦截。如果单次新建连接正常、连续请求或等待一段时间后失败，重点查连接复用和超时；如果每次建连都失败，重点查协议、端口和中间设备。抓包时同时记录两端时间，避免时钟偏差造成误判。

常见根因

1. 服务进程崩溃、被 OOM 杀死或重启，内核在关闭仍有未读数据的连接时发送 RST。
2. 空闲超时不匹配：负载均衡、NAT、Nginx 或服务端的空闲时间短于客户端连接池的复用时间，客户端复用已关闭的连接。
3. 服务端主动拒绝：连接数上限、限流、协议错误、把 TLS 流量发到明文端口，或把 HTTP 发到 HTTPS 端口。
4. accept 队列溢出。tcp_abort_on_overflow=1 时内核直接回 RST；为 0 时通常表现为丢包和超时。
5. conntrack 表满或会话过期，NAT 映射失效，后续包被重置或丢弃。
6. 防火墙或安全组使用 REJECT --reject-with tcp-reset，或云防火墙会话超时后重置连接。
7. Kubernetes 滚动更新时 Pod 正在终止，但端点摘除有延迟；没有 preStop 或优雅关闭不完整。
8. gRPC/HTTP2 长连接遇到 GOAWAY、keepalive 超时或服务端最大连接年龄时，客户端通常先表现为 UNAVAILABLE 或 transport closing；只有宽限期结束后被强制断开，才可能看到连接重置。
9. 应用层半关闭后仍继续写入，出现 broken pipe，随后连接被重置。
10. 中间设备（IPS、代理、云 LB）因策略或资源问题注入 RST。
11. 服务端设置 SO_LINGER 为 0，或关闭连接前丢弃接收缓冲区，主动发送 RST 而不是正常 FIN。

修复

• 用抓包和 ss 对齐时间线，确认 RST 是服务端、客户端还是中间设备发出，再决定排查方向。
• 服务崩溃就看退出码、OOM 记录和 --previous 日志；修复崩溃原因，并补齐优雅关闭。
• 统一空闲超时：负载均衡的空闲时间应大于服务端 keepalive，客户端连接池的最大空闲时间应小于服务端和 LB 的超时；必要时开启 TCP keepalive 并做连接健康检查。
• 对幂等请求增加带抖动的重试；对非幂等请求不要盲目重试，先确认服务端是否已处理。
• 监控 ListenOverflows、ListenDrops 和 SYN 重传，调整 somaxconn、tcp_max_syn_backlog 以及应用的 accept 并发。
• conntrack 场景提高表容量、核对 NAT 超时，并确认流量路径上没有多台设备各自维护不同会话时间。
• 防火墙按语义选择 DROP 或 REJECT；健康检查、长连接端口要显式放行。
• Kubernetes 增加 preStop 等待、设置合理的 terminationGracePeriodSeconds，并让就绪探针在关闭前先失败；长连接客户端仍要能重连。
• 长连接服务关闭前先停止接收新请求，再等待在途请求完成，最后关闭监听套接字；只改客户端重试而不修服务端优雅关闭，会把 RST 变成重复请求。
• gRPC/HTTP2 调整 keepalive 和最大连接年龄，服务端发送 GOAWAY 后给在途请求留出排空时间。
• 检查服务端是否设置了 SO_LINGER 0 或在 close 前丢弃接收缓冲区；正常情况下应使用 FIN 优雅关闭，让在途数据完成。
• 不要为了“消除 RST”把 tcp_abort_on_overflow 打开；它只是把静默丢包变成重置，可能掩盖真正的容量问题。

相关命令

• ss — 查看连接队列和重传状态
• tcpdump — 确认 RST 的方向和阶段
• nstat — 重置、溢出和丢包计数
• nc — 最小化复现端口行为
• curl — 验证 keepalive 和协议
• journalctl — 服务崩溃与重启日志
• kubectl — Pod、端点和事件
• conntrack-full — NAT 会话表问题

参考链接

• RFC 9293: TCP
• Linux tcp(7) 手册
• Kubernetes Pod 生命周期
• Nginx keepalive_timeout

读完自测

合上页面，先回答，再展开对照。

1. connection reset by peer 与 connection refused、连接超时的本质区别是什么？
2. 空闲一段时间后的第一个请求失败、重试后恢复，最可能是什么原因？
3. 如何确认 RST 是谁发出的，以及它发生在哪个阶段？