iptables规则按顺序逐条匹配，匹配即执行动作且不再检查后续规则；位置决定优先级，-j跳转需防死循环，-j LOG不终止匹配，conntrack状态匹配依赖模块正常工作。
iptables 规则是按顺序逐条匹配的
规则链（如 INPUT、FORWARD、OUTPUT）里的每条规则，从上到下依次检查数据包是否匹配。一旦匹配成功，就立即执行对应动作（ACCEPT、DROP、REJECT 等），后续规则不再处理该包。
这意味着：位置决定优先级。靠前的规则有更高“话语权”，哪怕后面有更宽泛的规则，也根本没机会生效。
- 常见错误：在末尾加一条
-j ACCEPT允许所有流量，但前面已有-j DROP—— 实际上整条链可能早已被拦截，这条允许形同虚设 - 调试建议：用
iptables -L --line-numbers查看规则序号，结合iptables -vxnL观察各规则的匹配包计数，快速定位哪条规则“截胡”了流量 - 不要依赖“默认策略兜底”来掩盖规则顺序问题；默认策略只在所有规则都不匹配时才触发
同一链中，-j 跳转目标会影响匹配流程
当某条规则使用 -j 跳转到自定义链（比如 -j MYCHAIN），数据包会进入该子链重新从头匹配；子链匹配完后，若未被终止（即没遇到 ACCEPT/DROP 等终止动作），控制权会返回原链的下一条规则继续执行。
这容易导致逻辑绕弯甚至死循环——比如子链末尾又跳回父链，而父链后续规则又跳回子链。
- 务必确保子链内有明确的终止动作，或用
-j RETURN显式返回，避免隐式落到底层默认策略 -
-j LOG不终止匹配，它只是记录日志，之后仍继续匹配下一条规则；常配合-j DROP使用，但顺序不能颠倒（否则日志可能记不到被丢弃的包） - 用
iptables -t nat -L -n -v查看nat表时要注意：SNAT/DNAT 规则只在连接首次建立时触发，后续包由连接跟踪自动处理，不重复匹配规则
连接状态（state）匹配依赖 conntrack 模块，不是“规则顺序”本身的问题，但影响实际效果
iptables -m state --state ESTABLISHED,RELATED -j ACCEPT 这类规则之所以常放在开头，是因为它们能快速放行海量回程流量；但它的生效前提是内核已加载 nf_conntrack 模块，并且连接跟踪表未满或未异常失效。
如果 conntrack 异常（比如表满、模块未加载、或被禁用），ESTABLISHED 匹配永远失败，所有依赖它的规则都会退化为普通匹配，极易误拦合法流量。
- 检查 conntrack 是否工作：
cat /proc/sys/net/netfilter/nf_conntrack_count与/proc/sys/net/netfilter/nf_conntrack_max对比 - 临时加载模块：
modprobe nf_conntrack；永久启用需确认nf_conntrack_ipv4（IPv4）或nf_conntrack_ipv6（IPv6）已列入/etc/modules -
--state已被标记为废弃，推荐改用-m conntrack --ctstate，语义更清晰且兼容性更好
iptables-restore 加载规则时，顺序由文件内容决定，而非执行时间
通过 iptables-restore 导入规则文件时，规则顺序完全取决于文件里 *filter 或 *nat 段内的书写顺序。即使某条规则在文件里写得晚，只要它出现在前面，就会先被加载、先生效。
很多人误以为“后执行的命令会覆盖前面的”，但在 iptables-restore 场景下，整个链会被清空并重置，最终顺序只由文件文本顺序决定。
- 备份当前规则用
iptables-save > rules.v4，这是唯一能保留真实顺序的快照方式 - 编辑规则文件后，务必先用
iptables-restore -t 做语法校验，避免因格式错误导致整条链被清空 - 不要混用
iptables -A和iptables-restore管理同一链；前者追加，后者全量覆盖，极易引发规则错乱
规则顺序看着简单，但真正出问题时，往往卡在 conntrack 状态异常、LOG 和 DROP 顺序颠倒、或 restore 文件里隐藏的空行/注释干扰解析——这些地方不报错，却让流量行为完全偏离预期。
