在OpenEuler 24.03这个以安全和稳定性著称的新一代操作系统上部署Docker服务时，不少开发者遭遇了一个顽固的“幽灵”：通过`firewall-cmd --permanent --direct`添加的自定义iptables规则，在系统重启或firewalld重载后神秘消失，只留下冰冷的“line X failed”错误。常规的排查——检查语法、验证模块、审视规则顺序——往往无功而返。今天，我们将揭开这个问题的真正面纱，并分享一个经过实战验证、一劳永逸的解决方案。

问题根源：被污染的链状态 问题的核心并非firewalld的direct接口本身，而在于Docker与firewalld在底层iptables链管理上的微妙博弈。Docker启动时会自动创建并管理`DOCKER-USER`链，用于放置用户自定义规则。然而，在OpenEuler 24.03特定内核与firewalld版本的组合下，可能会产生一个隐蔽的“状态污染”：即该链在iptables的规则表（如filter表）中物理存在，但其内部状态或与firewalld direct规则集的关联已出现异常。此时，任何试图通过firewalld向该链注入新规则的操作，都会在底层`iptables-restore`时触发兼容性校验失败，导致整个规则集重载回滚，你的自定义规则自然无法持久化。

解决之道：彻底清淤与重建 面对这种底层状态不一致，修修补补无济于事。我们需要的是外科手术式的彻底清理。以下是完整的解决步骤，请务必按顺序操作：

1. 停止所有容器服务：首先，安全地停止所有正在运行的Docker容器。`docker stop $(docker ps -q)`

2. 停止Docker守护进程：让Docker完全退出，释放其对iptables的控制。`systemctl stop docker`

3. 清除问题链：使用`iptables`命令直接查看并删除有问题的`DOCKER-USER`链（假设在filter表）。
`iptables -t filter -X DOCKER-USER` （-X 用于删除用户自定义链）

4. 通过firewalld重建链：让firewalld以干净的状态重新创建它。这步是关键，确保了firewalld对新链的所有权。
`firewall-cmd --permanent --direct --add-chain ipv4 filter DOCKER-USER`

5. 添加你的业务规则：现在可以安全地添加原本失败的direct规则了。例如：
`firewall-cmd --permanent --direct --add-rule ipv4 filter DOCKER-USER 0 -s 192.168.1.0/24 -j ACCEPT`

6. 重载firewalld配置：让更改生效。
`firewall-cmd --reload` 此时应该不再报错。

7. 重启Docker服务：最后启动Docker，它会识别并接入这个由firewalld管理的干净链。
`systemctl start docker`

原理与后续 这个方案的精髓在于“先破后立”。手动删除链清除了内核中的异常状态，然后通过firewalld的direct接口重建链，确保了链的生命周期被firewalld正确管理。此后添加的规则便能被顺利编译并持久化。完成上述步骤后，你可以重启系统进行最终验证，规则将会牢固存在。

希望这篇凝结了实战汗水的记录，能帮助更多在OpenEuler与Docker交织的网络迷宫中跋涉的同行者。技术之路，正是由这些具体的挑战与巧妙的破解铺就。如果你有更多发现，欢迎在社区分享交流。