两套配置为什么容易踩坑
firewalld 同时维护运行时与永久两份规则：不带 --permanent 的修改只影响运行时，立即生效但重启后消失；带 --permanent 的修改写入配置文件，需要 reload 才加载进运行时。理解这条机制，就能解释两类常见现象——『重启后规则没了』和『命令执行了但没生效』。排查规则问题时，把两份配置都列出来对比是最快的入口。
基本信息
| 运行时查看 | firewall-cmd --list-all、--list-ports |
|---|---|
| 永久查看 | firewall-cmd --list-all --permanent、--list-ports --permanent |
| 固化当前运行时 | firewall-cmd --runtime-to-permanent |
| 重载 | firewall-cmd --reload（丢弃未固化的运行时改动） |
| 完全重载 | firewall-cmd --complete-reload（重建全部规则） |
| 权限要求 | root 或 sudo |
典型使用场景
- 临时放行端口做联调，确认无误后再固化
- 排查规则失效时对比运行时与永久两份配置
- 交付前把联调期间的临时放行固化或清理干净
- 批量下发规则时统一用 --permanent 加 reload 的方式
- 演练与回滚：用运行时改动快速试错，不影响重启后的基线
两套配置操作
两套配置操作
firewall-cmd --add-port=9090/tcp # 仅运行时，重启即失效
firewall-cmd --list-ports # 看运行时端口
firewall-cmd --list-ports --permanent # 看永久侧端口
firewall-cmd --runtime-to-permanent # 把当前运行时整体固化到永久配置
firewall-cmd --reload # 重新加载永久配置（未固化改动被丢弃）
firewall-cmd --check-config 2>/dev/null || echo '永久配置存在问题'对比与排错
对比与排错
diff <(firewall-cmd --list-all) <(firewall-cmd --list-all --permanent) # 两份配置差异一目了然
firewall-cmd --zone=public --list-all --permanent | head -20 # 指定区域核对
systemctl status firewalld --no-pager | tail -5 # 服务状态与最近报错
journalctl -u firewalld -n 20 --no-pager # reload 报错时看这里
cp -a /etc/firewalld /etc/firewalld.bak.$(date +%F) # 大批量改动前先备份配置目录runtime 与 permanent 对比
| 维度 | runtime | permanent |
|---|---|---|
| 生效时机 | 立即生效 | reload 或重启后生效 |
| 重启后是否保留 | 不保留 | 保留 |
| 查看方式 | 默认参数 | 追加 --permanent |
| 典型命令 | --add-port、--add-service | --add-port ... --permanent |
| 被 reload 影响 | 未固化的改动被丢弃 | 重新加载为运行时规则 |
| 适用场景 | 临时试错、联调 | 基线配置、交付固化 |
--reload 会丢弃未固化的运行时改动：已经调试通过的临时放行要先 --runtime-to-permanent 再用 reload，否则一次 reload 就把改动清掉。
--complete-reload 会重建全部规则并可能中断已建立的转发会话：生产环境优先使用 --reload，只在规则结构混乱需要彻底重建时用它。