iptables规则按顺序匹配，DROP优先于ACCEPT导致后续ACCEPT不生效；ufw与iptables混用会互相覆盖；conntrack表满使NEW包被误拒；nftables与iptables后端不一致引发链跳转失效。
iptables 规则顺序导致 DROP 优先于 ACCEPT
Linux 的 iptables 是按顺序匹配规则的，一旦某条规则匹配成功（比如一条 DROP），后续规则就不再检查。常见误操作是先加了全局 DROP，再加 ACCEPT，结果后者根本没机会生效。
排查方法：
- 运行 sudo iptables -L -n -v --line-numbers 查看带行号和包计数的规则列表
- 关注 pkts 列：如果某条 ACCEPT 规则的计数始终为 0，而它前面的 DROP 计数持续增长，基本就是顺序问题
- 临时调整：用 sudo iptables -I INPUT 1 -p tcp --dport 22 -j ACCEPT 把 SSH 规则插到最前面测试
ufw 和 iptables 同时启用引发双重拦截
ufw 本质是 iptables 的封装，两者共存时容易互相覆盖或重复加载规则，尤其在重启后 ufw 自动重载可能清掉你手动加的 iptables 规则。
判断是否冲突：
- 执行 sudo ufw status verbose，观察输出里是否有 “Status: active”
- 再执行 sudo iptables -L INPUT | head -10，对比规则内容是否与 ufw 声明的一致
- 若 ufw 已启用，**不要直接用 iptables -A 添加规则**，应改用 ufw allow 或修改 /etc/ufw/before.rules
conntrack 状态干扰导致 NEW 包被拒绝
某些防火墙规则依赖连接状态（如 -m state --state RELATED,ESTABLISHED -j ACCEPT），但若系统启用了 nf_conntrack 且连接跟踪表溢出，新连接的 NEW 包可能无法正确标记状态，进而被后续规则误判丢弃。
验证方式：
- 查看 conntrack 表使用率：sudo cat /proc/sys/net/nf_conntrack_count 和 sudo cat /proc/sys/net/nf_conntrack_max
- 检查内核日志是否有 nf_conntrack: table full 报错：sudo dmesg | grep conntrack
- 临时缓解：增大上限 sudo sysctl -w net.nf_conntrack_max=131072，长期需优化服务连接复用或清理僵尸连接
nftables 与遗留 iptables 规则混用时链跳转失效
从较新内核（5.10+）开始，很多发行版默认启用 nftables 并通过 iptables-nft 兼容层运行旧命令。此时 iptables 命令实际操作的是 nftables 后端，但如果你手动写了 nft 规则又混用 iptables-save 导出，容易出现链不存在、跳转目标不识别等问题。
确认当前后端：
- 运行 sudo iptables -V，若输出含 “nft”，说明走的是 nftables 后端
- 查看真实规则：sudo nft list ruleset，比 iptables -L 更可信
- 避免混用：要么全用 nft 命令管理（推荐），要么确保系统未启用 nftables 服务并卸载 iptables-nft 包
规则顺序、工具层级、状态模块、后端一致性——这四点交叉影响最大，但文档常分开讲。实际排查时，先盯住 iptables -L -v --line-numbers 的包计数，再结合 dmesg 和 nft list ruleset 对照，多数冲突能快速定位。
