安全组明明放通了，ECS 还是连不上？按这 4 层排查

安全组明明放通了，ECS 还是连不上，很多人会反复改规则、重启实例，问题却原地不动。原因往往不在某一条规则，而在数据包经过的链路上还有别的关卡。下面按从云上到实例内的顺序，用 4 层定位法先找到丢包的一层，再改那一层的配置。

先明确一点：安全组是允许型规则，只放行不拒绝，没有匹配的允许规则，流量默认被丢弃。只看有没有放通是不够的，还要核对方向、协议、端口、源地址和绑定的实例。

第一层：安全组入方向、出方向与关联实例

先确认实例绑定的确实是你正在改的那组安全组，再核对入方向规则：协议是 TCP 还是 UDP，端口是单个端口还是范围，源地址是出口 IP 还是 0.0.0.0/0。把规则加到另一组安全组、把 TCP 写成 UDP、源地址填成内网地址，都会导致匹配失败。出方向也不能忽略，ECS 回包或主动发起连接时，出方向也要放行对应端口和目的地址。端口必须精确对应：放通 443 不等于放通 8080。

第二层：网络 ACL 与子网级控制

安全组无问题时，看子网网络 ACL。它按规则编号从小到大匹配，命中第一条即执行，且有允许也有拒绝。重点查入方向是否放行来源和目标端口、出方向是否放行回包、子网关联的是否为你以为的那张表。常见错误是只改入方向忘了回包，或新加的允许规则被前面一条拒绝规则先命中。

第三层：路由与源目检查

前两层都放行，报文仍可能没走到实例。先查子网路由表：公网访问是否走了正确网关路由，跨 VPC 是否有去程和回程路由。回程不通同样表现为超时。源目检查默认开启时，实例只接收目的地址是自己的报文；承担转发或 NAT 角色的实例，需要按角色关闭源目检查。定位可用 ping、traceroute、telnet、nc -vz 对照：ping 不通偏向路由或禁 ping，telnet 或 nc 超时偏向端口未放行或未监听，traceroute 中断处往往就是关卡。

第四层：实例内监听、防火墙与服务状态

云上全部放行后，再看实例内部：用 ss -tlnp 确认服务是否监听目标端口、是否只绑了 127.0.0.1；用 systemctl status 确认服务运行状态；再查实例内防火墙规则。TCP 可用 telnet 或 nc 探测，UDP 无握手过程，超时需结合日志判断启动报错、监听地址和端口冲突。

排查清单

1. 核对安全组绑定、入出方向、协议端口源地址。2. 检查网络 ACL 顺序、方向和关联子网。3. 检查路由去程回程和源目检查。4. 在实例内确认监听、防火墙和服务日志。按层定位再改对应配置，就不会来回折腾了。