ping 不通，tcping 却通了

一台机器 v6 ping 完全没回应，我以为链路断了。同事说试试 tcping，443 一下就通了。

原来对方网络把 ICMPv6 屏蔽了，TCP 一直是好的，白紧张了一小时。

tcping 验证的是握手

它比 ping 更接近业务，但也只是更接近，别把它当成完整验收。

它向目标端口发起 TCP 连接，看能不能完成三次握手。

握手成功，说明端口在监听、路径放行、目标也回应了，这三件事同时成立。

这比 ICMP 更贴近真实业务，因为业务本来就跑在 TCP 上，ICMP 只是探路。

IPv6 PING 测速：v6 回显结果与延迟

IPv6 PING 测速：v6 回显结果与延迟

能看出什么

这一段是它的价值范围，别超出这个范围用，用了就是自找麻烦。

端口开没开，这是最直接的结论，也是排查里最先要确认的。

建连花了多久，能反映网络往返和服务器处理速度，两地对比就知道差在哪。

是明确拒绝还是静默超时，这两者的原因完全不同。用宝塔拨测的 IPv6 检测在多个节点对比同一端口，差异落在哪个运营商，问题就在那一段。

看不出什么

越界使用，就会得出「通了就是好的」这种错结论，后面还得返工。

TLS 能不能握手成功，tcping 不知道，证书问题它一概不管。

HTTP 返回 200 还是 502，它也不知道，上游挂了它也照样通。

页面内容、跳转、资源加载，全在更上层，tcping 到不了那儿。

MTU 分片问题，连上了也未必能传大数据，大文件下载失败就是这么来的。

拒绝和超时要分清

这两种失败，排查方向完全相反，搞反了会走很多弯路。

明确拒绝，通常是端口没监听，或者被策略主动拒绝，这类最好查，日志里能看到。

静默超时，多半是中间设备丢包，或者防火墙直接丢弃，这类最费时间。

双栈与验收

两条腿分别验，报告也分别写，这样才看得出是哪条腿的问题。

v4 和 v6 各跑一轮，分开记录，别混在一起看。

连接层正常、应用层失败，就别再折腾网络，去查服务本身。

验收时把两层结论分开写，别用一个「可以访问」概括，那种写法迟早被追问。

握手能通，只是故事的开头。

故事开头顺利，不代表结局圆满。

所以还得再往上走一层。

往上走，才看得到真正的问题。

这句话我常跟新人说，也常提醒自己。

提醒多了，就成了习惯。

习惯养成了，判断就少出错。

少出错，就是省时间。

时间省下来，能做点正经事。

正经事，往往比救火有价值。