docker pull由Docker守护进程执行，不是当前终端里的curl。一次拉取通常先访问Registry API，跳转到认证服务获取Token，再下载Manifest和多个Blob；Blob还可能来自对象存储或CDN。因此docker login成功，只说明一部分认证链路可用。
一、镜像拉取的主要阶段
| 阶段 | 请求内容 | 常见故障 |
|---|---|---|
| Registry探测 | 访问v2 API | DNS、代理、TLS |
| Token认证 | 访问认证服务 | 401、凭据和时间 |
| Manifest | 读取镜像清单 | 权限、平台和标签 |
| Blob下载 | 并发下载镜像层 | 重定向、带宽、超时 |
| 内容校验 | 按Digest验证 | 缓存损坏和存储问题 |
二、守护进程代理与容器代理不同
镜像拉取由Docker Daemon发起，应在systemd服务、Docker Desktop或对应守护进程配置中设置代理。运行容器的环境变量只影响容器内部应用。构建阶段又是第三层。
完整分层见Docker守护进程、构建与容器代理。
三、Registry Mirror是什么
Registry Mirror面向镜像内容，缓存或代理上游Registry；HTTP正向代理则转发通用网络连接。Mirror能减少重复拉取和外部带宽，但需要可信来源、同步策略、存储容量和访问控制。它不能自动替代私有Registry认证或所有外部镜像源。
四、login成功为何pull失败
登录请求体积很小，而Blob可能数百MB并并发下载。认证服务、Registry和Blob存储还可能是不同域名。应查看守护进程日志中的实际主机和阶段，检查代理是否允许重定向目标、请求大小与长时间传输。
五、401、403和407如何区分
- 407：守护进程到企业代理的认证；
- 401：Registry Token或登录凭据；
- 403：仓库权限、组织策略或签名URL；
- 429：Registry限流；
- 502/超时：代理上游、Blob地址或容量。
六、NO_PROXY如何处理私有Registry
同一内网的私有Registry可能应直连。绕过规则需包含守护进程实际使用的域名和端口，并按Docker版本验证。若Registry把Blob重定向到另一内网域名，也需纳入设计。不要把所有Registry域名粗暴绕过。
七、证书错误应如何修复
私有Registry应使用正确域名与受信证书。企业CA需要安装到Docker守护进程认可的位置，并重启验证。insecure-registries会降低传输和身份保障，不应成为方便排错的长期配置。
TLS通用检查可参考HTTPS代理证书错误排查。
八、并发下载为什么影响代理
Docker可能并发下载多个层。并发过高会占用代理连接和带宽，过低则拖慢拉取。应结合镜像层大小、网络延迟、代理容量和Registry限流调整，不要只测试一个小镜像后直接扩大到所有构建节点。
九、多架构镜像会访问什么
同一标签可能先返回Manifest List，再选择当前平台对应Manifest和Blob。出现“manifest unknown”或平台不匹配时，不一定是代理问题。应记录主机架构、请求标签与Digest。
十、CI中哪些层容易混淆
宿主守护进程拉取Job镜像、Docker-in-Docker守护进程拉取构建基础镜像、Job容器内部访问包仓库，是三套网络环境。GitLab Runner分层可参考Docker与Kubernetes执行器代理。
十一、排查步骤
- 记录Docker版本、守护进程位置和Registry；
- 确认失败在探测、Token、Manifest还是Blob；
- 检查守护进程代理与NO_PROXY；
- 区分407、Registry权限、TLS和429；
- 核对Blob重定向后的实际主机；
- 用小镜像和大镜像分别测并发；
- 检查Digest校验和日志脱敏。
十二、结论
Docker Registry代理排查必须围绕守护进程和拉取阶段展开。登录成功不是终点，认证服务、Manifest与Blob下载都要可达；Mirror也应作为镜像供应链组件管理，而不是通用代理替代品。
