文章目录
docker pull「卡住」时引擎在等什么
容器镜像并不是一个单文件下载，而是一条流水线：拿 manifest → 决定要拉哪些 blob → 对每一层并行建 HTTPS 连接 → 校验 digest → 解压到本地存储。因此你在屏幕上看到的「pending」可能对应完全不同的阻塞点：某一步在等待 DNS 应答，某一步在等待 429 限速或 CDN 侧的排队，也可能只是 TLS 握手在 VPN 链路里超时，表面却都表现为进度条停摆。
如果你习惯先把问题笼统归因为「超时」，很容易就陷入「换一个镜像源试一下」这类随机试错。更有效的做法，是强迫自己回答两个可验证的子问题：① 此时此刻本机是否能稳定解析 Registry 需要的那些主机名；② 在向这些主机名发起 HTTPS 请求时是否能完成握手并收到合理的状态码。 只要这两个问题分开了，再结合是否开启 VPN，就能把「镜像下载超时排查」收敛到具体一层。
与纯浏览器场景不同，dockerd 往往以系统服务身份运行，继承的是宿主机解析器与路由表，而不是你终端里临时 export 的环境变量（除非守护进程显式配置代理）。这一点决定了：你在 shell 里测通 ≠ 引擎一定走同一条路径。后面几节会反复回到「用同一台机器、同一套 VPN 状态复现」这一原则。
二分法：先排除 DNS，再排除传输路径
建议把第一次排查控制在五分钟以内，并且不要先动 VPN 开关，而是先记录「当前 VPN 状态」作为基线，否则你会同时改变 DNS 与默认路由，变量叠在一起无法对比。
DNS 侧快速信号：对 registry-1.docker.io 与（若你拉的是官方 Hub 命名空间）常见 CDN 主机名做解析。若 dig 或系统解析工具在数秒内无结果、返回 SERVFAIL，或返回明显异常的 IP 集合，问题多半在解析链路——例如公司内网 DNS 对特定域做了过滤、本地 systemd-resolved 与 VPN 客户端注入的解析顺序冲突、或你强制使用 DoH 却没让引擎侧走同一解析器。
传输路径快速信号：在解析已返回合理 A/AAAA 记录的前提下，用 curl -Iv 或等价的 TCP/TLS 探测工具去访问 https://registry-1.docker.io/v2/ 一类端点。若 TLS 握手阶段长时间挂起、连接在建立后立刻被 RST、或稳定出现「卡在某个固定大小之后不再增长」，更像中间盒、出口策略、MTU 分片或 VPN 封装开销导致的链路问题，而不是「域名没解出来」。
当你确认「解析快、但 HTTPS 慢或失败」时，才有理由把Docker VPN这一类关键词放进诊断笔记：本质是谁在承载这条 HTTPS 会话的出站。若 VPN 使用虚拟网卡下调了有效 MTU，而路径上又有 DF 未分片的大数据包，表现出来的可能就是「小包命令行能动、拉镜像大卡死」的假性随机故障。
若在协议选择上仍不确定是否应该为「易识别」网络准备备用传输方式，可把 VPN 协议对比：WireGuard、OpenVPN 与私有协议各适合什么场景 当成背景阅读：它不直接修 Docker，但帮你建立「链路被识别时可切换」的预期，免得只在 Registry 一端反复改配置。
会与 Docker Hub 交互的典型主机名
Docker Hub 官方路径会牵涉多条主机名，其中任一条卡住都会让 pull 停摆。实践里不必死记硬背全部，但排查时要意识到「我只 ping 通了一个域名」并不等价于「整条 pull 链健康」。
- Registry 与认证：拉取公共镜像时，客户端需要与 Docker 提供的 Registry 端点通信；若企业环境对未分类的 HTTPS 目标统一审计，常见症状是首包延迟极高或在某些时段被排队。
- 实际层文件所在 CDN：大体积层往往并不一直落在单一主机名上，CDN 调度会让你的连接落到不同边缘。若某条出口对特定 ASN 或地理区域策略不佳，可能表现为「小镜像能拉、大镜像永远差最后几层」。
这也是为什么「只测浏览器能否打开某个网站」证明力有限：浏览器与 dockerd 可能走不同解析器、不同证书信任链、甚至不同网络命名空间（尤其在 rootless 或容器化 CI 里）。排查时尽量在宿主机直接对 Registry 主机名做探测，再与引擎日志里的报错时间戳对齐。
VPN 全开时的高频诱因：MTU 与远端 DNS
很多开发者开启「全盘加密隧道」后，第一件正确的事是：显式写下来当前 DNS 从何而来。有的 VPN 会把系统默认解析器切到远端；若远端对你所在网络的递归解析本身不稳定，就会在「HTTPS 之前就失败」——这类问题与镜像站无关。
第二件值得记录的是：MTU。封装后的有效载荷变小，大而密的 TLS 记录或 HTTP/2 frame 在某些路径上可能被静默丢弃（症状常是连接挂起而非立即报错）。若你在开启 VPN 后明显更容易复现卡住，而把同一台机器放回本地直连就立刻恢复，排查笔记里就应出现「链路层碎片化 / MTU」这一行，再去按官方文档调整网络参数或按客户端建议开启兼容模式——而不是先怀疑 Hub 当天「抽风」。
第三件是双栈偏好的副作用：若解析同时返回 A 与 AAAA，而你的隧道对 IPv6 支持不完整，表现为偶发超时。此时「强制 IPv4 试拉一次」只是验证手段，长期仍应修隧道或解析策略。
分流场景：dockerd 有没有走你想要的出口
当你使用「仅浏览器走 VPN」或「仅少数应用走隧道」这类策略时，最容易漏掉的是：系统服务进程并不在你脑中的那份应用名单里。dockerd 或 Docker Desktop 的后台组件可能仍走默认物理出口，而你在 shell 里做的测试却走了隧道——两者一旦不一致，就会出现「我 curl 明明通，docker pull 却不行」的经典错觉。
解决思路不是死记规则，而是回到事实：拉镜像时到底是哪一个 uid、哪一个二进制、哪一张路由表在承载连接。在桌面端，若客户端提供按进程或按目标域名的分流，你需要明确「Docker 相关进程」被归入了哪一类。Windows 用户若已熟悉 Split Tunneling 的黑白名单心智，可直接对照 Windows VPN 分流怎么配置？指定程序直连或走隧道详解（2026） 里的「默认方向 + 例外」写法，把 Docker 守护进程与虚拟网卡相关路径当成一等公民，而不是事后补丁。
在 Linux 桌面或服务器上，若你使用图形客户端接管路由，记得同步检查：systemd 服务单元是否在 VPN 之后启动、以及 iptables/nftables 规则是否对 docker0 桥接流量另有策略。否则你会看到「宿主机拉取成功、容器内构建仍失败」这种分层现象——那已经超出本文 Hub 拉取范围，但提示你问题在转发而不是账号。
Docker Desktop 与 Linux 守护进程的差异注意点
Docker Desktop（macOS/Windows）经常在用户态网络栈里再套一层，实际出站的接口与你在宿主机 traceroute 看到的不完全一致；再加上 WSL2 后端时，「究竟是谁在解析、谁在走 VPN」更容易分裂。遇到疑难时，优先以引擎侧日志与 Desktop 自带诊断为准，而不是仅相信宿主机 shell。
在原生 Linux 上跑 dockerd 时，与 VPN 的最大交集通常是防火墙标记与路由策略路由表。若你已按 Linux VPN（Ubuntu）下载安装与首次配置完整教程（2026） 完成客户端首开，下一步就应该把「服务启动顺序 + 重启后路由是否回填」记在运维笔记里：镜像拉取失败如果是重启后才出现，优先怀疑钩子没持久化。
企业代理、镜像加速与「不要猜配置」
公司网络常见的另一条分支是：出公网必须经过 HTTP 代理。Docker 守护进程侧的代理往往需要写在 systemd 环境里或 daemon 配置里，而不仅是当前 shell。若你只给交互式终端配了变量，很容易出现「人用得上、daemon 继续直连失败」的差异。
关于镜像加速：Daemon 允许的 registry mirrors 是公司基础设施决策，本文不替读者选择具体镜像域名。值得你记住的红线是：任何第三方缓存都应被当作供应链的一环——要可查来源、要能回滚、要在变更时留存 digest 校验预期。不要因为 pull 慢了就把未知镜像站写进全局配置却把审计责任扔给默认值。
若你已排除 DNS、MTU、分流与代理，仍稳定得到认证或限速类错误代码，那才是进入「账号配额、镜像删除、计费策略」域的问题；这一类与Docker Hub 拉取失败的关键词相关，但与 VPN/DNS 路径不是同一条因果链。
可打印的一张检查清单
-
1
固定 VPN 状态
分别记录「关 / 开 / 仅分流」三种基线，每次只改一个变量。
-
2
解析 Registry 关键主机名
观察是否慢、是否被劫持、是否 IPv6 异常。
-
3
对 Registry HTTPS 做最小握手验证
区分 TLS 挂起与 HTTP 层业务错误。
-
4
核对 dockerd 是否走代理 / 是否命中分流规则
与交互式 shell 的测试结果对照，不要假设一致。
-
5
若仅 VPN 开时复现，记录 MTU 与 DNS 来源
再决定是改客户端、改系统解析，还是调整链路参数。
小结：把「pending」翻译成「等待解析」或「等待 HTTPS 字节流」之一，你的下一步动作会完全不同；这也是镜像下载超时排查里最容易被省掉却收益最高的一步。
方案对比与日常开发出口选择
市场上常见的应急做法包括：临时关闭 VPN、临时换 DNS、或把 Registry 流量硬切到某条「看起来更快」的链路。它们都能换来短期可用性，但长期风险也不该被粉饰：长期关闭 VPN 等于把开发机出口直接暴露在你无法完全信任的网络路径上；随便写入未审计的镜像缓存则把供应链攻击面扩大；而把问题简单归结为「Hub 不行」往往掩盖了公司网络策略或本地 MTU 的真实矛盾。
更可持续的组合通常是：让解析稳定、让隧道参数与系统路由一致、让需要访问敏感 Registry 的进程明确走哪条出口——而不是每天手工切换全局开关。DVDVPN 客户端在五端提供统一的图形配置能力，支持在桌面端以规则方式管理分流与 Kill Switch 的协作；当你已经用命令行把问题定位到「解析」或「传输」其中之一时，再在客户端侧把 Docker 关联流量稳定下来，比在镜像地址上反复试错更符合工程习惯。
若你希望把同样的思路用在团队笔记本统一装机流程里，可先完成账号注册并从 下载页 获取对应平台安装包，再到 账户后台 校对流量配额与多端登录——免费套餐含新用户赠送流量，够用与否取决于你的拉镜像频率与是否在 CI 中集中下载。