502 是 cloudflared 容器里的 127.0.0.1 不是宿主机OpenClaw 的模型通道统一走 TaoToken 再查在 OpenClaw 的部署里有一个非常容易被误判的 502你把gateway.bind从lan改成loopback之后TUI 终于正常了但通过 Cloudflare Tunnel 从公网访问却直接返回 502 Bad Gateway。宿主机上curl 127.0.0.1:18789明明通为什么公网就是不行根因不在 OpenClaw而在 cloudflared 容器里的127.0.0.1根本不是宿主机的127.0.0.1。这篇文章按排障视角把网络命名空间、Docker bridge、host 模式这条链路拆开讲清楚同时把 OpenClaw 的模型通道统一收敛到 TaoToken官网https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content让你在 loopback 下先跑通一次模型请求再回头判断公网 502 到底卡在哪一层。一、原问题与场景TUI 在 LAN 异常改 loopback 后公网 502先还原现场。OpenClaw 的 gateway 配置大致是这样gateway: { port: 18789, mode: local, bind: lan }bind lan等价于监听0.0.0.0:18789所有网卡开放局域网内任何 IP 都能连。理论上更开放但实际表现是 OpenClaw TUI 行为异常连接状态不稳定、子 agent 内部通道建立失败、WebSocket 路径错乱。原因是 TUI 本质是本地控制界面设计目标是本机 CLI / 本机浏览器访问本地 agent、调度本地子进程。当监听0.0.0.0时有些组件走localhost解析有些走 LAN IP 回环连接路径不一致内部回调可能走外部网卡于是控制面就乱了。改成bind loopback监听127.0.0.1:18789所有内部组件统一走 localhost不涉及网卡选择不触发 LAN 路由网络路径极度简单进程 → 127.0.0.1 → OpenClaw。TUI 立刻恢复正常。这说明 OpenClaw 的本地控制面本来就适合 loopback而不是 LAN 暴露。但新的问题来了。公网架构是 Cloudflare TunnelDocker 容器→127.0.0.1:18789访问域名直接 502 Bad Gateway / connection refused而宿主机上curl 127.0.0.1:18789完全正常。矛盾点就在这里容器访问的127.0.0.1不是宿主机。二、TaoToken 前置先把模型通道从网络问题里剥离出来排障最怕两件事混在一起网络链路不通和模型请求发不出去。OpenClaw 在 loopback 下 TUI 正常但如果你连一次模型请求都没跑通就无法判断 502 是 Tunnel 的问题还是上游模型通道的问题。所以第一步先把模型通道统一走 TaoToken。TaoToken 在这里的角色很明确它只负责让 OpenClaw 的模型请求能正常发出去不负责解决 cloudflared 的网络命名空间问题。502 是否消失仍然要按 namespace 与 Docker host 模式来判断。把这两层分开排障才不会互相干扰。操作上先在 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 创建 Key拿到YOUR_API_KEY。然后进入 OpenClaw 的模型配置把 Base URL 填成https://taotoken.net/api注意不要带/v1。这一步做完OpenClaw 在 loopback 下就能先跑通一次模型请求确认控制面和模型通道都是通的再回来看公网链路。三、可复制配置OpenClaw 模型通道 cloudflared host 模式先给 OpenClaw 的模型通道配置。不同版本字段名可能略有差异核心是 base_url 和 api_key 两项{ model: { provider: openai-compatible, base_url: https://taotoken.net/api, api_key: YOUR_API_KEY, model_id: 你的模型ID } }如果你用的是 CLI 方式接入也可以直接npm i -g taotoken/taotoken taotoken cc -k YOUR_API_KEY -u https://taotoken.net/api -m MODEL_ID再给 cloudflared 的 Docker Compose。关键不是回退到 LAN而是让 cloudflared 使用 host 网络模式version: 3.8 services: cloudflared: image: cloudflare/cloudflared:latest container_name: cloudflared restart: unless-stopped network_mode: host command: tunnel --no-autoupdate run --token TOKENhost 模式下容器直接使用宿主机网络栈此时容器127.0.0.1 宿主机127.0.0.1访问路径变成Cloudflare → Tunnel → 宿主机 127.0.0.1 → OpenClaw。公网访问恢复同时 OpenClaw 仍然只监听 loopback不暴露 LANTUI 正常安全性最佳。四、验证请求与成功结果配置改完后按顺序验证不要跳步。第一步宿主机本地验证 OpenClaw 控制面curl -i http://127.0.0.1:18789预期返回 200 或正常的握手响应而不是 connection refused。第二步验证模型通道。在 OpenClaw TUI 里发起一次最简单的模型对话请求确认能正常返回内容。这一步通了说明 TaoToken 的 Base URL 和 Key 配置正确模型请求能发出去。第三步验证 cloudflared 容器网络。进入容器内部docker exec -it cloudflared sh curl -i http://127.0.0.1:18789在 host 模式下这个请求应该和宿主机上一样通。如果这里仍然 refused说明容器没有真正用上 host 网络检查network_mode: host是否生效、是否被其他网络配置覆盖。第四步公网访问域名。预期不再 502而是正常进入 OpenClaw 的界面或返回预期响应。成功的结果是TUI 在 loopback 下稳定模型请求经 TaoToken 正常返回公网经 Tunnel 访问不再 502且 LAN 端口没有暴露。五、本篇常见错排查错误一把 502 当成 OpenClaw 的问题。502 来自 Cloudflare是 Tunnel 到源站这一段失败。宿主机 curl 通、容器 curl 不通问题一定在容器网络命名空间不在 OpenClaw 本身。错误二改回bind lan来“修复”公网。LAN 模式下 bridge 容器确实能通过http://192.168.x.x:18789访问宿主机公网看起来可用但 TUI 内部逻辑可能异常而且服务暴露在整个局域网安全风险明显增加。这是用错误换可用不推荐。错误三Base URL 带了/v1。OpenClaw 模型配置里填https://taotoken.net/api不要写成https://taotoken.net/api/v1。路径多一层会导致请求 404 或鉴权异常容易被误判成网络问题。错误四Key 没生效就怀疑 Tunnel。如果模型请求本身就没跑通公网 502 和模型报错会混在一起。先在 loopback 下用 TUI 跑通一次模型请求确认 TaoToken 通道正常再排查 Tunnel。错误五host 模式没生效。检查 compose 里是否同时存在network_mode: host和networks字段两者冲突时 host 可能不生效。host 模式下容器不再有独立 IP端口映射ports字段也应去掉。错误六以为 127.0.0.1 是全局的。这是根因认知。127.0.0.1永远属于当前网络命名空间。Docker bridge 会创建独立 namespacehost 模式不会。理解这一句整个问题就通了。六、语义一致 CTA回到这条排障链路OpenClaw 控制面用 loopback 保证 TUI 稳定cloudflared 用 host 模式保证容器能访问宿主机 loopback模型通道统一走 TaoToken 保证请求能发出去。三层各司其职502 才不会反复出现。如果你正在配 OpenClaw 的模型通道先去 https://taotoken.net/api-keys 创建 Key再对照 https://taotoken.net/doc 的接入文档确认 Base URL 和字段名。需要长期跑编码和 Agent 任务可以看 Coding Planhttps://taotoken.net/coding-plan 。想先验证模型是否正常返回直接进模型对话https://taotoken.net/chat 。配置过程中遇到鉴权或路径问题接入文档里有完整的字段说明和示例。
502 是 cloudflared 容器里的 127.0.0.1 不是宿主机？OpenClaw 的模型通道统一走 TaoToken 再查
502 是 cloudflared 容器里的 127.0.0.1 不是宿主机OpenClaw 的模型通道统一走 TaoToken 再查在 OpenClaw 的部署里有一个非常容易被误判的 502你把gateway.bind从lan改成loopback之后TUI 终于正常了但通过 Cloudflare Tunnel 从公网访问却直接返回 502 Bad Gateway。宿主机上curl 127.0.0.1:18789明明通为什么公网就是不行根因不在 OpenClaw而在 cloudflared 容器里的127.0.0.1根本不是宿主机的127.0.0.1。这篇文章按排障视角把网络命名空间、Docker bridge、host 模式这条链路拆开讲清楚同时把 OpenClaw 的模型通道统一收敛到 TaoToken官网https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content让你在 loopback 下先跑通一次模型请求再回头判断公网 502 到底卡在哪一层。一、原问题与场景TUI 在 LAN 异常改 loopback 后公网 502先还原现场。OpenClaw 的 gateway 配置大致是这样gateway: { port: 18789, mode: local, bind: lan }bind lan等价于监听0.0.0.0:18789所有网卡开放局域网内任何 IP 都能连。理论上更开放但实际表现是 OpenClaw TUI 行为异常连接状态不稳定、子 agent 内部通道建立失败、WebSocket 路径错乱。原因是 TUI 本质是本地控制界面设计目标是本机 CLI / 本机浏览器访问本地 agent、调度本地子进程。当监听0.0.0.0时有些组件走localhost解析有些走 LAN IP 回环连接路径不一致内部回调可能走外部网卡于是控制面就乱了。改成bind loopback监听127.0.0.1:18789所有内部组件统一走 localhost不涉及网卡选择不触发 LAN 路由网络路径极度简单进程 → 127.0.0.1 → OpenClaw。TUI 立刻恢复正常。这说明 OpenClaw 的本地控制面本来就适合 loopback而不是 LAN 暴露。但新的问题来了。公网架构是 Cloudflare TunnelDocker 容器→127.0.0.1:18789访问域名直接 502 Bad Gateway / connection refused而宿主机上curl 127.0.0.1:18789完全正常。矛盾点就在这里容器访问的127.0.0.1不是宿主机。二、TaoToken 前置先把模型通道从网络问题里剥离出来排障最怕两件事混在一起网络链路不通和模型请求发不出去。OpenClaw 在 loopback 下 TUI 正常但如果你连一次模型请求都没跑通就无法判断 502 是 Tunnel 的问题还是上游模型通道的问题。所以第一步先把模型通道统一走 TaoToken。TaoToken 在这里的角色很明确它只负责让 OpenClaw 的模型请求能正常发出去不负责解决 cloudflared 的网络命名空间问题。502 是否消失仍然要按 namespace 与 Docker host 模式来判断。把这两层分开排障才不会互相干扰。操作上先在 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 创建 Key拿到YOUR_API_KEY。然后进入 OpenClaw 的模型配置把 Base URL 填成https://taotoken.net/api注意不要带/v1。这一步做完OpenClaw 在 loopback 下就能先跑通一次模型请求确认控制面和模型通道都是通的再回来看公网链路。三、可复制配置OpenClaw 模型通道 cloudflared host 模式先给 OpenClaw 的模型通道配置。不同版本字段名可能略有差异核心是 base_url 和 api_key 两项{ model: { provider: openai-compatible, base_url: https://taotoken.net/api, api_key: YOUR_API_KEY, model_id: 你的模型ID } }如果你用的是 CLI 方式接入也可以直接npm i -g taotoken/taotoken taotoken cc -k YOUR_API_KEY -u https://taotoken.net/api -m MODEL_ID再给 cloudflared 的 Docker Compose。关键不是回退到 LAN而是让 cloudflared 使用 host 网络模式version: 3.8 services: cloudflared: image: cloudflare/cloudflared:latest container_name: cloudflared restart: unless-stopped network_mode: host command: tunnel --no-autoupdate run --token TOKENhost 模式下容器直接使用宿主机网络栈此时容器127.0.0.1 宿主机127.0.0.1访问路径变成Cloudflare → Tunnel → 宿主机 127.0.0.1 → OpenClaw。公网访问恢复同时 OpenClaw 仍然只监听 loopback不暴露 LANTUI 正常安全性最佳。四、验证请求与成功结果配置改完后按顺序验证不要跳步。第一步宿主机本地验证 OpenClaw 控制面curl -i http://127.0.0.1:18789预期返回 200 或正常的握手响应而不是 connection refused。第二步验证模型通道。在 OpenClaw TUI 里发起一次最简单的模型对话请求确认能正常返回内容。这一步通了说明 TaoToken 的 Base URL 和 Key 配置正确模型请求能发出去。第三步验证 cloudflared 容器网络。进入容器内部docker exec -it cloudflared sh curl -i http://127.0.0.1:18789在 host 模式下这个请求应该和宿主机上一样通。如果这里仍然 refused说明容器没有真正用上 host 网络检查network_mode: host是否生效、是否被其他网络配置覆盖。第四步公网访问域名。预期不再 502而是正常进入 OpenClaw 的界面或返回预期响应。成功的结果是TUI 在 loopback 下稳定模型请求经 TaoToken 正常返回公网经 Tunnel 访问不再 502且 LAN 端口没有暴露。五、本篇常见错排查错误一把 502 当成 OpenClaw 的问题。502 来自 Cloudflare是 Tunnel 到源站这一段失败。宿主机 curl 通、容器 curl 不通问题一定在容器网络命名空间不在 OpenClaw 本身。错误二改回bind lan来“修复”公网。LAN 模式下 bridge 容器确实能通过http://192.168.x.x:18789访问宿主机公网看起来可用但 TUI 内部逻辑可能异常而且服务暴露在整个局域网安全风险明显增加。这是用错误换可用不推荐。错误三Base URL 带了/v1。OpenClaw 模型配置里填https://taotoken.net/api不要写成https://taotoken.net/api/v1。路径多一层会导致请求 404 或鉴权异常容易被误判成网络问题。错误四Key 没生效就怀疑 Tunnel。如果模型请求本身就没跑通公网 502 和模型报错会混在一起。先在 loopback 下用 TUI 跑通一次模型请求确认 TaoToken 通道正常再排查 Tunnel。错误五host 模式没生效。检查 compose 里是否同时存在network_mode: host和networks字段两者冲突时 host 可能不生效。host 模式下容器不再有独立 IP端口映射ports字段也应去掉。错误六以为 127.0.0.1 是全局的。这是根因认知。127.0.0.1永远属于当前网络命名空间。Docker bridge 会创建独立 namespacehost 模式不会。理解这一句整个问题就通了。六、语义一致 CTA回到这条排障链路OpenClaw 控制面用 loopback 保证 TUI 稳定cloudflared 用 host 模式保证容器能访问宿主机 loopback模型通道统一走 TaoToken 保证请求能发出去。三层各司其职502 才不会反复出现。如果你正在配 OpenClaw 的模型通道先去 https://taotoken.net/api-keys 创建 Key再对照 https://taotoken.net/doc 的接入文档确认 Base URL 和字段名。需要长期跑编码和 Agent 任务可以看 Coding Planhttps://taotoken.net/coding-plan 。想先验证模型是否正常返回直接进模型对话https://taotoken.net/chat 。配置过程中遇到鉴权或路径问题接入文档里有完整的字段说明和示例。
