端口开放了依然不通；多半卡在回程链路

控制台里安全组那条规则还亮着放行的状态，telnet 上去却一直卡在闪动的光标，等半天蹦出来一句超时。这种时候先别急着怪服务商，端口开放依然不通多半卡在回程链路，也就是数据包返程的那一段出了问题。入方向放行只是把门推开一条缝，包出去以后能不能找到回家的路，完全是另一码事。

「端口开放依然不通多半卡在回程链路」讲的是两个方向

不少人对“开放端口”的理解就停在控制台点一下保存。可一条 TCP 连接要走两趟路：请求包进到这台机器，机器的回应还得能原路或者另找一条路回来。安全组、网络 ACL、子网路由、系统防火墙，一层层都在管这件事，只要有任何一层只放进了“进”没放“出”，你就会看到那个经典画面——端口在列表里明明是放行的，实际连上去照样超时。

更冤的一种情况是入方向写得很细致，出方向却留着一条默认拒绝。这种配置在测试阶段往往没人发现，因为内部互访走的路径不一样，等外部用户一接过来就露馅了。

先搞清楚：包是没到，还是到了回不来

这一步真别猜，抓包最实在。本地开一个 tcpdump 盯着目标 IP 和端口，服务端那边也开一个，比如 tcpdump -n -i eth0 port 8080。如果服务端能看到 SYN 进来、却没有对应的 SYN-ACK 出去，问题就落在回程或本机策略上；要是连 SYN 都没出现，说明包在半路被吃掉了，那就去查路由、查清洗设备、查运营商那边。

回程路径绕圈子，traceroute 和 mtr 会把答案摆出来

traceroute 跑一次只给一个快照，我一般更信 mtr，多跑几十个包，看丢包是从哪一跳开始集中的。要留意的是，去程和回程本来就可以走不同的路，BGP 选路这东西不讲对称；所以你本地看到的路径没问题，不代表对面回来也顺。还有个小坑：ICMP 常被限速，光看星号容易误判，可以换成 TCP 模式的 traceroute -T -p 443 试试。

NAT 会话表和 conntrack，满了也表现为不通

这个现象特别像回程链路出问题：一会儿通一会儿不通，过几分钟自己又好了。路由器的 NAT 会话数、云上 NAT 网关的连接上限、conntrack 表打满，新连接都会被直接丢掉。查 conntrack -S 看统计，或者临时停掉一批客户端再试。另外家里或办公室里访问自己服务器的公网 IP 不通，那个是 NAT 回环的问题，跟服务器本身没关系，别在那儿折腾半天。

出方向策略、清洗设备、回源白名单，三处最容易漏

系统层面先看 iptables -L -n 和 firewall-cmd –list-all，有些安全加固脚本会把出方向也一并收紧。云上还多一层：开了高防或清洗之后，源站往往只允许清洗节点的回源 IP 段进来，其它一律拒掉——这时候用户拿着自己的 IP 直连，当然连不上。具体放行哪些段，以服务商那边的文档和控制台说明为准，别照抄网上的旧列表。

别忘服务自己：监听地址和协议对不上

网络查了一圈没毛病，结果 ss -lntp 一看，服务只听在 127.0.0.1 上，外面的包进得来也没人接。0.0.0.0 和 127.0.0.1 差着十万八千里，这俩搞混的人真不少。还有只监听了 IPv6、IPv4 自然连不通；或者端口开了 TCP，业务跑的却是 UDP，协议对不上当然白搭。顺手再确认一下进程是不是真的起来了，有时候端口显示被占用，占着的是别的程序。

容器、负载均衡、数据库白名单，链路里多出来的层

docker -p 那行看着简单，实际宿主机防火墙、docker 自己写的 iptables 规则都会插一脚；写成 -p 127.0.0.1:8080:8080 的话，等于只给了本机。负载均衡后面的健康检查探不通，多半也是这一串原因里的一个。数据库那种“端口不通”，先去看白名单有没有放对端 IP，这一步比查路由省事得多。

一个不聪明但很有效的顺序：两端抓包，一次只改一样

我自己的顺序大概是这样：先两端抓包确认方向，再看本机防火墙和监听，然后安全组和子网 ACL，接着 traceroute 看回程，最后才是应用层配置。每改一处就记一笔，不然回头连自己动过什么都想不起来，越查越乱。有条件就开两台机器对照着测，比在脑子里推演快得多。

提醒一句：遇到不通，先别急着重装系统，也别急着换服务商。把“进”和“出”分开看，把“到”和“回”分开看，多数问题在半小时内就能定位到某个具体配置。真正难缠的往往不是网络，是我们自己脑子里那个“端口开了就一定通”的预设。