策略拦截怎么排
确认「不是服务本身的问题」之后，剩下的高频嫌疑就是策略拦截。现代环境里一次请求往往要穿过四层策略：云安全组或 NACL、网络防火墙、主机防火墙、应用层白名单。逐层核对的关键是「从外到内、用计数器证明」——不要凭配置界面上的印象判断，而要执行一次真实请求，再看哪一层的命中计数增加了，计数增长的那条规则就是拦截点。顺序上从最外层开始，因为外层一旦拦截，内层根本看不到流量，查内层只会白费功夫。
基本信息
| 方向 | 先确认方向（入站/出站）与五元组，再逐层核对策略 |
|---|---|
| 核对顺序 | 云安全组或 NACL → 网络防火墙 → 主机防火墙 → 应用白名单 |
| 证据 | iptables -v 计数器、firewalld 日志、云平台流日志 |
| 要点 | NAT 环境要确认策略匹配的是转换前还是转换后的地址 |
| 回滚约定 | 为测试临时放行的规则必须写明失效时间，测完立即回收 |
| 抓包对照 | 两端同时抓包可判断拦截发生在去程还是回程 |
典型使用场景
- 端口在目标机上看到监听，但从外部 telnet 不通，怀疑中间被拦
- 同一服务内网可访问、公网不可访问，需定位是哪一层策略
- 新上线的主机或容器访问外部依赖被拒，需核对出站方向策略
- 云上迁移后部分流量不通，需核对安全组与子网级 ACL
- 批量放行端口后个别来源仍失败，需用命中计数确认是否被更靠前的规则拦下
- 单向不通的场景：确认是去程被拦还是回程被丢
看规则与命中计数
看规则与命中计数
sudo iptables -L INPUT -n -v --line-numbers | head -30 # 规则与命中包数
sudo iptables -t nat -L -n -v | head -30 # NAT 表：地址转换是否符合预期
sudo nft list ruleset 2>/dev/null | head -40 # 使用 nftables 的发行版看这里
sudo firewall-cmd --list-all # firewalld 运行配置（zone 与端口）
sudo ufw status verbose # Ubuntu 的简化前端
sudo iptables -Z # 计数器清零做增量对比，清前先记录现值逐层核对要点
| 层次 | 看什么 | 常见坑 |
|---|---|---|
| 云安全组 | 入站与出站规则、关联的实例 | 只改了入站没改出站，部分云平台出站同样受控 |
| 云 NACL | 子网级无状态规则 | 无状态：回包方向端口也要显式放行 |
| 网络防火墙 | 策略、会话表与路由 | 非对称路由导致回包不匹配会话被丢弃 |
| 主机防火墙 | iptables、nftables、firewalld、ufw | 默认丢弃策略下新端口未放行 |
| 应用白名单 | Nginx 的 allow/deny、应用级 ACL | 进程级拒绝日志不显眼，容易漏查 |
用计数器增量定位：执行一次测试请求，对比执行前后 iptables -v 里的包数变化，增长的那条规则就是命中项。这比逐条读配置快得多，也能避免漏掉默认策略这类兜底规则。
双向抓包是最直接的对照：客户端发出 SYN 而服务端没收到，说明包丢在中间设备；服务端收到并回了包而客户端没收到，则问题在回程方向。先确定方向，再去查该方向上的策略，能省掉大量逐层读配置的时间。
为测试临时全放行的规则必须立即回收：这类规则会长期潜伏在配置里，成为最容易被利用的入口。放行时就同时写下回收时间与负责人，避免变成安全债。