诊断 firewall-cmd 区域冲突需先执行 firewall-cmd --get-active-zones 查看实际生效的 zone 及绑定网卡，再结合 --get-default-zone、ip -br a 确认默认 zone 和真实接口；接着比对各 zone 的 --list-all 配置，重点关注 sources、ports、services 是否冗余或矛盾；通过开启日志 firewall-cmd --set-log-denied=all 并分析 journalctl 日志定位流量所属 zone；最后用 --change-interface 或 --add-source 修正绑定并 firewall-cmd --reload 固化配置。
诊断 firewall-cmd 区域冲突，核心是确认“哪个区域在管哪块流量”——因为同一张网卡不能同时属于多个活跃 zone，而不同 zone 的默认策略（如 public 拒绝入站、trusted 全放行）一旦错配，就会导致看似矛盾的访问行为：比如某 IP 能通 SSH 却打不开 Web 服务，或内网机器连不通却能访问外网。
查清当前哪些区域被激活并绑定了接口
运行以下命令，看实际生效的区域和对应网卡：
- firewall-cmd --get-active-zones：列出所有正在使用的 zone 及其绑定的网络接口（如 eth0、ens33）
- firewall-cmd --get-default-zone：查看系统默认 zone（新接口默认归入此处）
- ip -br a 或 nmcli device show：确认物理/虚拟网卡名，避免把 bond0、docker0 等误认为主网卡
常见冲突场景：eth0 被错误分配到 drop 区域（默认丢弃所有入站），而你本意是让它走 public；或 docker0 接口意外加入 public，导致容器端口被防火墙拦截。
比对各区域规则是否互相覆盖或矛盾
同一个端口或服务，在不同 zone 中可能有不同策略。例如：
- public zone 开了 8080/tcp，但 internal zone 也开了 8080/tcp，而 eth0 实际属于 internal —— 此时 public 的配置完全不生效
- trusted zone 允许所有流量，但只绑定了 lo（回环），而业务网卡却在 public 下，结果还是被限制
逐个检查关键 zone 的完整配置：
- firewall-cmd --zone=public --list-all
- firewall-cmd --zone=internal --list-all
- firewall-cmd --zone=trusted --list-all
重点关注 sources（源地址段）、ports、services 和 masquerade 是否存在冗余、遗漏或反向限制（如某 zone 显式 reject 了本该放行的 IP 段）。
验证流量实际落入哪个 zone
firewalld 根据“接口归属 + 源地址匹配”决定 zone，不是单纯看 IP。可借助富规则日志定位：
- 临时开启拒绝日志：firewall-cmd --set-log-denied=all && firewall-cmd --reload
- 复现问题请求（如 telnet 192.168.1.100 8080）
- 查日志：journalctl -u firewalld | grep "REJECT" | tail -20，观察日志中显示的 zone 名称和 source IP
如果日志里频繁出现 zone="public" 但你期望是 internal，说明接口绑定或源地址匹配逻辑出错了。
修正与固化配置
发现冲突后，按需调整：
- 把接口移到正确 zone：firewall-cmd --permanent --zone=internal --change-interface=eth0
- 为特定源 IP 指定 zone（更精准）：firewall-cmd --permanent --zone=trusted --add-source=192.168.5.0/24
- 删除错误绑定：firewall-cmd --permanent --zone=public --remove-interface=eth0
- 所有修改后必须执行：firewall-cmd --reload（不中断连接）
改完再跑一次 --get-active-zones 和对应 --list-all，确保输出符合预期。不复杂但容易忽略。
