挑了最快的那一行

TCPing 结果一出来，我习惯先扫最快的那个节点。数字很小，心里就踏实了。

有一次拿这个数去汇报，说「网络没问题」。后来运维同事查到，有一整组节点是失败的，只是我没往下看。

最快节点只代表最好的一条路，不代表所有人都走这条路。而且那次汇报之后，我们真的按「没问题」处理了，直到用户投诉才回头。

成功率是门槛

先看有多少节点握手成功。有失败，说明那段路根本走不通，讨论延迟没有意义。

少量失败，可能是节点自身问题；整组失败，偏目标侧策略或端口限制。

成功率还要结合总节点数看。十个节点成功九个，和五十个节点成功九个，含义完全不同。节点少的时候，一次失败就能把比例拉得很低。

成功率不过关，先解决「通不通」，再谈「快不快」。

TCP 检测：填域名和端口，多节点看连通与握手耗时

TCP 检测：填域名和端口，多节点看连通与握手耗时

延迟要看分布

全部成功之后，再看延迟。

最快、最慢、平均三个数一起。最快代表理想状态，最慢代表最差的那部分用户，平均是中间值。平均值只能说明中间水平，遇到一堆慢节点时，它反而会显得还行。

延迟低的节点如果只占少数，那只是个别线路的表现，别当成整体。

我通常先看最慢那一档。它决定了体验的下限，也最容易暴露链路问题。

三种节点要分开看

成功且快：正常节点，参考价值有限，只能说明路是通的。

成功但慢：最值得研究的一类。集中在某个运营商，偏互联；散布在各处，偏目标出口或容量。

还有一种成功但极慢，握手像是被限速，通常和策略有关。

失败：先确认端口和目标是否正确，再判断是不是策略拦截。

只盯着第一种，等于只看好消息。真正的问题，往往藏在后两种里。

分组能画出边界

在宝塔拨测的 TCP 测速里按运营商和地区分组，成功率和延迟一起看。

某一家运营商整组慢，问题在那条互联；只有某个地区失败，偏区域路由或地方策略。

分组之后，问题从「网络不好」变成一个具体范围。慢节点的分布，比慢节点有几个更值得看。

复测和记录

改完用同一批节点复测，成功率先回到全通，再看延迟有没有下降。

连续测两三次，排除抖动，别在不同时段混着比，高峰的延迟天然更高。记录里带上成功率、最慢节点和分组结论，比只写一个最快值有用得多。

向别人解释时，先说成功率，再说最慢，最后说最快。顺序对了，对方才不会误判。

报告是给人做判断的，不是挑一个最漂亮的数字。