telnet 通了，我还是判断错了

有次排查邮件端口，telnet 一连，显示连接成功，我就说服务没问题。后来用户发不出信，才发现服务握手后直接拒绝了后续命令。

telnet 只完成了握手。它证明不了对面愿不愿意干活。

telnet 做了什么

它建立一个 TCP 连接，然后把你输入的内容原样发过去，把回显原样打出来。

连接成功，说明端口开着、网络可达。之后能不能登录、能不能发命令，取决于服务本身。

它没有统计，没有多节点，也不记录耗时。一次一行，靠人眼看。很多系统默认还没装 telnet 客户端，用 nc 也能达到类似效果。

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

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

TCPing 做了什么

它对同一个目标做多次握手，记录每次的耗时，统计成功率，还能从多个地区、多个运营商同时发起。

在宝塔拨测的 TCP 测速里，你能看到最快、最慢和平均，以及按地区分组的结果。

它走的是 TCP 握手，不依赖 ICMP，被禁 ping 的机器照样能测。

它回答的是「这条路通不通、稳不稳、不同地方差多少」，但它不关心握手之后服务说了什么。

两者的差别在样本和视角

telnet 是单点、单次、可交互；TCPing 是多点、多次、只测量。

一个能看见应用层的第一句话，另一个能看见链路层的分布。一个是「连得怎么样」，一个是「对面是谁」。

结论对不上，往往就是因为问的不是同一个问题：一个说「能连」，一个说「某些地区连不上」，两句都对。

怎么互补

先用 TCPing 扫范围：是不是所有地区都能握手，延迟分布如何，哪一组明显异常。顺序上先扫描、再交互，先用外部视角、再回本地。

再用 telnet 或对应协议的客户端验证应用层。80、443 用 curl，443 也可以看证书；SMTP 用 telnet 看欢迎语；数据库用专用客户端。

TCPing 通过、telnet 有回应，基本可以判定服务正常；TCPing 通过、telnet 没回应，问题在服务进程或应用配置。

telnet 里看到的内容也要判断：有的是欢迎语，有的其实是拒绝信息，别看到字就以为成功。

复测和判断边界

改完用同一批节点复测，先看成功率，再看延迟。

别用 telnet 的一次成功去否定 TCPing 的多点异常，也别用 TCPing 的通去证明应用没问题。

两个工具测的是两段路，拼起来才是完整的一条。结果不一样时，先想清楚各自回答的是哪个问题，别急着说哪个工具错了。