浏览器能开 GitHub，为什么 docker compose up OpenHands 还是拉不动镜像？

浏览器走系统 PAC 或 HTTPS 代理，而 dockerd 与容器内进程默认不继承 shell 的 HTTPS_PROXY，常在直连或企业透明代理下半截失败。仅用 Mixed Port 而不开 TUN 时，宿主机终端与 Docker 引擎出站可能分叉。先在宿主机开 TUN 并对拍 auth.docker.io、registry-1.docker.io 等连接，再决定是否给 compose 显式写 proxy 环境变量。

OpenHands 容器已起来，但对话报模型 API 超时，要补哪些域名？

以 Connections 中出现的 Host/SNI 为准，常见包括 api.anthropic.com、api.openai.com、generativelanguage.googleapis.com 及你配置的 OpenRouter、Azure OpenAI 网关等；沙箱内请求可能经不同网卡发出。把高频集合封装进 Rule Provider，并确保在过宽 GEOIP 直连之前命中。

TUN、Docker 镜像加速和 npm 国内源应该先动哪一个？

先确认链路是否已进入内核与被哪条规则命中，再决定是否换镜像站或 registry 镜像：否则会把 TLS 不匹配、MITM 根证书缺失等失败误报成「网速慢」。个人环境可先试 TUN+官方源；企业环境必须以 IT 批准的出口与 Nexus 策略为先。

OpenHands 超时？Clash TUN（2026）

先分层：你卡在「Docker 镜像」「npm 依赖」「GitHub」还是「模型 API」

OpenHands 的出站至少分四层，终端里都叫「超时」，根因却不同。第一层是 docker compose up 或 docker pull 访问 Docker Hub、ghcr.io 与镜像层 CDN，典型报错含 context deadline exceeded、net/http: TLS handshake timeout、长时间卡在 Pulling。第二层是在宿主机或容器构建阶段执行 npm install、pip install，打 registry.npmjs.org 与 tarball 静态域。第三层是 Agent 克隆私有仓库、读 Issue、推 PR 时访问 GitHub API、GraphQL、objects.githubusercontent.com 与 SSO 跳转域。第四层才是对话与工具调用时的 模型 API——api.anthropic.com、api.openai.com、generativelanguage.googleapis.com，或你自配的 OpenRouter、Azure OpenAI 网关。

若一开始就把问题笼统归到「OpenHands 坏了」，很容易只给 github.com 写一条 DOMAIN，却漏掉 auth.docker.io 或容器沙箱里实际命中的 API 主机。正确起手式仍然是在失败时间窗内打开 Clash 的 Connections／日志，抄下完整主机名、规则序号、最终策略组与失败原因。若日志里看不到 dockerd 或容器相关连接，说明流量没进 Meta 内核，或被其它 VPN、ZTNA 截获。Clash TUN 的价值，是把宿主机与多数用户态进程的默认出站抬到系统路由层，让你维护的分流规则与真实五元组对齐。

为什么「浏览器能开 GitHub」治不好 Docker 里的 OpenHands

桌面浏览器通常跟随系统 PAC 或 HTTPS 代理；而 dockerd 拉镜像、containerd 与容器内 npm／Python 进程，经常处于三种尴尬状态之一：守护进程没有继承 shell 的 HTTPS_PROXY；有变量但仅写在 compose 里、沙箱子进程仍未读到；或走了公司明文代理却未信任企业 MITM 根证书，TLS 在客户端提前失败却被口语化成「超时」。HTTP/3／QUIC 还可能尝试 UDP 路径，绕开只懂 TCP 的 HTTP 代理。Mixed Port 对「尊重标准环境变量」的宿主机工具有效，但对 Docker 引擎默认出站不够稳——这也是 OpenHands 与纯 CLI Agent（如 Copilot CLI）排障差异最大的地方：你往往要同时照顾宿主机 TUN与容器网络模式。

本地非 Docker 安装（make build、poetry install 等）则更接近传统终端代理场景：与 WSL2 内 Git／npm 与 Windows Clash 打通一文类似，需确认执行命令的 shell 与 IDE 集成终端是否同一出站。无论 Docker 还是裸机，把排障抽象成「统一 TUN + 日志驱动规则 + 最后一层才动镜像站」会省掉大量重复尝试。

安装与运行阶段常见主机簇（以日志为准，勿背死的清单）

Docker Hub 侧常见 auth.docker.io、registry-1.docker.io、index.docker.io 及 production.cloudflare.docker.com 等（具体以 pull 日志与 Connections 为准）。项目文档若引用 ghcr.io 预构建镜像，还需单独收录 GitHub Container Registry 后缀。OpenHands 官方 compose 镜像名会随版本调整，本文不替某个 tag 背书行为——请以你本机 docker compose config 打印的镜像地址为准，把对应 registry 主机写进 Rule Provider。

npm registry 侧绕不开 registry.npmjs.org 与 verbose 日志里的 tarball 下载域（可能落在 *.npmjs.net）。GitHub 侧除 github.com 外，REST 常走 api.github.com；Raw、Release、LFS 与对象存储往往分散在 githubusercontent.com、objects.githubusercontent.com 等子域。模型 API 侧请按你在 OpenHands 设置里选的提供商对拍：Anthropic、OpenAI、Google、OpenRouter、Bedrock 代理网关等主机名各不相同；沙箱执行 curl 测试模型时，可能出现与宿主机不同的源地址。任何「转载静态列表」只能当起跑线；真实世界还有 302、区域 PoP 与短期 CDN。请把高频集合沉淀为 Rule Provider，避免把几百行 DOMAIN 直接糊进主配置难以合并。

1启用 Clash TUN，让宿主机 docker 与终端共用一张「出口地图」

在 Meta 内核图形客户端打开 TUN、切到规则接管模式，并按平台完成驱动／Helper 授权。第一次配置建议先跟 Clash Verge Rev TUN 模式完整教程走通，再回读本篇。堆栈在 gvisor 与 system 之间取舍可参考 TUN 堆栈 gvisor 与 system：若 Docker Desktop 虚拟化与 TUN 叠加导致偶发卡顿，可尝试换栈或对 com.docker.backend 等进程做排除实验，而不是盲换节点。

TUN 生效后，在宿主机执行 docker pull hello-world，同时观察 Connections 是否出现 auth.docker.io 相关条目且策略非意外 DIRECT。若设备策略禁止 TUN，只能在将要执行 docker／npm 的同一会话里显式导出 HTTP_PROXY／HTTPS_PROXY／ALL_PROXY，并在 compose 的 environment 里为需要出网的 service 重复写入——维护成本高，但比反复重装 OpenHands 更省时间。

2用连接日志排规则顺序，把 Docker Hub 与 GitHub 排在宽泛直连之前

许多配置里存在激进的 GEOIP,CN,DIRECT 或超大的「国内域名」合集，仍会把部分海外 SaaS、CDN PoP 送进直连，在跨境抖动时表现为长尾超时。做法是在这些宽泛规则之前插入针对 Docker Hub、npm registry、GitHub API 与模型 API 的后缀，并映射到你愿意手动 pinned 的策略组。下面是一段仅作演示的 YAML 骨架，组名请替换为你文件中真实存在的名称：

# Example only — replace PKG_PROXY / GH_PROXY / AI_API with your proxy-group names
rules:
  - DOMAIN-SUFFIX,auth.docker.io,PKG_PROXY
  - DOMAIN-SUFFIX,docker.io,PKG_PROXY
  - DOMAIN-SUFFIX,docker.com,PKG_PROXY
  - DOMAIN-SUFFIX,ghcr.io,GH_PROXY
  - DOMAIN-SUFFIX,registry.npmjs.org,PKG_PROXY
  - DOMAIN-SUFFIX,npmjs.org,PKG_PROXY
  - DOMAIN-SUFFIX,github.com,GH_PROXY
  - DOMAIN-SUFFIX,githubusercontent.com,GH_PROXY
  - DOMAIN-SUFFIX,api.github.com,GH_PROXY
  - DOMAIN-SUFFIX,api.anthropic.com,AI_API
  - DOMAIN-SUFFIX,api.openai.com,AI_API
  - DOMAIN-SUFFIX,generativelanguage.googleapis.com,AI_API
  - GEOIP,CN,DIRECT
  - MATCH,GH_PROXY

「写得多」替代不了顺序错：请参阅 Clash Meta 规则顺序与 MATCH。OpenHands 若启用浏览器自动化或远程桌面组件，还可能出现 Playwright、VNC 相关主机——仍以 Connections 为准分批收录，可参考 MCP 远程模型分流里对多跳 API 的写法。

3Docker：镜像拉取、compose 网络与代理环境变量

宿主机已开 TUN 后，多数环境下 docker pull 会随系统路由进入 Clash；若仍直连超时，检查 Docker Desktop 是否配置了与 Clash 冲突的固定 DNS（如 8.8.8.8 却未走内核解析策略），或是否启用了「绕过 VPN」类选项。企业镜像仓库（Harbor、内网 registry）往往需要直连或专用策略组，勿与公网 Docker Hub 混在同一组。

在 docker-compose.yml 中为需要访问外网的 service 添加 HTTP_PROXY／HTTPS_PROXY／NO_PROXY 时，NO_PROXY 应包含内网段与本地 LLM 网关；勿把 api.github.com 误写入 NO_PROXY。若使用 network_mode: host，容器将共享宿主机网络栈，TUN 规则通常可直接覆盖；默认 bridge 模式下，容器 DNS 由 Docker 内置解析器转发，需与下文 DNS 章节一并核对，避免「宿主机 pull 成功、容器内 pip 失败」的分叉。

国内用户有时会配置 registry-mirrors；镜像站与 lockfile、供应链审计策略不一致时，会出现「元数据像有、层拉不动」。公司环境通常只允许白名单 Harbor。不要把未知第三方 registry 设为默认。

4npm 与 GitHub API：源码路径与 Agent 运行时

从源码构建 OpenHands 时，在将要执行命令的同一目录运行 npm config get registry：若指到未同步的镜像或只读脱库，会出现假死。企业内部 Nexus／Verdaccio 往往需要直连或专用策略组。若与公网 https://registry.npmjs.org/ 混用，请用 scope 或项目级 .npmrc 明确优先级。

Agent 克隆仓库、创建 PR、读 Actions 日志时，流量集中在 GitHub API 与 GraphQL；策略组若是激进的 url-test，可能在长会话中途自动换出口，症状像随机断流。实践上可把 api.github.com 相关簇放进更新少的手动 GH_PROXY 组。身份方面，gh auth login 或 PAT 校验时的跳转域名同样会出现在日志里；遇到 302 链跨域时，只写单条 DOMAIN 往往不够。

npm config get proxy 与 https-proxy 若指向陈旧明文入口，会在中间盒子上被半截丢弃；与 TUN 并存时，有时反而应当清空 npm 级 proxy，让流量交给系统路由——是否采用要看公司是否强制显式上游代理。strict-ssl 与公司根证书是否导入系统／Node 信任库要一起核对。

5模型 API：多提供商与沙箱出站

OpenHands 支持在设置里切换 Claude、GPT、Gemini 及兼容 OpenAI 协议的网关。安装阶段超时与运行时模型 API 超时要分开看：前者多在 Docker／npm／GitHub；后者在发起对话、执行工具、上传上下文时出现。请在报错瞬间对照 Connections：若主机名属于模型 API 却走了 DIRECT 或高延迟自动测速组，应把该后缀提前映射到AI_API 组，并与娱乐流量组解耦。

若模型走企业专线或 Azure OpenAI，个人订阅节点可能与 IT 官方出口冲突，此时应遵循组织规定的出口。参考 Claude Code CLI TUN 排障、Codex CLI 与 Gemini CLI 中对各提供商 API 主机簇的维护方式；OpenHands 只是多了一层 Docker／沙箱，排障原则相同：日志驱动、规则靠前、DNS 对齐。

6DNS、FakeIP 与分流规则语义对齐

常见误区是规则里写了 DOMAIN，但 Docker 内置 DNS 与 Clash 模组走了另一套解析路径，导致「看起来像命中 DIRECT，实则目的地址已分叉」。建议阅读 Meta 内核 DNS 防泄漏指南与 fake-ip-filter 与局域网；确认 FakeIP 模式下需要直连的本地域、内网 registry 已写入 fake-ip-filter；若使用 nameserver-policy，策略域名要与规则里出现的主机一致。更细的按域 DoH 写法可参考 nameserver-policy 教程。

最小验证：用轻量探针代替反复全量 compose

调参期间不要每次都用完整 docker compose up --build 撞墙。可以分四步：其一，docker pull hello-world 观察是否与 Connections 一致；其二，curl -Iv https://auth.docker.io/ 与 https://registry.npmjs.org/；其三，curl -Iv https://api.github.com/（注意速率限制，仅作连通性探针）；其四，对你配置的模型 API 基址做 HEAD 或组织允许的健康检查。若 TUN 打开后仍显示稳定直连超时，问题多半在更底层出口、MTU 或证书，而不是 OpenHands UI 参数。

在 WSL2 里跑 Docker 的用户，请读 WSL2 与 Windows Clash 打通，避免 Linux vNIC 与宿主策略各说各话。

补充 FAQ：OpenDevin 改名、镜像加速与「看起来像超时」的 TLS

OpenDevin 和 OpenHands 是同一个项目吗？社区语境里常把 OpenHands 视为 OpenDevin 路线的延续；排障时以你 clone 的仓库与 compose 文件为准，出站主机簇不因品牌名改变而改变。

只给 OpenHands 容器配 HTTP_PROXY 就够吗？不够。拉镜像阶段往往由 dockerd 在宿主机完成；若宿主机未进 TUN，容器内 proxy 也救不了 pull。应宿主机 TUN 优先，再按需给 service 写环境变量。

模型 API 走国内中转网关还要写 api.openai.com 吗？以 Connections 里实际出现的 Host 为准；中转域名也要单独规则，勿假设「写了 OpenAI 就能覆盖所有网关」。

合规提醒：请遵守所在地法律、GitHub／各模型提供商服务条款与公司网络政策；生产与办公环境优先使用经批准的专线、ZTNA 或官方出口。勿把个人代理凭据、API Key 写入共享仓库、compose 公共分支或 CI 日志。

下载渠道：安装 Clash 图形客户端请优先使用本站下载页，避免误装二次打包不明二进制；本文讨论的是出站与 OpenHands 工具链排障，与具体第三方安装包无代言关系。

小结：把 Docker Hub、GitHub、npm 与模型 API 画进同一张图

OpenHands 同时踩在 Docker Hub、npm registry、GitHub API 与多家模型 API 上；只修其中一层都会在压力场景下露馅。Clash TUN 先把终端代理边界抬到操作系统层，让分流规则覆盖 dockerd 与宿主机工具链；随后用日志驱动的方式维护镜像站、registry 与 API 后缀，再回头整理 compose 环境变量与 DNS。这比反复 docker system prune 或盲目换 npm 镜像更能定位根因。

不少临时方案要求在每个 shell、每个容器里手工复制代理 URL；一旦 compose 升级或沙箱进程丢失环境变量，就会回到「偶发成功」状态。Clash 系 Meta 客户端把订阅、可视化规则与连接追踪放在同一工作台，排障时可以直接看到某次 模型 API 调用走了哪条策略。若你按本文完成 TUN、规则、Docker／npm 与 DNS 对齐仍失败，多数已超出个人软件配置范畴，应转向企业 IT 或官方状态页。若希望用统一界面维护这些规则，可以免费下载 Clash，先完成 TUN 教程，再用最小 curl／docker pull 探针验证整条 OpenHands 链路。

OpenHands 装依赖总超时？Clash TUN 分流稳连 GitHub 与模型 API（2026）