不少运维人员都遇到过这样的场景：在云服务器上辛辛苦苦配置了几十条iptables规则，业务运行一切正常，可服务器一重启，规则全部消失，端口策略失效，甚至出现安全组明明放行了、机器层面却拒绝连接的诡异情况。这并不是iptables出了bug，而是它的规则默认只保存在内核内存中，重启后自然恢复为空。想彻底解决这个问题，就必须掌握规则的持久化方法。本文将系统讲解iptables-save的用法、各发行版的持久化工具，以及新一代防火墙框架nftables的持久化方案。
一、为什么防火墙规则会丢失
iptables本质上是一个操作Linux内核netfilter模块的用户态工具。你执行的每一条iptables命令，都是在直接修改内核中的规则表，这些规则只存在于内存里，并不会自动写入任何磁盘文件。因此一旦机器重启、内核重新加载，所有通过命令行手动添加的规则都会不复存在。
有些发行版默认安装了持久化组件，会在开机时自动加载一份规则文件，这种情况下规则看起来“不会丢”，但如果你后来手动修改了规则而没有重新保存，重启后加载的仍是旧文件，就会出现配置与预期不一致的问题。所以在动手之前，先搞清楚自己的系统目前用的是什么机制非常重要。
另外还有一种情况：云平台的安全组与系统内部的iptables是两层独立的防线。安全组放行了端口，但系统内iptables规则没有对应条目或被清空，连接依然会被拒绝。排查时不要只看控制台，务必登录机器内部执行iptables -L -n确认实际生效的规则。
二、iptables-save与iptables-restore的基础用法
iptables-save命令的作用是把当前内核中的规则导出为特定格式的文本，输出的内容可以直接重定向到文件保存。例如执行 iptables-save > /etc/iptables.rules 就能生成一份完整的规则快照。导出的内容包含filter、nat、mangle等所有表的规则，格式是iptables专有的结构化文本，不建议手工大幅修改。
与它配对的是iptables-restore，用于把规则文件重新加载到内核中。执行 iptables-restore < /etc/iptables.rules 即可恢复。注意restore是整体替换而非增量追加，也就是说它会用文件中的规则覆盖当前内核里的规则，这一点在操作生产环境时要特别小心，避免覆盖掉其他工具动态添加的规则。
一个常见的运维习惯是把保存和恢复写成开机脚本，例如在/etc/rc.local中追加恢复命令，或者通过systemd的自定义unit在网络启动后执行iptables-restore。这种方式虽然简单直接，但缺少依赖管理和错误提示，建议优先使用下面介绍的发行版官方持久化工具。
三、Ubuntu与Debian系统的持久化方案
Ubuntu和Debian系推荐使用iptables-persistent工具包。安装命令为 apt-get install iptables-persistent，安装过程中会提示是否保存当前IPv4和IPv6规则，选择是之后，规则会被分别写入/etc/iptables/rules.v4和/etc/iptables/rules.v6两个文件。
后续每次修改完规则，不需要重装软件包，只需执行 netfilter-persistent save 即可把最新的内核规则写入上述文件。对应地，netfilter-persistent reload 命令可以在不重启的情况下重新加载规则文件，方便验证配置是否正确。这个工具本质上是在systemd中注册了一个netfilter-persistent服务，开机时自动执行restore动作。
需要提醒的是，IPv4和IPv6规则是分开管理的。如果你的服务器启用了IPv6，记得用ip6tables同样配置一套规则并保存到rules.v6，否则IPv6流量将不受任何过滤限制，这是一个很容易被忽视的安全盲区。
四、CentOS与RHEL系统的持久化方案
CentOS 7及类似版本使用iptables-services包来管理持久化。先安装 yum install iptables-services，然后执行 systemctl enable iptables 设置开机自启。规则文件固定存放在/etc/sysconfig/iptables，保存命令为 service iptables save，这条命令会调用iptables-save把当前规则写入该文件。
修改规则后务必养成执行保存命令的习惯。有些人在机器上调通了规则就不再管保存这一步，结果一次系统更新触发的重启让所有配置归零。另外要注意firewalld与iptables-services是冲突的，如果机器上同时启用了firewalld，需要先执行systemctl disable firewalld并停止该服务，否则两套工具互相抢夺netfilter控制权，规则行为会变得难以预测。
在较新的RHEL 8及以上版本和对应的社区发行版中，系统默认转向了nftables，传统的iptables命令实际上是iptables-nft后端，规则最终以nftables的形式存储。此时更推荐直接使用nftables体系，或者安装iptables-services继续沿用旧的工作流，两种方式选一种即可，不要混用。
五、nftables的原生持久化方案
nftables是netfilter项目的新一代框架，从设计之初就考虑了配置文件的管理。它的规则语法与iptables完全不同，采用层级结构表达表、链、规则，可读性更好，且原生支持在一个表中同时管理IPv4和IPv6，也就是所谓的inet地址族。
nftables的持久化非常直接：规则写在/etc/nftables.conf文件中，通过systemctl enable nftables设置开机加载。手动导出当前规则用 nft list ruleset > /etc/nftables.conf，加载配置文件用 nft -f /etc/nftables.conf。整个过程不需要额外的第三方工具，系统自带机制就能完成。
下面用表格对比两套方案的核心差异：
| 对比项 | iptables方案 | nftables方案 |
|---|---|---|
| 规则存储 | /etc/sysconfig/iptables 或 rules.v4 | /etc/nftables.conf |
| 保存命令 | iptables-save / service iptables save | nft list ruleset 重定向 |
| IPv4与IPv6 | 需要分别配置两套 | inet族可统一管理 |
| 语法风格 | 命令式，逐条添加 | 声明式，结构化配置 |
| 适用系统 | 传统发行版广泛兼容 | 较新内核与新发行版默认 |
六、验证与故障排查技巧
完成持久化配置后，验证方法很简单：先执行保存命令，然后重启服务器，登录后运行 iptables -L -n 或 nft list ruleset 查看规则是否完整恢复。也可以不重启，直接执行reload命令加载文件，观察是否有报错输出，这样能更快发现语法问题。
排查规则丢失问题时，建议按以下顺序检查：第一，确认持久化服务是否开机自启，用systemctl status查看状态；第二，检查规则文件内容是否为最新版本，比对时间戳；第三，查看系统日志中restore阶段是否报错，规则文件中如果有语法错误，加载会整体失败；第四，确认没有其他工具（如Docker、Kubernetes）动态修改规则造成覆盖。
特别要注意容器环境的影响。Docker会大量操作iptables的nat表和filter表，如果你的自定义规则与Docker的链有交叉，保存和恢复时要谨慎，最好把自定义规则放在独立的自定义链中，并在DOCKER-USER链中处理需要控制的流量，避免与Docker的自动化管理冲突。
总的来说，防火墙规则丢失的根因是规则只存于内存，解决办法就是建立规范的保存与加载流程。老系统用iptables-persistent或iptables-services，新系统可以拥抱nftables的原生配置文件机制，再配合严谨的验证步骤，就能彻底告别重启丢规则的烦恼。
iptables持久化nftables防火墙规则丢失修改时间：2026-09-09 13:49:11