阿里云防火墙端口开放——不通多半在回程链路

端口在控制台里放行了，telnet 过去还是卡在超时——这种情况下先别急着回头改规则。十有八九，包已经进了门，回程那一段半路被丢了。阿里云防火墙端口开放这个动作本身不复杂，麻烦的是它跟安全组、系统里的 iptables、路由表这几层的关系，哪一层没对齐，你看到的现象就永远是”不通”两个字。

阿里云防火墙端口开放，其实是两处动作

很多人以为控制台里点一下”允许”就完事了，实际能拦你的地方至少有两层：安全组，挂在实例上的虚拟防火墙；还有云防火墙，管的是更靠外的南北向边界。有人只在前者加了规则，后者还是默认策略；也有人反过来，只动了云防火墙，安全组那条默认拒绝还稳稳挂着。两边都放行、方向也对，才算真正过了第一关。至于哪层优先、默认是白名单还是黑名单，各家版本差别不小，以控制台上的提示和官方文档为准，照着网上老教程抄容易抄错。

出方向没放，回程一样断

入方向大家都会看，出方向九成人不点开。默认模板多数是全放通的，所以平时不出问题，可有些镜像自带一套收紧的 iptables 规则，OUTPUT 链上挂着 DROP；还有自建 NAT、内网代理的环境，回包在出本机之前就被掐了。请求能进来，回复出不去，现象和”端口没开”一模一样。查法很简单，iptables -L -n -v 看 OUTPUT 链的 DROP 计数有没有随着你的测试往上涨，比盯着控制台猜快得多。

回程链路才是最容易冤枉防火墙的地方

一台机器挂了两块弹性网卡，或者加了策略路由、走了 VPN、专线，请求从公网进来走的是 eth0，回包按路由表却从 eth1 或者隧道出去了。源地址跟对端期待的对不上，对端直接丢包，你这边看到的就是超时。容器环境更明显，overlay 网络、NodePort 转发、SNAT 规则一圈绕下来，回程走的不一定是进来的那条路。

判断办法笨但管用：两头同时抓包。客户端 tcpdump -n tcp port 8080，服务端抓同一条。看 SYN 有没有到、SYN-ACK 发出去没有、发出去时的源 IP 是不是客户端认的那个。如果服务端明明发了 SYN-ACK 而客户端啥也没收到，问题就不在防火墙上，去查路由和回程，省得在规则里绕圈。

服务只听 127.0.0.1，端口开了也白开

ss -lntp 或者 netstat -lntp，看 LISTEN 那一列的地址。写着 127.0.0.1:8080 的，外面怎么连都进不来；得是 0.0.0.0:8080 或者具体的内网地址才行。nginx、Redis、MySQL 默认只听本地的配置并不少见，配置文件里改一行 bind 或者 listen 就解决。别漏了 IPv6：ss 里显示 [::]:8080 和 0.0.0.0:8080 不是一回事，有的系统 v6 优先，而你的防火墙规则只写了 v4，测起来就像随机不通。

还有几个常被忽略的小坑

端口号写错一位，比如该是 8080 写成 80；协议选错，UDP 服务只在 TCP 上放行；运营商侧对 25、135 这类端口有限制，本地全放开照样连不上；用了负载均衡的，后端端口和健康检查端口往往不是同一个；安全组里还躺着一条优先级更高的拒绝规则，把后面的允许全盖住了。机器刚重启、服务还没起来就去测，也是常见的一类”假故障”。

顺着查的一条路线，别跳步

第一步，本机 ss -lntp 确认监听地址和端口；第二步，本机 curl 127.0.0.1:端口，验证服务本身活着；第三步，同 VPC 里另一台机器 curl 内网 IP:端口，把公网因素摘出去；第四步，公网 telnet IP 端口；第五步，两端 tcpdump 对着看；第六步，route -n 和 ip rule 看回程怎么走。每一步卡在哪，问题就落在哪一层。跳着做最容易得出”防火墙有毛病”这个结论，然后白折腾半天。

规则改一次记一次，一条一条加，别一口气动五个地方。真出问题时你至少知道是哪一刀切歪的。端口不通这事儿，十次里有六七次不在规则表上，而在回程和监听地址上，抓包比改配置诚实。