curl命令测试端口，命令这事比你想的测试简单，也比你想的端口有用。

我前几天帮朋友排查一个线上服务，命令他死活说端口开了，测试防火墙也放了，端口可客户端就是命令连不上。我让他执行一条命令：curl -v telnet://192.168.1.10:8080。测试三秒钟后他发来截图，端口连接被拒。命令问题定位了——服务进程根本没监听那个端口。测试他之前用netstat查了半天，端口愣是命令没看出门道。

为什么用curl？测试因为它自带详细输出，能告诉你TCP握手到底走到哪一步。端口你不需要额外装nc、telnet这些工具——大多数服务器上curl是标配，哪怕是最精简的容器镜像也常带着它。

基本用法就一行：curl -v telnet://目标IP:端口。注意是telnet://这个协议前缀，不是http。curl会尝试建立TCP连接，如果通了，你会看到Connected to 目标IP这样的字样，然后卡住不动——因为对方没给你发任何HTTP数据，curl在等。这时候按Ctrl+C退出即可。

如果端口不通，情况分两种。连接被拒绝（connection refused），说明目标机器上没人监听这个端口，或者防火墙直接回了RST包。超时（timeout），那多半是防火墙把包丢了，或者IP根本不可达。这两种区别很关键——前者是服务没起，后者是网络不通，排查方向完全不同。

我习惯再加个--connect-timeout 5参数，避免默认的无限等待。真要排查生产环境，等两分钟才超时太煎熬了。完整命令长这样：curl -v --connect-timeout 5 telnet://10.0.0.5:3306。测MySQL端口、Redis端口、Kafka端口，通通适用。

有个坑得提醒你。curl对telnet协议的支持，在某些版本里表现不太一样。老版本可能不支持telnet://写法，这时候可以用curl -v telnet://IP:端口的替代方案——直接写curl -v IP:端口，curl会自动猜测协议。不过实测下来，主流发行版自带的curl都支持显式telnet协议，不用太担心。

还有个更野的玩法。你测的端口如果恰好是HTTP服务，直接curl -I http://IP:端口，看返回的响应头。如果返回了HTTP/1.1 200 OK，端口肯定通，而且你能确认服务类型。如果返回404，端口也通，只是路径不对。最怕的是返回Connection reset by peer——那说明端口开着，但协议不对，对面可能是个非HTTP服务。

有一次我排查一个奇怪的Nacos集群，节点间通信端口明明通了，但服务注册总是失败。我用curl -v telnet://测了每个节点的8848端口，发现有个节点响应特别慢——连接建立了，但握手耗时超过2秒。后来查出来是那台机器负载过高，网络栈处理不过来。这种细节，光靠ping是测不出来的。

别小看这条命令。它比nc轻量，比telnet客户端通用，比写脚本快。你不需要记一堆参数，核心就一个-v加一个telnet://前缀。剩下的，curl帮你把整个TCP连接过程摊开在你面前。

最后说个段子。有同事问我：“curl不是下载文件的吗？怎么还能测端口？”我说：“你拿菜刀还能拍蒜呢。”工具是死的，用法是活的。下次遇到端口不通的破事，先别急着装工具，试试curl，大概率三分钟内就能给你个明确的方向。