生产环境是否启用 firewalld 取决于网络策略管理主体：若已有硬件防火墙、云安全组或 eBPF/iptables 工具（如 Calico），则 firewalld 冗余且易引发冲突；仅推荐用于无集中管控的中小规模物理机/虚拟机场景。
firewalld 服务是否该在生产环境启用
生产环境是否启用 firewalld，不取决于“该不该用”，而取决于“谁在管网络策略”。如果已有专用硬件防火墙、云平台安全组（如 AWS Security Group、阿里云 ECS 安全组）或主机侧 eBPF/iptables 直接管理工具（如 Calico、Cilium），firewalld 往往是冗余层，反而增加策略冲突风险。它适合中小规模、无集中网络策略管控的物理机或虚拟机场景，尤其是管理员需频繁增删端口且不熟悉 raw iptables 规则时。
- 不建议在 Kubernetes 节点上同时启用
firewalld和 kube-proxy 的 iptables 模式，二者会竞争FORWARD链规则，导致 Pod 网络不通或 Service 访问异常 - 若使用 cloud-init 或 Ansible 自动化部署，确保
firewalld启动顺序早于应用服务，否则服务可能在防火墙就绪前监听成功，造成短暂暴露 - 默认的
publiczone 允许ssh、dhcpv6-client，但禁止所有入向新连接——这点常被误认为“已锁死”，实则只是没显式放行业务端口
zone 切换与 runtime/permanent 模式的坑
firewall-cmd 的 --runtime-to-permanent 不是“保存当前配置”，而是把当前 runtime 规则覆盖写入 permanent 配置。若你只临时加了一条端口、未 reload，又执行该命令，之前通过 firewall-offline-cmd 或手动编辑 /etc/firewalld/zones/*.xml 写死的规则就会丢失。
- 修改 zone 建议始终用
firewall-cmd --permanent --set-default-zone=trusted+firewall-cmd --reload，避免仅 runtime 切换导致重启后回退 - 给网卡绑定 zone 时，不要依赖
firewall-cmd --change-interface=eth0 --zone=internal，该操作仅 runtime 生效；应改用nmcli connection modify "System eth0" firewall.zone internal（配合 NetworkManager）或在/etc/sysconfig/network-scripts/ifcfg-eth0中加FIREWALL_ZONE=internal -
firewall-cmd --list-all-zones输出中，每个 zone 的services:行只显示“预定义服务”（即/usr/lib/firewalld/services/下的 XML 文件），自定义端口必须看ports:字段，否则容易漏检
如何安全地批量开放端口而不留后门
直接 firewall-cmd --permanent --add-port=8080-8090/tcp 是高危操作：范围端口难以审计，且一旦某端口被恶意进程监听，即自动获得通行权。生产环境应坚持“最小端口+明确协议+绑定 zone”。
- 优先用服务名而非端口号：
firewall-cmd --permanent --add-service=http，因为/usr/lib/firewalld/services/http.xml明确定义了80/tcp，语义清晰且防错 - 如需开放非标端口（如 Java 应用的
8761/tcp），先建自定义服务：cat > /etc/firewalld/services/eureka.xml <<'EOF' <service> <short>Eureka Server</short> <port protocol="tcp" port="8761"/> </service> EOF
，再firewall-cmd --reload && firewall-cmd --permanent --add-service=eureka - 永远避免
--add-port=0-65535/udp类操作；UDP 端口尤其危险，因无连接状态跟踪，firewalld 默认仅靠 timeout 控制，易被放大攻击利用
排查 connection refused 却能 ping 通的问题
ping 通只说明 ICMP 和网络层可达，connection refused 多数情况是 TCP 连接被拒绝，原因常不在 firewalld，但在排查路径上它最容易被冤枉。
- 先确认服务真在监听：
ss -tlnp | grep :8080，若无输出，问题在应用未启动或绑定错了地址（如只绑127.0.0.1） - 再查 firewalld 是否放行：
firewall-cmd --list-ports和firewall-cmd --list-services，注意输出中的 zone 是否匹配网卡实际所属 zone（firewall-cmd --get-active-zones） - 最后验证规则是否生效：用
firewall-cmd --direct --get-all-rules查看是否有 direct rules 干扰，或用iptables -t filter -L INPUT -n -v看底层链是否含REJECT或DROP—— firewalld 的default_zone若设为drop，未匹配任何 rule 的包会被静默丢弃，此时telnet会超时而非refused
真正麻烦的是 multi-zone 场景下 interface 绑定漂移，比如 DHCP 重获 IP 后 NetworkManager 重载配置，导致网卡 zone 回到 default。这种问题不会报错，只会让某批请求突然失联，得盯住 journalctl -u firewalld -f 里 zone change 日志。
