TCP RST 和连接重置 PCAP 分析:谁关闭了连接以及原因

“连接由对等方重置”是 HTTP 客户端、数据库、TLS 工具、代理和自定义 TCP 应用程序中的常见错误。用户搜索“TCP RST pcap 分析”、“对等 Wireshark 重置连接”、“SYN 后的 RST”、“TLS 连接重置”和“防火墙 TCP 重置”，因为他们需要知道是谁终止了连接以及重置是否来自应用程序、操作系统、防火墙、负载均衡器或服务器。

TCP RST 是显式的。它说“中止此连接”。困难的部分是归因。

PCAP 手术非常有用，因为重置调查需要在重置之前进行干净、集中的跟踪，其中包含方向、时间戳、序列号和足够的数据包。

常见的重置模式

RST 可能发生：

• 紧接在 SYN 之后。
• SYN-ACK 之后。
• 在 ClientHello 之后。
• HTTP 请求之后。
• 空闲超时期间。
• 协议数据无效后。
• 当应用程序关闭未读数据的套接字时。
• 当防火墙拒绝策略时。
• 当负载均衡器没有健康的后端时。
• 当服务器进程崩溃或拒绝状态时。

时间告诉你去哪里寻找。

谁发送了 RST

首先识别复位报文的源IP、源端口、目的IP、目的端口。如果服务器 IP 发送 RST，则服务器端或冒充该端的某些东西会结束它。如果客户端IP发送RST，则客户端结束它。如果 TTL、MAC 或路径行为表明存在中间件，则可能会注入重置。

不要仅依赖应用程序措辞。 “Reset by Peer”可以由接收到RST的一方报告。

SYN 后复位

SYN 之后的 RST 通常意味着端口已关闭或策略拒绝连接。如果 SYN 立即收到 RST，则应用程序永远不会达到 TLS 或 HTTP。

寻找：

• SYN -> RST,ACK
• 无服务器问候
• 无申请数据
• 跨尝试的一致行为

这不是证书失败或 HTTP 错误；这是 TCP 可达性/服务状态故障。

在 TLS 期间重置

ClientHello 之后的 RST 可能是由错误的端口、不支持的 TLS、SNI 不匹配、中间盒策略或服务器拒绝引起的。保留 DNS 和 ClientHello 元数据，以便您可以查看主机名、ALPN、TLS 版本和计时。

如果重置在 TLS 警报之后到达，则警报比重置提供更多信息。如果没有警报，则重置可能是较低级别的或策略驱动的。

请求后重置

HTTP 请求、数据库查询或协议命令之后的 RST 通常意味着应用程序足以拒绝请求或崩溃。这也可能意味着代理因上游不可用而关闭。

关联：

• 最后发送的应用程序字节。
• 服务器有响应或无响应。
• 复位前的空闲时间。
• 后端/负载均衡器日志。
• 重置是否仅针对特定的请求大小发生。

Checklist

使用此工作流程：

1. 识别对话中的第一个 RST。
2. 确定是谁发送的。
3. 检查之前发生的事情。
4. 检查TCP握手是否完成。
5. 检查 TLS 是否已开始或完成。
6. 检查应用数据是否发送。
7. 检查空闲超时时间。
8. 比较中间盒注入的 TTL/MAC/路径线索。
9. 保留重置周围的 DNS、TCP、TLS 和应用程序字节。
10. 使用服务器/负载平衡器日志来确认归因。

最终诊断

TCP RST 是连接中止，但原因取决于时间和发送者。 pcap 可以区分端口关闭、防火墙拒绝、TLS 拒绝、应用程序关闭、空闲超时、负载均衡器故障和中间盒重置。

PCAP 手术有助于保留数据包序列，从而回答最重要的问题：谁重置了连接，以及之前发生了什么？