Linux防火墙拦截请求通常因iptables、nftables或firewalld规则显式拒绝或未放行流量；排查需确认请求是否到达主机、规则是否命中且计数增长、顺序与默认策略是否合理，并结合tcpdump和日志验证，同时注意云平台安全组及规则持久化。
Linux防火墙拦截请求，通常是因为iptables、nftables或firewalld的规则显式拒绝或未放行对应流量。排查核心是确认请求是否到达主机、是否被规则丢弃、以及放行规则是否生效且顺序正确。
确认当前启用的防火墙服务
不同发行版默认工具不同，先明确实际运行的服务：
- CentOS/RHEL 7+、Fedora：常用 firewalld（底层可能调用nftables）
- Ubuntu/Debian 默认无firewalld，多直接用 iptables 或 nftables
- 检查服务状态：systemctl status firewalld、iptables -L -n -v、nft list ruleset
- 若多个工具共存（如firewalld + 手动iptables规则），可能互相干扰，建议统一管理
查看匹配计数，定位被拦截的规则
仅看规则列表无法判断是否真在起作用，需结合包计数验证：
- iptables：加 -v 显示数据包/字节计数，例如 iptables -L INPUT -n -v
- nftables：使用 nft list ruleset -a 查看handle，并观察 packets 字段变化
- firewalld：用 firewall-cmd --list-all --verbose 查看带接口、源地址、端口的详细规则；也可临时切换为iptables backend再查计数
- 若某条REJECT/DROP规则的packets持续增长，基本可确认是它拦截了请求
检查规则顺序与默认策略
防火墙规则按顺序逐条匹配，一旦命中即执行动作，后续规则不再检查：
- DROP/REJECT规则若位置靠前，且条件宽泛（如 -s 0.0.0.0/0 -p tcp --dport 80），可能误拦合法流量
- 注意默认策略（iptables -P INPUT DROP）——即使没显式DROP规则，也可能因默认拒绝而拦截
- 临时将默认策略改为ACCEPT：iptables -P INPUT ACCEPT，观察请求是否恢复，可快速验证是否为防火墙导致
- firewalld中，public 区域的默认target是 default（等效于DROP），不是ACCEPT
验证连接路径与日志辅助
单纯看规则不够，需结合网络路径和日志缩小范围：
- 确认请求已到达本机：tcpdump -i any port 80 看是否有入向SYN包；没有则问题在路由、网关或上层设备
- 开启防火墙日志（iptables示例）：iptables -I INPUT 1 -p tcp --dport 80 -j LOG --log-prefix "FW-DROP-80: "，然后查 journalctl -k | grep "FW-DROP-80"
- firewalld支持日志：firewall-cmd --set-log-denied=all，日志出现在 /var/log/firewalld
- 注意：云服务器（如阿里云、AWS）还有安全组，必须同步检查，它在防火墙之前生效
不复杂但容易忽略的是规则持久化与服务重启的影响。修改iptables后忘记保存（iptables-save > /etc/iptables/rules.v4），或firewalld改完没重载（firewall-cmd --reload），都会导致排查结果失真。
