不少用户在部署 ManusAI 时，发现后端服务一旦动态创建 Docker 容器就会卡死，任务状态始终停留在“等待沙盒就绪”。卡住的根本原因究竟是什么？多数情况下，是防火墙直接拦截了 Docker socket 通信。问题排查的关键，在于首先确认究竟是权限不足、服务异常，还是防火墙规则在作祟，然后针对 firewalld 或 iptables 分别给出处理方案。
背后的逻辑是这样的：ManusAI 部署时，后端服务通过 Unix Socket（/var/run/docker.sock）与宿主机的 Docker 守护进程通信。如果系统开启了 iptables 或 firewalld，某些默认策略可能误判这个本地 AF_UNIX 域的通信路径，直接将其拦截。结果就是沙盒创建失败，任务一直卡在原地。
确认防火墙是否实际阻断了 Docker socket 通信
如何确认防火墙到底是不是罪魁祸首？方法很简单。先执行 sudo ss -ltpn | grep docker.sock，看看输出里有没有 u_str 类型的监听项，且 State 为 LISTEN。如果没有任何输出，说明 Docker daemon 根本没有正常绑定 socket——这时候问题根本不在防火墙，而是需要先去检查 Docker 服务状态。
接着运行 sudo journalctl -u docker --since "1 hour ago" | grep -i "permission denied|connect.*refused|denied"，重点搜索包含 permission denied 或 connection refused 的日志行。如果出现 connect to /var/run/docker.sock: permission denied，那么问题的根源是文件权限或 SELinux 上下文，同样与防火墙无关。
放行 Docker socket 通信（仅适用于 firewalld 环境）
如果你使用的是 firewalld，可以按下面几步操作。
方法一：临时关闭 firewalld 验证（不推荐生产环境这样操作）
直接执行 sudo systemctl stop firewalld，然后看看 ManusAI 能否成功创建沙盒容器。如果能恢复，说明 firewalld 确实是阻断源，问题就定位了。
方法二：永久放行本地 socket 通信
firewalld 默认其实不管理 AF_UNIX socket，但如果你启用了 --enable-firewall 参数，或者自定义了 zone 规则，那么就需要显式允许本地 IPC。可以执行 sudo firewall-cmd --permanent --add-rich-rule='rule family="inet" source address="127.0.0.1" port port="2375" protocol="tcp" accept' ——但注意，这一步只对启用了 TCP Docker API 的情况有效。真正关键的是确保 firewalld 没有启用 `docker-plugin`，或者 `public` zone 的 `masquerade` 规则没有被覆盖，因为这两种情况可能误把 socket 连接当成外部请求进行拦截。
方法三：重载 firewalld 并验证
执行 sudo firewall-cmd --reload，然后再次运行 ManusAI 部署脚本，检查沙盒容器能否创建。如果仍然失败，那就需要继续往下排查了。
iptables 场景下解除拦截（适用于 Ubuntu/Debian 系）
对于 Ubuntu 或 Debian 系的系统，先执行 sudo iptables -L -n -v | grep "docker|unix"。如果输出为空，说明 iptables 根本没有设置相关规则，问题不在它身上。
但如果发现了类似 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited 这样的规则，并且 Chain INPUT 的计数还在持续增长，那就需要插入白名单规则了。执行 sudo iptables -I INPUT 1 -i lo -j ACCEPT ——这条规则会把 loopback 接口的所有流量放到最优先级放行，覆盖掉后续可能存在的拒绝规则。注意一定要插在第一条（-I INPUT 1），否则会被已有的 REJECT 规则提前截断，那就白做了。
最后保存规则：Debian/Ubuntu 下使用 sudo iptables-save | sudo tee /etc/iptables/rules.v4，CentOS/RHEL 下使用 sudo service iptables save。