--passthrough无法可靠解决调优死锁，因其仅支持向filter表特定链注入规则，不触达raw/mangle/nat表，无法干预conntrack状态或netfilter钩子顺序，且firewalld会自动清理、重排这些规则，导致行为不可预测；应优先使用ipset、rich rules或direct接口，必要时切换至iptables-legacy/nftables直管模式。
Firewalld 的 --passthrough 接口不是为绕过 firewalld 管理、直接下发任意 iptables 规则而设计的。它仅支持在特定链（主要是 filter 表的 INPUT、OUTPUT、FORWARD）中插入**兼容 firewalld 运行时模型**的原生规则，且必须严格遵循其生命周期管理逻辑。试图用它解决“高级调优死锁”（如连接跟踪冲突、规则顺序竞争、状态机错位）往往适得其反——firewalld 会在重载、重启或 zone 切换时自动清理、重排或覆盖这些 passthrough 规则，导致行为不可预测甚至服务中断。
为什么 --passthrough 无法可靠解决调优死锁
死锁类问题通常源于 netfilter 内核子系统层面的状态同步或钩子点竞争（例如 conntrack 超时与 raw 表标记冲突、mangle 表 TTL 修改影响后续 filter 匹配），而 --passthrough 只能向 filter 表注入规则，既不能触达 raw/mangle/nat 表，也无法干预 conntrack 模块参数或 netfilter 钩子执行顺序。firewalld 对 passthrough 规则不做语法校验、不检查链依赖、不维护其上下文一致性，一旦规则触发内核状态异常，firewalld 本身无法感知或恢复。
在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...
真正有效的替代路径
-
优先使用 firewalld 原生高级功能：启用
ipset支持实现超大白名单/黑名单毫秒级匹配；配置rich rules精确控制连接状态（connection-limit、source-port、icmp-block）；通过direct interface（firewall-cmd --direct）安全操作 raw/mangle 表，它比 passthrough 更可控且被 firewalld 显式管理 -
对核心调优需求，切换至 iptables-legacy 或 nftables 直管模式：若必须深度干预（如自定义 conntrack helper、raw 表 NOTRACK、mangle 标记路由），应停用 firewalld（
systemctl stop firewalld && systemctl disable firewalld），改用iptables-legacy或现代nftables手动配置，并通过 systemd service 保障规则持久化。这是唯一能完全掌控钩子点、表优先级和状态机的行为方式 -
诊断而非掩盖死锁根源：用
conntrack -L查看连接状态表溢出；用iptables -t raw -L -v -n确认 NOTRACK 是否生效；用cat /proc/sys/net/netfilter/*核查内核参数（如nf_conntrack_max、nf_conntrack_tcp_be_liberal）。多数“死锁”实为参数失配或规则逻辑矛盾，修复配置比强行注入规则更根本
如果仍需最小化使用 --passthrough
仅限临时调试，且必须满足：
– 规则目标链必须是 INPUT、OUTPUT 或 FORWARD（firewall-cmd --passthrough ipv4 -I INPUT -p tcp --dport 8080 -j ACCEPT）
– 不得包含 -t nat、-t mangle、-t raw 等跨表指令
– 不得使用 --ctstate 等依赖 conntrack 状态的 match（firewalld 不保证其上下文）
– 每次 firewalld reload 后必须重新下发，不可依赖其持久化
不复杂但容易忽略：firewalld 的设计哲学是抽象与安全优先，不是 iptables 的快捷方式。调优死锁的本质是网络栈深层交互问题，工具选择应匹配问题层级。
