linux防火墙拦截请求，通常是因为iptables、nftables或firewalld的规则显式拒绝（REJECT）或丢弃（DROP）了对应流量。关键不是“有没有开防火墙”，而是“规则是否匹配且动作是否阻止”。排查需从连接五元组（协议、源IP、源端口、目标IP、目标端口）出发，结合实际访问场景逐层验证。
确认当前生效的防火墙服务与后端引擎
不同发行版默认工具不同：centos 7/8 默认用 firewalld（底层可能是 nftables 或 iptables），ubuntu 20.04+ 默认用 ufw（封装 iptables/nftables），而较老系统或手动配置环境可能直用 iptables。先明确你在和谁打交道：
- firewalld：运行 sudo firewall-cmd –state 查状态；sudo firewall-cmd –list-all 看当前区域规则
- ufw：运行 sudo ufw status verbose 查启停状态、日志级别和所有规则
- iptables：运行 sudo iptables -L -n -v（查看 Filter 表）和 sudo iptables -t nat -L -n -v（查 NAT 表）
- nftables：运行 sudo nft list ruleset 查全部规则
定位被拦截的具体连接与匹配规则
仅看规则列表常不够——规则顺序决定匹配优先级，且 LOG 规则缺失时无法知道哪条“默默丢包”。推荐组合操作：
- 在服务端用 sudo tcpdump -i any port 目标端口 -nn 确认请求是否到达本机（若没抓到，问题在路由或上游设备）
- 若能抓到包但服务无响应，加一条临时 LOG 规则（如 iptables 中：sudo iptables -I input 1 -p tcp –dport 端口 -j LOG –log-prefix “FW-DROP: “），再查 sudo dmesg | tail -20 看是否触发日志
- 检查规则中是否含 -s 源IP、-d 目标IP、-i 输入网卡 等限制条件，这些易被忽略却导致规则“看似开放实则屏蔽”
修复常见误配：放行端口 ≠ 自动允许所有访问
很多人执行了“开放80端口”却仍无法访问，原因多在规则粒度或链默认策略：
- firewalld：开放端口需指定 zone（如 public），且确保服务绑定的是该 zone 对应网卡；若用 –add-port=80/tcp 但未 –permanent，重启后失效
- ufw：默认策略是 deny incoming，必须显式 sudo ufw allow 80/tcp；若开了 80 却用 httpS 访问，要额外放行 443
- iptables：常错在只加了 ACCEPT 规则，但 INPUT 链默认策略是 DROP —— 新规则必须插在 DROP 前（用 -I INPUT 1 而非 -A INPUT），否则永远不生效
验证修复与防止回归
改完规则别急着关终端，立刻本地测试并检查连接跟踪状态：
- 用 curl -v http://localhost:端口 或 telnet localhost 端口 测试本机通路
- 从另一台机器用 nc -zv 服务器IP 端口 测试外部可达性
- 检查连接跟踪：sudo conntrack -L | grep :端口，看是否有 ESTABLISHED 条目；若只有 SYN_SENT 无后续，说明 SYN 包被拦在半路
- 将关键规则导出备份（如 sudo iptables-save > /root/iptables.rules.bak），避免误操作失联