服务连不上：先分清是没人监听、被墙，还是队列满了

「连不上」是一句含糊的描述。refused 说明对端明确拒绝（没人监听或被拒规则拦），timeout 说明包没回来（网络或防火墙丢包），reset 说明连接被中途掐断（中间设备或应用层）。

这三种现象对应的排查工具完全不同，混着查会浪费大量时间。

先说结论

先拿到确切错误类型，再用 ss 看本机状态，最后 tcpdump 确认包到没到。

• refused → ss -lntp 看有没有监听
• timeout → tcpdump 看 SYN 有没有回
• reset → 查中间设备/连接数上限
• TIME_WAIT 多 → 看是否短连接过多
• conntrack 满 → dmesg 有 nf_conntrack 报错

先把问题说清楚

云环境还有一层安全组：本机 iptables 放行了，安全组没放，表现就是 timeout。

高并发短连接场景下，TIME_WAIT 会吃满本地端口，表现为「连不上但有监听」。

具体怎么做

按顺序执行，每步都验证完再进下一步：

• 记录确切错误：Connection refused / timed out / reset by peer
• ss -lntp | grep 端口 确认监听地址（0.0.0.0 还是 127.0.0.1）
• ss -s 看连接总量与 TIME_WAIT 数量
• tcpdump -i any -nn port 端口 抓包，看 SYN 是否有 SYN-ACK
• 查安全组/防火墙与 conntrack 上限（sysctl net.netfilter.nf_conntrack_count）

参数与成本对照

把关键数值摊开，方便判断该选哪条路：

几个容易踩的坑

下面这些是最常见的错误做法：

• 只在本机 curl 127.0.0.1 就认为没问题：绕过了防火墙和安全组
• 改 iptables 不开持久化，重启后失效
• 把 TIME_WAIT 调到极小值：可能引发端口复用冲突
• 忽略 IPv6：监听在 :: 上，v4 连不上

最后补两句

把三种错误类型记牢，排查效率会立刻不一样：refused 查监听，timeout 查链路，reset 查中间层。

工具是手段，理解机制才是能力。命令记不住没关系，知道「该看什么」就够了。