TCPing 的异常排查，核心是先分清“拒绝”和“超时”。这两个词看起来都是失败，实际指向完全不同的两层。

全部被拒绝

地址可达，端口没服务。

先去服务器上看监听状态：ss -lntp。重点看两件事，端口对不对，监听地址是不是 :: 或 [::]。

只监听 0.0.0.0 的服务，在 IPv6 侧不可达。这不是防火墙问题，是服务根本没接 IPv6 的连接。Nginx 要写 listen [::]:443，Node、Python 的服务要显式绑定 ::。

全部超时

包被丢了，没有任何回应。

查三层：云厂商安全组的 IPv6 入方向规则、服务器上的 ip6tables、机房或链路上的 ACL。

安全组最常见。IPv4 和 IPv6 是两套规则，很多人只配了 IPv4，结果 IPv4 正常、IPv6 全超时。

部分节点失败

先看分布有没有规律。

集中在某个省份或某个运营商，通常是当地 IPv6 出口或地域性 ACL。分散且无规律，可能是目标侧限流。

拿失败节点和成功节点做对比，能快速缩小范围。

有时拒绝有时超时

同一个目标，不同节点返回不同类型，说明路径上的策略不一致。

有的地区防火墙直接丢包，有的地区能到目标但端口没开。这种情况要按地区分别处理，不能指望改一处配置解决所有节点。

握手成功但应用报错

这是另一类问题，不属于 TCPing 的排查范围。

端口通、握手快，但网站返回 502 或一直转圈，说明问题在应用层。用 IPv6 网站测速 看状态码和分段耗时，方向就清楚了。

一个排查顺序

先看失败类型，再看失败分布，最后回服务器确认监听和防火墙。

用 IPv6 TCPing 对 443 和 22 各测一次，两个端口的结果对比，能快速判断是“所有 IPv6 端口都不通”还是“只有某个服务没配好”。这个区分很关键。