Docker Hub 拉取镜像总超时？Clash 分流 Hub 与镜像站域名实测（2026）

1. docker pull 链路里到底访问了谁

当你在命令行执行 docker pull library/nginx之类指令时，客户端并不是只跟一个「Docker 网站」通信。现代 OCI 分发流程通常会触及鉴权服务、Registry API以及承载 layer blob下载的CDN 或对象存储域名。任意一环若在受限网络下被路由到错误出口、遭遇高丢包、或 TLS中间环节被干扰，你都会在前台看到笼统的「timeout」或握手失败，却很难一眼看出卡在哪一跳。

对使用 Clash 分流的读者而言，关键结论是：必须把「Registry 主机名」而不是「你记得的官网域名」写进策略。浏览器收藏夹里的地址与 Engine 实际解析到的服务可能完全不是同一批 IP。再加上你可能启用了镜像加速器，加速器提供商的主机名同样需要独立考虑——有时需要直连以享受内地带宽，有时又需要与官方 Hub 的registry mirror回源策略一致，否则会出现「manifest 从加速器拿到、blob 仍去境外拉」的割裂体验。

这也是为什么站内会把「容器进程走宿主代理」与「Hub／镜像站域名分流」分成两篇：前者解决的是命名空间与端口可达（参见Docker 容器走宿主机 Clash），后者解决的是宿主机上 Docker daemon 自己的出站。二者在 CI、WSL、远程开发机场景里常常叠加出现，但排错时务必先分清楚触发拉取的进程跑在哪。

2. 典型报错：超时、握手失败与「看似通了」的假阳性

实战里最常遇到的描述包括：TLS handshake timeout、i/o timeout、connection reset、或长时间停在拉 layer 的百分比不动。它们并不等价：握手阶段失败往往意味着 TCP 已建立但 TLS 无法在限时内完成，可能与出口质量、错误 SNI、或者被中间设备打断有关；而纯超时有时是 DNS 走丢、有时是策略组选到了不可达节点、有时是 DIRECT路径本身在跨境段拥塞。

另一类「假阳性」来自部分域名已通、另一部分仍失败：例如浏览器能开 hub.docker.com的页面，但 Engine 访问 registry-1.docker.io仍卡住。用户容易误以为「Docker 已经能连」，实际上只是 HTTP 前端与 Registry API 走了不同证书与不同路由。排错时应以 docker pull -v或 daemon 日志里打印的主机名为准，而不是以浏览器为准。

若你同时使用企业内网 Registry与公网 Hub，还要注意 NO_PROXY类食品问题在宿主机侧同样存在：错误地把内网仓库送进境外节点会导致「偶发成功、批量失败」。这与 npm 私服分流里强调的「私有注册表直走内网」是同一类思路，只是把场景换成了 docker pull。

3. Docker Hub 与常见镜像站：建议写入规则的一组域名

下表整理的是「经常出现在 Hub 拉取路径中」的主机名类别，便于你在 mihomo里按DOMAIN-SUFFIX或 DOMAIN集中落策略。具体子域会随官方基础设施调整而变化，以你本机 dig与拉取日志为准；表内名称用于起步模板，而非永久保证完整。

大陆用户常见的 镜像加速器域名会出现在各云「容器镜像服务」帮助页中，地址可能轮替。务必以厂商当前文档为准，把当下有效的 FQDN 填进规则，而不是复制数年前的教程。写入 Clash时，建议把加速器域名放在「明确 DIRECT或内地低延迟组」区块，并与 Hub 官方后缀块分开，否则易出现「一半流量直连、一半仍被迫回 Hub」的混乱。

4. Clash／mihomo 规则怎么写才不互相打架

写规则时优先保证更具体的域名规则在泛化规则之前。例如：先声明 registry-1.docker.io走名为 PROXY-HUB的策略组，再写大范围的 GEOIP,CN,DIRECT。若顺序颠倒，某些实现里命中早停会导致 Hub 流量始终落在错误分组。可以把 Hub 理解成「开发关键基础设施」，与你在 Cursor、API场景里置顶开发者域名是同一习惯。

下面是一段仅作结构演示的片段，策略组名请替换为你订阅里真实存在的组名；注释必须使用英文以符合仓库规范：

# Example only: pin Docker endpoints before broad GEOIP rules
rules:
  - DOMAIN-SUFFIX,docker.io,PROXY-HUB
  - DOMAIN-SUFFIX,docker.com,PROXY-HUB
  - DOMAIN,production.cloudflare.docker.com,PROXY-HUB
  # Optional: mirror hostnames from your provider docs → DIRECT or CN-LowLatency
  - DOMAIN-SUFFIX,your-mirror.example.com,DIRECT

若你使用 规则集（rule-providers）而非手写全量列表，请确认第三方 GEO 或「去广告」集合没有粗暴拦截整段 docker.io。这类误杀在日志里有时只表现为持续的握手失败，排查成本很高。订阅更新类问题若伴随 TLS报错，也可交叉阅读订阅更新与 TLS 日志篇中的抓包与日志思路，迁移到 Registry 场景同样适用。

5. DNS 与 fake-ip：为什么「解析对了」仍可能命错规则

Clash Meta上常见的 fake-ip与 redir-host会改变「应用程序看到的解析结果」与「内核实际连到的远端」之间的关系。若 docker pull走的是系统解析路径而非经过 Clash DNS，可能出现规则集根本没机会按域名命中的情况；反过来，如果 Engine 使用了自己的解析结果而 Sniffer 与路由阶段不一致，也会看到「连接日志里的 SNI 与域名规则对不上」。

建议在排障时打开连接日志，对照「域名／SNI／进程」三列，并与 fake-ip 与 redir-host 对照文中的表格逐项核对：是否需要为某些模式开启 respect-rules、是否在 TUN 场景要关心绕行名单。对纯命令行用户而言，一个简单的启发是：先确认 Docker 守护进程所在网络命名空间里，解析与路由都确实经过你希望的那条路径，再讨论具体规则文案。

IPv6 双栈环境还会叠加 AAAA记录与择优逻辑；若你启用了 IPv6 上行却未在策略里覆盖对应出口，也可能表现为间歇超时。可与IPv6 双栈与 TUN篇里的「泄漏／回退」检查一起完成。

6. daemon.json 与 registry mirror：和分流并列的一层配置

Linux 与 Docker Desktop 都支持在 daemon.json里声明 registry-mirrors数组，把对 docker.io的请求改写为加速器入口。要注意：这一层不理解 Clash 的策略组，它只是在 Engine 内部改写 Registry 主机名。若加速器自身在境外，或仍需回源官方 blob，最终仍会访问到前文表格里的域名；这时**加速器配置**与 **Clash 规则**必须同时成立。

典型最小结构如下（地址必须换成你服务商提供的 HTTPS 入口；注释保持英文）：

{
  "registry-mirrors": [
    "https://<your-mirror-host>/"
  ]
}

修改后需要重启 Docker 服务或应用 Docker Desktop 设置。若你发现「改完加速器反而更慢」，常见原因包括：镜像站离你地理上并不近、供应商 QoS 变更、或你的 Clash仍把加速器域名送去了跨境线路。此时回到连接日志看实际命中策略，往往比反复更换镜像 URL 更有效。

7. 实测验证与日志怎么看

推荐的最小闭环是：先选一个体积适中的官方镜像（如轻量 hello-world或常用基础镜像），执行 docker pull -v，在 verbosity 输出里观察第一次 HTTPS 请求的 host；然后在 mihomo日志中搜索同名主机，确认策略组是否与预期一致、有无频繁切换。对于长时间拖慢，重点看blob 下载阶段是否命中了高延迟节点，必要时把 CDN 域名与 Registry API 域名拆到不同组做 A/B。

如果你启用了 Sniffer，可以对照Sniffer 与 SNI篇里关于日志字段的解释，核对 HTTPS 流量是否在域名维度上被正确还原。遇到「日志里有 IP、规则却只写域名」这一类错位时，应先修 DNS／Sniffer，再增删规则，避免堆叠出一组互相矛盾的兜底。

远程 Linux 服务器上拉取时若未跑桌面 Clash，而是依赖机房自带线路，也要区分：那是「无代理环境下的纯运营商问题」，不在本文覆盖范围内；但一旦你在该机器上同样部署了 mihomo 或 TUN，全文方法仍然适用。

8. 排查清单

9. 常见问题