程序员应该掌握的网络命令telnet、ping和curl

一句“telnet 一下”，把我从服务排查地狱拉回现实

前几天上线遇到奇怪的问题：我们服务调用别的团队服务，日志里一直报找不到下游实例。说实话，当时我第一反应是看代码、看配置，半小时过去还没头绪，最后把运维拉上来，人家一句“先 telnet 一下”，我一脸懵——这话把我的脸憋红了，可就是这一步，把问题给撕开了口子。

说白了，telnet 干的事儿很简单也很直接，它不是远古神器而已，而是用 TCP 去试端口是否能连通。如果你在服务器上 telnet 对方的 IP 和端口，连上了说明目标端口在网络层是开放的，连不上就说明问题还在网络或目标服务根本没启动。ping 是另一件事儿，ping 只能告诉你主机是否能被 ICMP 到达，不能判定端口状况。记住这两者的不同，能让你少绕很多弯路，反正我是这么觉得的。

接下来该怎么排，一句话概括：先看“主机在不在”，其次看“端口通不通”，再看“协议和应用层能不能通”。也就是说你可以先 ping 一下主机确认能到，然后 telnet 主机端口排查端口是否开放。如果 telnet 能通但接口还是不行，那就用 curl 去实际请求接口，看看返回是什么错误，是 4xx 授权问题还是 5xx 服务内部错误。有人可能嫌麻烦，其实浏览器 Network 里右键复制出来的 curl 命令，直接拿到服务器粘贴跑，省时又准。

我得讲两个身边的例子给你们听，说明这套逻辑有多实用。我的同事小张某次遇到服务不通，先是怀疑对方服务挂了，结果 telnet 过去连不上，后来发现是运维在做内网隔离策略，安全组把端口关了，开了端口问题就好了。还有一次是我朋友小李，telnet 能通但接口一直 401，最后发现是请求头里少了一个 token，直接在浏览器里复制 curl 到服务器执行，一次性把问题暴露出来，这比盲目翻代码快十倍。

顺便说一句，telnet 有安全隐患，它会以明文传输登录信息，所以现在远程登录基本不用 telnet，建议只把 telnet 当作端口测试工具。更现代的替代方式是用 nc（netcat）或者 ss、netstat 去看端口状态，用 traceroute 确认路由，用 iptables 或安全组规则去排查被阻断的情况。至于 curl，你完全可以把它当成命令行版的 Postman，-X 指定方法，-H 添头信息，-d 带参数，很多时候把浏览器复制的 curl 粘到服务器上跑，能直接看到真实的接口交互细节。

技术之外，有个很容易被忽视的点，是沟通成本和心理预期。很多开发怕丢人不敢问运维“这到底要干嘛”，结果浪费时间。我同事张姐有句话我很认同：遇到服务不通，先把假设放一边，照着网络—端口—协议—应用这条链一路排下去，不要先把注意力放在代码逻辑上。你会发现，很多“代码问题”其实是网络或权限导致的伪故障。

最后给大家一句容易记住的口头禅，遇到服务不通，先分清是“主机死了”还是“端口闭了”，这一步比写代码还重要。未来我觉得开发和运维的边界会越来越模糊，掌握几条简单又实用的排查套路，比会十个框架更能在突发时救场。你平时遇到服务调用失败时，会先做哪一步？说说你印象最深的一次排查经历和那个瞬间你最想说的话。