ACL 故障的典型特征
网络 ACL 作用在子网层，是无状态的三层过滤：放行入方向请求的同时，还要单独放行出方向的返回流量。它的故障特征相当典型——同一子网内的多台实例同时异常、换实例依旧不通、抓包能看到请求但看不到回包。定位顺序是先确认子网绑定了哪个 ACL，再逐条核对入站与出站规则。
基本信息
| 作用层级 | 子网级，影响该子网内所有实例 |
|---|---|
| 状态特性 | 无状态：出入方向要分别放行 |
| 匹配方式 | 按规则序号从小到大匹配，命中即生效 |
| 默认规则 | 每个新 ACL 都带允许全部流量的默认规则（编号最小） |
| 与安全组关系 | 两者都放行才通过，是串联关系 |
定位步骤
- 确认实例所在子网关联的是默认 ACL 还是自定义 ACL
- 检查入站规则：请求方向的端口与源网段是否放行
- 检查出站规则：返回方向的端口段是否放行（无状态的关键）
- 用临时放行做对照测试，确认故障是否由 ACL 引起
- 仍未恢复则结合流日志与安全组继续排查
对照测试示例
对照测试示例
python3 -m http.server 18080 & # 在目标机上起一个测试端口
nc -zv -w 3 <目标机IP> 18080 # 从对端验证 TCP 连通性
tcpdump -i eth0 port 18080 -c 20 # 目标机抓包：看请求到没到
iptables -L -n -v 2>/dev/null | head # 实例内若有本地防火墙也要放行故障特征对照
| 现象 | 更可能是 | 验证方法 |
|---|---|---|
| 同子网多台实例同时不通 | ACL 或子网路由问题 | 换一台实例复测 |
| 只有单台实例异常 | 实例本身或安全组 | 对比同子网其他实例 |
| 请求能到、回包不到 | 出方向被 ACL 拦截 | 两侧抓包对照 |
| 偶发不通 | 规则序号冲突或路由抖动 | 查规则顺序与流日志 |
ACL 是无状态的：只放行入方向的请求端口不够，返回流量使用高位随机端口，出方向规则要覆盖对应范围，否则会表现为单向不通。
用于排障的临时放行规则用完应及时回收，长期留在生产环境等于持续扩大暴露面。