Docker 拉不动别急着换 DNS：国内镜像加速源挑选、配置与避坑全指南

Wed, 15 Jul 2026 19:30:00 +0800

先说结论国内网络环境下，Docker 拉取镜像失败，往往不是镜像不存在，也不一定是 DNS 的锅。更常见的原因是：公共仓库的访问链路拥堵、某个加速源临时故障，或者配置文件改对了却没有重启 Docker。我的建议是：先打开 status.anye.xyz，把它当作“镜像源天气预报”，看多个源最近是否可用；再根据自己的系统改对配置文件；改完先校验 JSON，再重启 Docker，最后用一个小镜像做真实拉取验证。一、问题背景：为什么昨天能拉，今天就超时？很多人第一次遇到这个问题，是在部署一个很普通的服务：nginx、redis、postgres，或者 NAS 上的媒体服务。命令可能只有一句： docker pull nginx:alpine 但终端却出现了超时、context deadline exceeded、TLS handshake timeout、connection reset by peer，甚至长时间停在下载层。换一个镜像标签、重启路由器、修改本地 DNS，有时能暂时恢复，于是大家容易得出一个结论：Docker 太玄学。其实 Docker 拉镜像像是“从仓库借书”： Docker 客户端先找到仓库地址；再通过网络连接仓库；仓库返回镜像清单；客户端逐层下载内容；最后校验每一层是否完整。这条链路中任何一段堵住，都会表现为“拉不下来”。所以，镜像加速源不是魔法按钮，而是给这条路增加一条更顺畅的入口。二、问题表现：不要只看网页能不能打开一个镜像源网页能打开，不等于 Docker 一定能用。选择加速源时，至少要看四件事： 1. 地址是否真的可达浏览器打开首页，只能证明首页响应了。Docker 还要访问 Registry API、鉴权接口和镜像层下载接口。网页正常、拉取失败，是完全可能的。 2. 是否支持完整的 Docker Hub 加速链路有些地址只是一个网页代理或搜索页面，并不是 Docker Registry mirror。配置到 registry-mirrors 后，如果 docker info 看不到它，或者 docker pull 仍然直接访问默认仓库，就要怀疑它并非真正的加速服务。 3. 是否持续稳定，而不是刚好今天在线镜像源很像城市道路：今天通车，不代表明天不施工。稳定性比某一次测速的峰值更重要。家用 NAS 可以接受偶尔切换，CI 构建和生产环境则应该准备备用方案。

把一台慢成蜗牛的 Docker 镜像代理从 5 分 14 秒干到 0.6 秒:我踩过的三个坑和一段 5 行的 cron

Sat, 13 Jun 2026 07:20:00 +0800

先说结论

我在家里的自建小集群上跑着一个 registry:2 的 pull-through 代理,平时给局域网里的几台机器和 NAS 当 Docker Hub 镜像源用,用了快两年一直挺稳。直到有一天,它拉一个 5MB 的 alpine 镜像要 5 分 14 秒。

这篇文章记录我怎么查到根因、换了哪些方案、为什么每一版都没让我满意、最后怎么用一个 5 行的 bash 脚本 + 每天一次的 cron 把它彻底稳下来。整个排查过程 100% 是我在自己的机器上跑出来的真实数据,不是我抄 README、不是我看博客道听途说。

关键决策点都贴了实测数据。如果你也在自建 docker 镜像代理,或者你公司的 devops 团队在维护一个内部 registry 镜像,文末的 Q&A 段能帮你省掉至少 3 小时的踩坑。

镜像加速 on 魔都水滴

Docker 拉不动别急着换 DNS：国内镜像加速源挑选、配置与避坑全指南

把一台慢成蜗牛的 Docker 镜像代理从 5 分 14 秒干到 0.6 秒:我踩过的三个坑和一段 5 行的 cron