Wireshark分析网络请求："POST 请求发出后，对端返回了一个带有 `RST` 标志位的包"

Posted on Views:

场景其实很典型

Wireshark 看到 POST 请求发出后，对端返回了一个带有 RST 标志位的包，于是客户端报错 connect reset。
这种情况可以从 TCP 层和应用层（HTTP）**两个角度来分析。

一、RST 出现的典型原因

RST 表示 复位连接，意思是对端（或中间设备）强行终止 TCP 连接。常见原因：

  1. 应用层主动关闭

    • 服务器应用（例如 Web 服务）不接受这个连接，直接调用 close()，内核发 RST。
    • 服务端程序崩溃或没有对应端口在监听，也可能发 RST。

  2. 端口/进程不存在

    • POST 发到的端口没进程在监听（比如防火墙拦截了 SYN/ACK）。

  3. HTTP 层错误导致内核复位

    • 发送了 非法的 HTTP 报文（header 格式错误、content-length 不匹配等），应用拒绝并直接 reset。

  4. 连接被中间件/负载均衡干预

    • F5、Nginx、CDN、WAF、IPS/IDS 等安全设备，检测到异常请求（如 CC 攻击、payload 特征），直接复位。

  5. TCP 层状态异常

    • 比如客户端还在发送数据，但服务器认为连接已经关闭（TIME_WAIT/FIN_WAIT/半开连接），于是 RST。

⚠️：最终分析是这个情况：后端keepalive timeout < (小于) 前置负载 keepalive timeout导致的偶发connect reset，在wireshark上看是负载端未收到http响应而标记502。

二、在 Wireshark 中如何分析

你可以按这个顺序排查：

  1. 确认三次握手

    • 看是否有正常的 SYN → SYN/ACK → ACK，确认连接建立成功。

  2. 检查 HTTP 报文

    • Follow TCP Stream，看 POST 请求格式是否正确。
    • 特别注意 Content-Length 是否和实际 body 匹配。

  3. 看 RST 发生的时机

    • 如果 POST 刚发完立刻 RST → 服务端/中间设备主动拒绝。
    • 如果 POST 过程中或传输大 body 时 RST → 可能是 WAF/负载均衡拦截。
    • 如果 先有响应（200/302/xxx）然后 RST → 可能应用处理完后强制关闭。

  4. 看 RST 的方向

    • RST from server → client → 服务端或中间设备复位。
    • RST from client → server → 本地程序不认这个连接。

三、进一步排查建议

  • 应用日志：看服务器 web 应用是否有报错（如 Nginx error.log，Tomcat/Java 日志）。
  • tcpdump 双端对比：在客户端和服务端同时抓包，确认 RST 是谁发的。
  • 防火墙/WAF 日志：排除中间件强制 reset。
  • 抓长 body 的情况：如果 POST 带大数据，看是不是 MTU/分片/超时导致 reset。

👉 总结一句：
POST 后立即 RST，多半是服务端应用拒绝或中间安全设备拦截；POST 传输中途 RST，多半是协议格式异常或 WAF/负载均衡策略触发。