Docker Desktop 拉镜像失败？与 Windows 11 宿主机 Clash 对齐代理与 DNS 分步操作（2026）

读完本文你能独立完成什么

你可以按固定顺序完成：确认 Windows 侧 Clash 实际监听的 mixed 或 HTTP 端口，以及系统代理或 TUN 是否与浏览器现象一致；在 Docker Desktop 图形界面为引擎配置 Manual 代理，必要时对照等价的daemon.json；理解镜像拉取与镜像内 apt分别受哪一层代理影响；为 docker build 配置 HTTP_PROXY 构建参数或 Dockerfile 环境变量；在怀疑解析异常时调整 Docker 的 DNS 设置并与 Clash 的 DNS／fake-ip 行为对照；最后用短命令与日志做分层验收，而不是反复重装 Docker。

根因：为什么「Win11 开了 Clash，Docker 却像没代理」

第一，Docker Desktop 在 Windows 上使用独立的 Linux 虚拟机承载引擎（常见为基于 WSL2 的后端）。你在 PowerShell 或 CMD 里看到的网络环境、甚至你在 WSL 发行版里 export 的代理变量，并不自动等价于 Docker 守护进程及其拉镜像会话使用的出站路径。第二，Clash 的「设置为系统代理」主要服务 Windows 用户态里会读系统代理的应用；而 dockerd 拉取镜像时往往遵循 Docker 自己读取的代理配置或守护进程参数，必须通过 Docker Desktop 或 daemon.json 显式对齐。第三，容器内部执行 apt-get 时走的是容器自己的网络命名空间，默认同样不会因为你给宿主机设了代理就自动带上 http_proxy，除非你在镜像构建或运行时注入。

第四，DNS 路径不一致时，表现很像「代理没生效」：解析被污染、返回意外地址、或与 Clash fake-ip 协作不一致，都会出现 pull 握手失败、TLS 报错或间歇超时。需要把「代理是否到达 Clash」与「解析是否一致」分开验证。若你尚未在 Windows 上把 Clash 基础跑通，建议先完成Windows 11 下 Clash Verge 首次安装与断网排查，再回本文对接 Docker。

第一步：确认宿主机 Clash 端口与可达性

在 Clash 系客户端中记下实际生效的 mixed-port 或单独的 HTTP 端口（下文以 7890 为例，请替换为你的真实端口）。确认浏览器访问目标 registry 相关站点时，Clash连接日志里能看到对应域名被正确分流。若你计划让局域网内其他设备或虚拟网卡上的客户端访问同一端口，需要理解「仅监听 127.0.0.1」与「允许局域网／绑定多接口」的差异；当 Docker 后端从另一网络命名空间访问宿主机代理时，行为上接近「跨接口访问」，细节可对照允许局域网与防火墙放行一文，避免只开了浏览器代理却拦了来自虚拟网络的入站。

第二步：在 Docker Desktop 图形界面配置 Manual 代理

打开 Docker Desktop → Settings → Resources → Proxies（不同版本菜单名称可能略有差异，以你安装的版本为准）。启用 Manual proxy configuration，在 Web Server (HTTP) 与 Secure Web Server (HTTPS) 中填入指向宿主机 Clash 的地址。

常见填法有两种，需以你本机实测为准：（1）http://127.0.0.1:7890——在不少 Docker Desktop 版本上，引擎侧会通过宿主网关访问回环代理；（2）http://host.docker.internal:7890——利用 Docker Desktop 提供的宿主机解析名指向 Windows 主机，在部分网络组合下更稳定。若一种填法 pull 仍失败，可切换另一种并点击 Apply & restart 后重试。请勿在截图或工单中泄露订阅与令牌。

配置完成后，在 PowerShell 执行 docker pull hello-world 或你常用的基础镜像，观察是否仍 TLS 超时；同时打开 Clash 日志，确认 Docker 相关出站是否命中预期策略与节点。

第三步：daemon.json 与图形界面配置的关系

Docker 守护进程还支持通过 daemon.json 声明代理、DNS、镜像加速等。Docker Desktop 在 Windows 上往往提供与界面操作等价的底层配置；若你习惯用文件管理，可在 Docker 文档指明的用户或系统配置路径中编辑（路径随版本与安装方式可能不同，以官方文档与当前安装为准），避免盲抄过时博客里的盘符路径。

与代理相关的典型键包括指向 HTTP 代理的字段（名称随 Docker 版本演进，请以你使用的 Engine 文档为准）。核心原则不变：守护进程认识的代理才影响 docker pull、docker push 等由 dockerd 发起的流量。若你同时配置了界面与文件，应保证语义一致，并在修改后重启 Docker Desktop，避免半套旧配置残留。

第四步：镜像拉取仍失败时，分层检查 DNS

在 Clash 侧若启用 fake-ip 或自定义 DNS，而 Docker 引擎仍使用另一套解析上游，可能出现「域名在浏览器里解析正常、引擎侧握手异常」。可操作方向包括：在 Docker Desktop 的 Docker Engine 或网络相关设置中，为守护进程指定 与宿主机协调的 DNS 服务器；或在 daemon.json 中使用 dns 数组列出你希望引擎使用的地址（例如公共 DNS，具体以你的合规与网络策略为准）。

修改 DNS 后同样需要重启 Docker 并复测 pull。若你怀疑是规则未覆盖 registry 子域，应在 Clash 连接日志中核对实际请求主机名，再与自定义规则教程中的写法对照，把遗漏的域名前移到合适优先级，而不是只反复更换节点。

第五步：容器里 apt 不走代理——与 pull 不是同一问题

很多读者混淆两类流量：（A）宿主机或引擎发起的 registry 拉取；（B）已进入容器后，apt-get 访问发行版镜像站点的 HTTP(S)。后者默认不会读取你在 Docker Desktop 里为引擎配的代理，除非你在 构建阶段传入 --build-arg HTTP_PROXY=... 并在 Dockerfile 用 ARG／ENV 接住，或在 docker run 时传入 -e http_proxy=...。

构建参数示例（端口与主机名请替换）：

docker build --build-arg HTTP_PROXY=http://host.docker.internal:7890 \
  --build-arg HTTPS_PROXY=http://host.docker.internal:7890 \
  -t myimage .

Dockerfile 内可配合 ENV http_proxy=... 让同一层中的 RUN apt-get 生效；构建结束后若不希望运行时继承，可在后续阶段取消变量。使用国内镜像源加速 apt 与使用代理并不矛盾，但应避免「镜像源与代理策略互相打架」导致路径绕远或失败。

第六步：docker compose 与多服务构建

在 Compose 场景下，除在 compose 文件中为需要构建的服务声明 build.args 外，还应关注拉取依赖镜像时仍由引擎代理负责。若 compose 同时拉起多个服务，请逐个确认是否仍有某张镜像来自未覆盖规则的 registry 主机名。与单机 docker 命令相同，修改代理或 DNS 后务必让栈重启，避免旧容器沿用构建缓存里的错误假设。

第七步：registry 镜像加速（可选，与代理正交）

在部分网络环境下，用户会在 daemon.json 中配置 registry-mirrors 以加速 Docker Hub 拉取；这与把流量交给 Clash 是不同层面的优化——镜像站本身也需可达。若你同时启用代理与镜像，出现偶发失败时，应在日志里区分是「连镜像站超时」还是「连原始 registry 超时」，再决定调整顺序或规则，而不是把两类问题混为一谈。

分步对照排查清单（建议打印勾选项）

（1）浏览器访问 Clash 日志可见的测试站点是否正常。（2）Docker Desktop 代理地址是否与 Clash 端口一致，修改后是否已重启。（3）docker pull 失败时，Clash 是否出现对应 registry 主机名的连接记录；若无，优先怀疑引擎未走代理或 DNS 不一致。（4）容器内 apt 失败时，是否已在 build／run 层注入 http_proxy。（5）fake-ip 与 Docker 解析是否冲突，必要时为引擎指定明确 DNS 并复测。（6）Windows 防火墙是否阻止了虚拟网卡与宿主机端口通信（可与局域网放行文交叉阅读）。（7）公司设备组策略是否限制本地代理或虚拟网卡。

安全与合规提醒

将代理监听扩展到非回环地址或放宽防火墙时，请意识到同一网络内的其他设备也可能尝试连接；在不可信网络应及时收回「允许局域网」类能力。勿在公开渠道泄露订阅链接。请遵守当地法律与服务条款，本文仅描述在自有设备上的网络调试思路。

小结

Docker Desktop 与 Windows 11 上已跑通的 Clash 对齐时，关键是接受「引擎在独立 VM 网络栈」这一事实，用图形界面或 daemon.json把 HTTP/HTTPS 代理显式指到宿主机端口，再单独处理容器内 apt 与 构建参数；最后把 DNS、fake-ip 与规则覆盖放在同一套排错顺序里验证。与站内 WSL2 共用代理、Win11 首次安装与局域网放行等文章连读，可以覆盖从桌面浏览器到容器构建的完整开发链路。

相比在论坛碎片里反复试错，使用维护积极的客户端、从本站下载页获取安装包并配合使用教程建立固定排错顺序，长期成本更低。规则型代理在可观测性与分流精度上仍具优势；当你需要在本地稳定拉镜像与构建依赖时，按本文对齐 Docker 与宿主机 Clash，能明显减少「系统明明能上网、Docker 却完全不走代理」的困惑。→ 立即免费下载 Clash，开启流畅上网新体验。