Docker部署避坑：OpenClaw容器内无法使用代理？网络模式选择建议

大家好，我是讯享网，很高兴认识大家。这里提供最前沿的Ai技术和互联网信息。

“在本地跑得好好的OpenClaw，一放到Docker容器里，代理就不生效了……”

“明明docker-compose.yml里配了环境变量，容器里curl也能通，但OpenClaw就是不走代理……”

“更离谱的是，容器能ping通外网，但OpenClaw一跑采集任务就报网络错误……”

如果你正在经历这些，别怀疑人生——这不是你的问题，是Docker网络和OpenClaw代理解析逻辑的“双重夹击”。我在这上面折腾了好几天，踩了不下5个坑，今天一次性帮你排完。

先看看你是不是遇到了以下情况：

现象可能原因宿主机curl能通代理，容器内curl也能通，但OpenClaw报错 OpenClaw代理解析与Docker网络叠加问题容器能ping通外网，但OpenClaw采集失败代理环境变量未正确传递到OpenClaw进程 Docker Desktop刚升级后代理突然失效新版Docker的容器网络隔离策略变更配置了HTTP_PROXY但OpenClaw仍走直连 YAML配置与容器环境变量冲突

我一个一个说，并给出对应的解决方案。

2.1 错误做法

很多人在docker run命令里只写了这样：

 docker run -d --name openclaw openclaw/openclaw:latest

然后在容器里手动export HTTP_PROXY——容器重启就没了。

2.2 正确做法

方案A：docker run时直接传环境变量

 docker run -d    -e HTTP_PROXY="http://隧道ID:密码@tps.zdaye.com:8080"    -e HTTPS_PROXY="http://隧道ID:密码@tps.zdaye.com:8080"    -e NO_PROXY="localhost,127.0.0.1"    --name openclaw    openclaw/openclaw:latest

方案B：docker-compose.yml配置（推荐）

 services:   openclaw:     image: openclaw/openclaw:latest     container_name: openclaw     ports:       - "18789:18789"     environment:       - HTTP_PROXY=http://隧道ID:密码@tps.zdaye.com:8080       - HTTPS_PROXY=http://隧道ID:密码@tps.zdaye.com:8080       - NO_PROXY=localhost,127.0.0.1     volumes:       - openclaw_data:/root/.openclaw     restart: unless-stopped volumes:   openclaw_data:

验证环境变量是否生效：

 docker exec openclaw env | grep -i proxy

应该能看到你配置的代理地址。

3.1 问题根源

这是一个很容易被忽略的坑。回顾我们之前讲过的HTTP/HTTPS协议混淆问题——OpenClaw在处理YAML中的代理配置时，可能存在解析缺陷。

而当你在容器里同时做了两件事：

在config.yaml里配置了proxy字段
通过-e传入了HTTP_PROXY环境变量

OpenClaw的代理加载逻辑可能产生冲突，导致两个都不生效。

3.2 解决方案

二选一，别混用：

推荐方案：只用环境变量，注释掉YAML中的proxy配置

 # config.yaml - 代理配置注释掉，让环境变量接管 # proxy: #   http: "http://..." #   https: "http://..."

备选方案：只用YAML配置，不用环境变量

但这意味着你需要把YAML文件挂载进容器，并且要确保OpenClaw能正确解析（可能会遇到协议混淆问题）。

我的建议：在Docker环境中，优先使用环境变量方案。这是最底层、最可靠的代理配置方式，能绕开OpenClaw自己实现的代理解析逻辑。

4.1 问题现象

Docker Desktop 4.29.0及以上版本引入了“隔離容器”（Air-Gapped Containers）功能，可以对容器网络流量施加自定义代理规则。这个功能本意是好的——帮助管理员限制容器网络访问，保护敏感环境。

但如果配置不当，可能会意外拦截容器的代理流量。

4.2 检查方法

如果你用的是Docker Desktop，检查一下admin-settings.json中是否有containersProxy配置：

 {   "containersProxy": {     "mode": "manual",     "http": "http://proxy.company.com:8080",     "https": "http://proxy.company.com:8080",     "transparentPorts": "*"   } }

如果这里有配置，Docker会强制容器的网络流量走这个代理，覆盖你在容器内设置的环境变量。

4.3 解决方案

方案A：如果你不需要这个功能，删除或注释掉containersProxy配置

方案B：如果需要保留，确保这里的代理地址配置正确，且与OpenClaw的代理设置不冲突

PAC文件配置示例：

 function FindProxyForURL(url, host)    // 其他流量走公司代理   return "PROXY corporate-proxy:8080"; }

5.1 常见错误：用`--network host`导致代理配置失效

有些用户为了让容器和宿主机共享网络，会这样写：

 docker run --network host ...

这会导致：

容器使用宿主机的网络栈
HTTP_PROXY环境变量可能被宿主机网络配置覆盖
代理行为变得不可预测

5.2 正确做法：使用默认bridge网络 + 环境变量

 services:   openclaw:     image: openclaw/openclaw:latest     # 不要用 network_mode: host     # 让Docker使用默认bridge网络     environment:       - HTTP_PROXY=http://隧道ID:密码@tps.zdaye.com:8080       - HTTPS_PROXY=http://隧道ID:密码@tps.zdaye.com:8080

5.3 特殊场景：容器需要访问宿主机的代理服务

如果你在宿主机上运行了一个代理服务（比如Clash、v2ray），想让容器通过它上网：

方案A：使用host.docker.internal（Docker Desktop专用）

 environment:   - HTTP_PROXY=http://host.docker.internal:7890   - HTTPS_PROXY=http://host.docker.internal:7890

方案B：使用宿主机IP（Linux Docker）

 # 先获取宿主机IP ip addr show docker0 | grep inet # 输出示例：inet 172.17.0.1/16

 environment:   - HTTP_PROXY=http://172.17.0.1:7890   - HTTPS_PROXY=http://172.17.0.1:7890

6.1 问题现象

代理配置看起来没问题，环境变量也传进去了，但OpenClaw报错：

 Error: getaddrinfo ENOTFOUND tps.zdaye.com

6.2 原因分析

容器内的DNS配置可能无法正确解析站大爷的代理域名。这在某些云服务器或自定义Docker网络中很常见。

6.3 解决方案

方案A：使用IP地址代替域名

联系站大爷客服获取代理入口的IP地址，然后：

 environment:   - HTTP_PROXY=http://隧道ID:密码@123.123.123.123:8080

方案B：自定义容器DNS

 services:   openclaw:     image: openclaw/openclaw:latest     dns:       - 114.114.114.114       - 8.8.8.8     environment:       - HTTP_PROXY=http://隧道ID:密码@tps.zdaye.com:8080

方案C：在容器内测试DNS解析

 docker exec openclaw nslookup tps.zdaye.com

如果不通，说明DNS确实有问题，用方案A或B。

下面是一份经过实测、可直接使用的docker-compose.yml：

 version: '3.8' services:   openclaw:     image: openclaw/openclaw:latest     container_name: openclaw     restart: unless-stopped          ports:       - "18789:18789"          environment:       # 站大爷隧道代理配置       - HTTP_PROXY=http://你的隧道ID:你的隧道密码@tps.zdaye.com:8080       - HTTPS_PROXY=http://你的隧道ID:你的隧道密码@tps.zdaye.com:8080       - NO_PROXY=localhost,127.0.0.1       # 时区设置       - TZ=Asia/Shanghai          # DNS配置（如果解析有问题，取消注释）     # dns:     #   - 114.114.114.114     #   - 8.8.8.8          volumes:       - openclaw_data:/root/.openclaw       - openclaw_cache:/root/.cache          # 健康检查（可选）     healthcheck:       test: ["CMD", "curl", "-f", "http://localhost:18789"]       interval: 30s       timeout: 10s       retries: 3 volumes:   openclaw_data:   openclaw_cache:

启动命令：

 docker-compose up -d

验证代理是否生效：

 # 进入容器 docker exec -it openclaw bash # 测试代理连通性 curl -I https://httpbin.org/ip # 或者用OpenClaw指令 openclaw gateway status

网络模式适用场景代理兼容性推荐度 bridge（默认） 大多数场景，容器需要独立网络 ⭐⭐⭐⭐⭐ ** 最推荐 host 容器需要极致网络性能，不关心隔离 ⭐⭐ 可能冲突不推荐用于代理场景 none 完全离线容器 ❌ 不支持代理不适用自定义网络多容器互联 ⭐⭐⭐⭐ 良好高级用户

一句话总结：

普通用户：用默认bridge网络 + 环境变量配置代理 = 最稳
不要用 --network host，会让代理行为变得不可预测
不要混用 YAML配置和环境变量，二选一

如果配置完还是不行，按顺序检查：

[ ] 环境变量是否传入了容器？→ docker exec openclaw env | grep -i proxy
[ ] 代理地址格式是否正确？→ 不要漏掉http://前缀和认证信息
[ ] 容器内能否curl通代理？→ docker exec openclaw curl -x http://... https://httpbin.org/ip
[ ] DNS能否解析代理域名？→ docker exec openclaw nslookup tps.zdaye.com
[ ] Docker Desktop是否有containersProxy配置拦截？→ 检查admin-settings.json
[ ] 是否混用了YAML配置和环境变量？→ 注释掉YAML中的proxy
[ ] 网络模式是不是host？→ 改回bridge

Docker部署OpenClaw+站大爷隧道代理，核心就三句话：

环境变量传代理，别用YAML配置
网络模式用bridge，别用host
二选一别混用，环境变量最稳

把这三点记住，基本就不会踩坑了。如果还不行，按上面的排障清单一步步查，总能找到问题。