在线 -
搜索 AIGC编程网
← 返回题目列表

Connection reset by peer 是什么意思？RST 包常见原因有哪些？

高频 中等 第 13 / 26 题 更新于 2026/07/31
RSTConnection resetTCP网络排查

简化版

Connection reset by peer 表示连接被对端或中间设备用 TCP RST 强制重置。常见原因包括应用主动关闭异常连接、端口未监听、防火墙或负载均衡重置、协议不匹配、连接空闲超时后被复用、服务崩溃。排查要抓包确认 RST 从哪一端发出。

详细版

TCP 正常关闭通常是 FIN 四次挥手，RST 是强制中止连接。客户端读写时收到 RST，就可能报 Connection reset by peer。这不一定是网络丢包，更多时候是对端应用、代理、负载均衡或防火墙主动拒绝。

排查思路：

  • 看 RST 是谁发的：客户端、服务端还是中间设备；
  • 看发生阶段：握手时、请求发送后、响应中、空闲复用时；
  • 查应用日志、LB 日志、超时配置、协议配置；
  • 对比是否只在大包、长连接、特定路径或特定客户端出现。

完整版教学

一、RST 和 FIN 的区别

FIN 是正常关闭，表示“我这边数据发完了”；RST 是重置连接，表示“这个连接不要了，立即中止”。应用看到 RST 时，通常不会再把连接当成可恢复状态。

normal close: FIN -> ACK -> FIN -> ACK
abort close:  RST

所以 Connection reset 更像突然挂断电话，而不是礼貌说再见。

二、RST 可能由谁发出

RST 可以由服务端发，也可以由客户端发，还可能由中间设备伪造或注入，例如防火墙、负载均衡、代理。

client <-> firewall/LB <-> server

如果只看应用错误日志，很难知道是谁发的 RST。抓包时要看源 IP、TTL、序列号和链路位置，必要时两端同时抓包。

三、握手阶段的 RST

客户端向一个没有监听的端口发 SYN，目标主机可能直接回 RST。这通常表现为 Connection refused。

client SYN -> server closed port
server RST -> client

这种情况要查服务是否监听、端口是否正确、容器端口是否映射、负载均衡后端是否健康。

四、数据传输中的 RST

连接建立后发送请求，对端应用发现协议错误、请求太大、鉴权失败、连接状态异常，可能主动关闭甚至 reset。代理也可能因为超时或规则拒绝发送 RST。

client sends HTTP to TLS port
server/proxy resets connection

协议不匹配很常见，比如把 HTTP 明文发到 HTTPS 端口，或者客户端说 HTTP/2 但服务端只支持 HTTP/1.1。

五、空闲连接复用导致 reset

连接池复用长连接时，如果服务端、NAT 或负载均衡已经关闭了空闲连接，客户端还以为连接可用。下一次写入可能收到 RST。

connection idle 120s
LB idle timeout 60s
client reuses connection -> RST

解决方法包括设置合理 idle timeout、借出前检查、失败后重试一次、让客户端空闲时间短于服务端超时。

六、抓包如何定位

抓包中看到 [R] 或 [R.] 标记就是 RST。关键是看 RST 的源地址和发生前的最后几包。

client -> server: PSH request
server -> client: RST

如果服务端抓包没看到自己发 RST，但客户端看到来自服务端 IP 的 RST，可能是中间设备伪造或在服务端之前注入。双端抓包能快速验证。

七、排查 checklist

建议按阶段排查：握手前查监听和防火墙，握手后立即 reset 查协议和 TLS，传输中 reset 查应用异常和请求大小，空闲后 reset 查连接池和 idle timeout。

阶段常见原因
SYN 后 RST端口未监听
TLS 握手 reset协议/证书/SNI
请求后 reset应用拒绝/代理规则
空闲后 resetLB/NAT idle timeout

记忆钩子：RST 不是“网络自己坏了”，而是某一端或中间设备明确说“这条连接作废”。

八、常见误区与追问

  • 误区：Connection reset 一定是服务端应用崩了。 中间设备、协议不匹配、空闲超时也常见。
  • 误区：RST 和 FIN 都是正常关闭。 RST 是强制中止，语义更粗暴。
  • 误区：客户端看到服务端 IP 发 RST 就一定是服务端进程发的。 中间设备可能伪造源 IP。
  • 追问：如何确认 RST 来源？ 两端同时抓包，对比 RST 是否出现在服务端出口。
  • 追问：空闲连接 reset 怎么解决？ 调整连接池 idle、LB timeout、心跳或失败重试。
  • 追问：HTTP 发到 HTTPS 端口会怎样？ 常见表现是 TLS 握手失败或连接被 reset。
  • 追问：RST 会不会丢数据？ RST 会中止连接，未读取或未确认的数据可能丢弃。

九、加强记忆

Connection reset 要按 TCP RST 理解：连接被强制作废。排查时先定位阶段，再定位来源。握手阶段看监听和端口，TLS 阶段看协议和 SNI，请求阶段看应用和代理规则，空闲复用看连接池与超时。抓包是最可靠的证据，尤其是双端抓包判断 RST 到底从哪里冒出来。