浏览器访问镜像仓库页面正常，docker pull 却一直卡在 waiting for connection 或报 EOF；同一台机器拔掉代理直连又能拉下来——代理IP 明明配了，pull 却完全不认。Docker 的镜像拉取流量默认不读终端代理，它只认 Docker daemon 自己的代理配置，配错一层，pull 就全废，这是代理IP 环境下的高频翻车点。
为什么 docker pull 和浏览器走的不是一条路
docker 命令只是客户端，真正拉镜像的是后台 daemon；系统代理设置影响的是终端程序，daemon 默认不读。HTTP_PROXY 和 HTTPS_PROXY 要写进 daemon 的启动配置（systemd 的 environment 文件或 daemon.json），写在客户端 shell 里完全不生效。这是新手最容易踩的坑：终端里配了半天，daemon 一句没听见。
registry 域名规则也要对得上。docker hub 的仓库域名、自建镜像源的域名要分别处理：规则写窄了 pull 走直连，规则写宽了又把内网镜像源也带上代理，两头都会出问题。
三类典型报错怎么分
卡在 waiting for connection，通常是 daemon 没走代理，或代理地址端口配错，连接一直挂起；EOF 或 connection reset，说明走了代理但链路不稳，出口到 registry 的连接被中间层掐断，分层下载中途断也常表现为 EOF；401 unauthorized 或证书报错，多半是出口地区与账号地区不匹配，或出口证书链导致 registry 验签失败。
- 第一步确认 daemon 代理配置。systemctl show docker 看 Environment，或检查 /etc/systemd/system/docker.service.d/ 下的 proxy.conf，确认代理地址指向代理IP 客户端的监听端口，改完要重启 daemon。
- 第二步核对域名规则。看 daemon 的 NO_PROXY 和代理客户端规则，docker hub 与自建镜像源分开处理，内网镜像源别被强行带上代理。
- 第三步直连对比。临时停掉 daemon 代理配置直连拉一个已知镜像；直连正常代理必挂，问题在代理链路；直连也挂，先查本机网络与仓库可达性。
- 第四步查分层校验。pull 中断后重试看 digest 校验是否失败；失败说明分层数据被截断或改写，检查代理IP 出口稳定性，必要时固定出口再拉。
代理IP 场景的常见坑
出口地区与镜像源匹配——部分地区的仓库有就近调度，出口漂移让分层下载的 CDN 边缘不稳定，固定账号地区出口能减少中断；分层校验 sha256——镜像分层下载完要验摘要，出口抖动导致的分层截断会报校验不符，重试多次仍失败就换出口；凭据与认证——登录仓库的凭据与出口绑定，换出口后 401 变多，需要重新 docker login。三件事都顺了，pull 才稳定。
排查的关键是先确认 daemon 到底读没读代理，再谈链路问题；只改终端环境变量不重启 daemon，pull 永远不会变快。
docker pull 的流量只认 daemon 的代理配置，终端配得再漂亮也不会生效——代理IP 环境下排障，第一件事永远是确认 daemon 读的是哪份配置。