firewalld 的 --reload 是 runtime 与 permanent 配置的同步操作，不中断现有连接；仅加载带 --permanent 的规则，不清理临时规则；需确保服务运行、语法正确、区域绑定更新。
Firewalld 的 --reload 是实现安全规则“热加载”的核心机制，它能在不中断已有连接、不重启服务的前提下，将 permanent 配置生效。关键在于理解 reload 不是简单刷新，而是 runtime 与 permanent 的一次同步操作。
明确 reload 的作用边界
reload 只会把已标记 --permanent 的配置（如添加的服务、端口、源地址、区域目标等）载入当前运行时环境；它不会清除临时规则（runtime-only），也不会影响正在传输的 TCP 连接或 UDP 会话。这意味着：
- 已有 SSH 会话、HTTP 长连接、数据库连接全部保持活跃
- 未加
--permanent的命令（如firewall-cmd --add-port=8080/tcp）在 reload 后会丢失 - reload 本身执行极快（通常
确保规则真正“永久+生效”的两步法
很多用户 reload 后发现规则没变，根本原因是只做了半步操作。必须严格按顺序执行：
- 所有变更命令都带上
--permanent参数，例如：sudo firewall-cmd --permanent --add-service=httpssudo firewall-cmd --permanent --add-source=10.10.20.0/24 --zone=internal - 最后统一执行：
sudo firewall-cmd --reload
跳过任一环节，规则就无法持久化或无法上线。
配合日志实现可追溯的热加载
为验证 reload 是否成功、便于审计与排障，建议将每次 reload 输出写入日志：
- 定义日志路径：
logfile="/var/log/firewall-reload.log" - 执行带记录的重载：
sudo firewall-cmd --reload >> "$logfile" 2>&1 - 日志中会包含时间戳、成功提示（如 "success"）及可能的警告，例如：
2026-05-23 18:42:15 reload: success, 12 rules applied
避免 reload 失效的三个常见陷阱
即使命令写对，也可能因环境问题导致 reload 表面成功实则无效：
-
firewalld 服务未运行：先确认状态
sudo firewall-cmd --state或systemctl is-active firewalld -
配置语法错误但未报错：比如误写
--zone=pubic（拼错 public），reload 仍返回 success，但该规则实际被忽略；建议 reload 后立即用firewall-cmd --list-all核对 -
区域绑定未更新接口：修改了 zone 规则，但网卡仍绑定在旧 zone；需用
firewall-cmd --get-active-zones确认接口归属
