Linux防火墙拦截请求通常因iptables、nftables或firewalld规则显式拒绝或未放行流量；排查需确认请求是否到达主机、规则是否命中且计数增长、顺序与默认策略是否合理，并结合tcpdump和日志验证，同时注意云平台安全组及规则持久化。
直接看 iptables 或 nftables 规则，再结合连接跟踪状态和日志，基本能定位拦截来源。
检查 iptables/nftables 是否主动 DROP/REJECT
大多数拦截来自防火墙规则，而不是内核默认行为。先确认当前生效的规则：
- 传统 iptables：
sudo iptables -L -n -v（看REJECT或DROP行，尤其INPUT和FORWARD链） - nftables（较新系统）：
sudo nft list ruleset，重点找drop、reject语句 - 若用 firewalld：
sudo firewall-cmd --list-all，注意ports、services、rich rules中是否有拒绝策略
注意：iptables -L 默认不显示计数器，加 -v 才能看到匹配包数；没匹配记录的规则可能只是“存在”，但未必是罪魁祸首。
查 conntrack 看连接是否被标记为 INVALID 或已 DROP
连接跟踪表能反映内核对连接的实时判断，比规则更接近真实拦截点：
- 运行
sudo conntrack -L | head -20，观察状态列：INVALID表示连接无法建立或被丢弃（常因反向路径过滤、TCP 校验失败或防火墙提前截断） - 过滤特定目标：
sudo conntrack -L | grep "dst=192.168.1.100"，看对应连接是否处于TIME_WAIT、ESTABLISHED还是直接消失 - 如果大量连接显示
icmp reply或unreplied，说明响应未到达，可能是上游设备拦截，而非本机
注意：conntrack 不显示规则，只显示内核视角的连接状态；INVALID 状态本身不等于“被 iptables 拦”，也可能是 netfilter 的早期校验失败。
抓包确认拦截发生在哪一层
用 tcpdump 判断拦截是发生在本机、网关还是远端：
- 在客户端发包时，本机抓包：
sudo tcpdump -i any port 80 -nn，若能看到 SYN 但无任何响应，说明请求发出后没回包 → 拦截不在本机（可能是网关或服务端） - 同时在目标服务器抓包，对比是否收到 SYN：如果服务器收不到，而客户端能发出去，问题出在中间路径（路由、安全组、ISP 层）
- 重点看是否有
RST包：如果是本机发出的RST，大概率是iptables -j REJECT；如果是远端发来，则不是本机拦截
注意：tcpdump 抓不到被 DROP 的包（它被静默丢弃），但能看到 REJECT 触发的 RST 或 ICMP port unreachable；所以没抓到任何响应，更倾向是 DROP 或路径中断。
检查 sysctl 中的网络过滤开关
某些内核参数会无声拦截，不依赖防火墙规则：
-
net.ipv4.conf.all.rp_filter：设为1时启用反向路径过滤，源 IP 不合法的包会被静默丢弃（常见于多网卡或 NAT 场景） -
net.ipv4.ip_forward：为0时，即使配置了路由，Linux 也不会转发包（影响桥接/容器通信） - 查看命令：
sysctl net.ipv4.conf.all.rp_filter net.ipv4.ip_forward - 临时修复：
sudo sysctl -w net.ipv4.conf.all.rp_filter=0（仅调试用，勿长期关闭）
这些参数不会出现在 iptables 或 conntrack 输出里，但会导致连接“无响应”——最容易被忽略的静默拦截点。
