iptables规则冲突本质是匹配路径上的逻辑断点或覆盖，如宽泛accept前置导致后续限制失效、established规则被拒在drop之后；解决需看清执行顺序、定位关键断点、最小干预恢复通路。
iptables 规则冲突不是“规则多了就打架”，而是数据包匹配路径上出现了逻辑断点或覆盖——比如一条宽泛的 ACCEPT 写在精细策略前面，后面所有限制都失效；或者 ESTABLISHED 规则被挡在拒绝规则之后，导致 SSH 一断就连不上。解决核心是看清执行顺序、定位关键断点、用最小干预恢复通路。
先看清楚：带行号+数值化查全貌
别只跑 iptables -L，它隐藏细节、自动反向 DNS、不显计数，容易误判：
- 查 INPUT 链（最常出问题）：
sudo iptables -L INPUT -n --line-numbers -v—— 行号帮你精准删改，-v 显示包/字节计数，一眼看出某条规则是否真生效 - 查 NAT 表端口映射：
sudo iptables -t nat -L PREROUTING -n --line-numbers—— 确认 DNAT 是否存在、目标 IP 和端口是否匹配容器实际监听地址 - 查 FORWARD 链（Docker/VM 关键）：
sudo iptables -t filter -L FORWARD -n --line-numbers | grep -E "(DOCKER|DROP|REJECT)"—— 快速定位是否被提前拦截
快速识别三类典型冲突模式
以下情况一出现，基本就是规则失控信号：
- 顺序颠倒：例如 “拒绝所有 ICMP” 规则写在 “放行 ESTABLISHED 连接” 前面，导致已建立连接的回包被拒，SSH 断连后无法恢复
-
宽泛覆盖：中间某行写着
-A INPUT -j ACCEPT，它会让其后所有规则（包括你刚加的 DROP）彻底失效 -
重复与矛盾：同一网段既被
ACCEPT又被DROP，且两条规则都未加-i或-o限定接口，系统按顺序执行，后一条实际生效，但你可能根本没意识到前一条还挂着
安全调整：删、移、合、固四步走
不建议清空重来，而应分步修复，避免服务中断：
-
删冗余：用行号精准删除，如
sudo iptables -D INPUT 7删第 7 条；或按条件删，如sudo iptables -D INPUT -s 10.0.0.0/8 -j DROP -
移顺序：把基础规则提到最前——本地回环（
-i lo）、已建立连接（-m conntrack --ctstate ESTABLISHED,RELATED）、管理白名单（如-p tcp --dport 22 -s 192.168.10.0/24） -
合同类：多个端口合并成一条，减少规则数量和匹配开销，例如：
-p tcp -m multiport --dports 22,80,443 -j ACCEPT -
固底线：设默认策略而非最后加
-j DROP，执行sudo iptables -P INPUT DROP—— 它不可被后续规则绕过，是真正兜底
特殊场景：Docker / UFW / firewalld 共存时的避坑要点
这些工具不是“配合 iptables”，而是主动接管 netfilter，手动规则极易被覆盖：
-
Docker 环境：自定义过滤规则必须加到
DOCKER-USER链（iptables -I DOCKER-USER ...），它位于所有 Docker 自动规则之前；宿主机本地访问（curl localhost）才加 INPUT 链 -
UFW 启用中：手动
iptables命令无效，规则会被ufw-before-input链拦截；需改写/etc/ufw/before.rules（预处理）或/etc/ufw/after.rules（后处理） -
firewalld 运行时：不要直接操作 iptables；要么停用 firewalld 改用 iptables-services，要么把
docker0接口划入dockerzone 并开启 masquerade，让 firewalld 统一纳管
