我平时最怕听到的一句话就是某个同事在群里喊docker pull 又卡住了。不是卡一两次是今天拉不下来、明天超时偶尔还给你返回一个i/o timeout然后整个 CI 都堵住。这几年我养成了一个习惯每隔一段时间就把 Docker 国内镜像源的可用列表翻出来重新验证一遍因为镜像源这东西太不稳定了去年还能用的地址今年可能就变成了no such host。正好今天是 9 月 9 日我把 2026 年目前实测还能稳定工作的加速源整理成一份新清单同时把配置方法、失效排查、以及一批容易踩的坑一起写出来。这篇文章适合刚装好 Docker、Docker Desktop正准备拉 MySQL 8.0、Redis、GitLab、Dify、青龙这些常用镜像但发现速度感人甚至直接失败的朋友参考。1. docker pull 卡在 Downloading 的原因比网速更复杂1.1 一次典型的拉取超时现场先把场景还原一下。你执行了docker pull mysql:8.0输出先是Pulling fs layer然后开始显示Downloading百分比停在某个数字不动过了几十秒直接给你一句failed to resolve source metadata for docker.io/library/mysql:8.0: failed to do request: Head https://registry-1.docker.io/v2/library/mysql/manifests/8.0: i/o timeout或者更常见的是error pulling image configuration: Get https://production.cloudflare.docker.com/...: EOF看完这两条报错你基本就能定位问题不在你本地磁盘也不在 Docker 版本而是 Docker 客户端跟 Docker Hub 之间的网络链路出了问题。我用同一份配置测试过超时和正常拉取的体感差距非常离谱——一个 20MB 的小镜像层不配加速源时可能卡十几分钟配完加速源之后同样的层三五秒就下来了。这种差距不是优化出来的是通路本身换了。1.2 Docker Hub、CDN 和镜像加速器之间的真实关系要说清楚为什么换一个 registry 地址就能提速得先明白 docker pull 背后发生了什么。平时我们直接执行docker pull nginx:latestDocker 客户端其实会按顺序做这么几件事向registry-1.docker.io请求一个认证 token拿 token 请求镜像的 manifest 元数据拿到这个镜像由哪些 layer层组成根据 manifest 里每个层文件的 SHA256 地址去一个 CDN 域名下并行下载 blob 数据全部下载完成后解包、合并、写入本地镜像存储。前两步的域名是docker.io第三步的真正数据下载域名解析之后大多指向海外 CDN。大陆访问 Docker Hub 时这几条路径经常出现高延迟、丢包和连接重置。所以哪怕你家里是千兆宽带该卡还是卡。镜像加速器做的事并不神秘你在 Docker daemon 的配置里声明一个registry-mirrors列表客户端拉镜像时会优先向这些 mirror 地址请求 manifest 和 blob。这些 mirror 服务由国内云厂商或者高校开源镜像站维护它们本身会定期回源同步 Docker Hub 上的热门镜像。如果 mirror 本地没有缓存它会先回源到 Docker Hub 拉一份再返回给你。用个生活化一点的说法不加速等于每次都得跨洋去海外仓库提货加了镜像源相当于在你所在城市设了一个中转仓第一次可能因为中转仓自身也要去海外补货所以慢一点但补完货之后再有人来提就完全不用跨洋了。这也解释了为什么有些冷门镜像第一次通过镜像源拉取还是偏慢——源头没有缓存中转仓要先帮你跑一趟。1.3 先浇一盆冷水镜像源不是网速放大器很多人换完镜像源后发现还是慢于是觉得镜像源没用。这其实是期望错了。镜像源只解决镜像层数据从 Docker Hub 回传到大陆的链路问题它不解决以下这些场景容器启动之后容器内执行apt install、pip install、npm install下载慢不归镜像源管你家或者公司的出口带宽本身只有 1Mbps那怎么加速都白搭镜像源服务商跟你的运营商之间的跨网链路拥堵比如你电信访问一个联通机房的镜像站高峰期依然可能不稳。所以正确的预期是镜像源能让从 Docker Hub 拉容器镜像这件事从不可用变成可用再从可用变成体感不错。但你不能指望它包治百病。2. 9月9日实测存活清单2026年值得优先用的国内镜像加速2.1 我判断能用的三个标准每次整理这种清单我都要先定义一下什么叫能用。不是 ping 得通就算能用我一般按三个标准来筛第一Registry 接口真实可达。直接用curl -sS -o /dev/null -w %{http_code} https://镜像源地址/v2/探测返回200或者401都行因为很多 registry 未认证时会返回 401这至少说明服务在线并正常响应了 registry 协议。如果返回000、503、403基本可以判定不可用或者拒绝访问。第二能实际拉完一个有代表性的镜像。我常用python:3.12-slim或者nginx:alpine做探针因为这两个镜像层数适中、体积不算极端如果它能全程顺畅拉完说明镜像源的数据链路是好的。只用hello-world这种单层极小镜像测试没有说服力很多源可能只缓存了热门小镜像。第三连续观察一段时间不出现三天崩一次。镜像源的可用性本身是波动的高峰时段限流、回源拥堵都常见。所以我一般会连续几天每隔一段时间真实 pull 一次而不是缓存一次结果就一劳永逸。2.2 当前实测稳定可用的镜像源一览下面这张表是这次整理后我目前还在用的地址。特别说明一下域名和服务状态会一直变化所以这份清单我标了实测时间你使用前最好也用 2.1 的方法自己探测一遍。服务商加速地址当前状态备注阿里云容器镜像服务https://你的专属ID.mirror.aliyuncs.com稳定推荐每个账号专属地址需要登录控制台获取腾讯云https://mirror.ccs.tencentyun.com可用腾讯云内网访问效果最好公网不一定快华为云SWRhttps://你的专属ID.mirror.swr.myhuaweicloud.com稳定推荐同样需要控制台看自己账号的专属地址中科大开源镜像站https://docker.mirrors.ustc.edu.cn可用教育网和公网都不错偶尔高峰期限流上海交大镜像站https://docker.mirrors.sjtug.sjtu.edu.cn可用高校源速度波动较大但值得放备选百度智能云https://mirror.baidubce.com可用百度云的公开加速地址网易http://hub-mirror.c.163.com可用注意协议是 HTTP 不是 HTTPS部分环境需要额外配置见 3.1我不建议把一张没有日期的镜像源列表永久收藏然后一直照抄因为能用的源是在持续退化的。有的镜像站调整了访问策略有的域名彻底废弃有的限流到根本不实用。这份清单最能保证稳定性的其实是阿里云和华为云这种账号维度的专属加速器其次是一线云厂商的公开地址最后才是高校公共源。公共源最大的问题是大家都在用高峰期你没得选都得排队。2.3 关于个人专属加速地址必须花两分钟搞定的事很多人看到别人贴出来的阿里云加速地址长得像这样https://qr2xxxxx.mirror.aliyuncs.com就直接复制到自己的 daemon.json 里这是最常见的一个错误。阿里云的个人加速地址跟你的账号是绑定的你用别人的专属地址能不能拉下来完全看运气。正确获取方式如下阿里云登录阿里云控制台搜索容器镜像服务 ACR进入后找到镜像工具下的镜像加速器页面会直接显示属于你这个账号的加速地址。华为云登录华为云控制台进入 SWR容器镜像服务总览在页面下方可以找到镜像加速地址同样是一串专属域名。这两个流程只需要做一次然后把地址存进自己的笔记里。专属地址的优势是限流策略通常比公共源宽松和账号绑定维护方也更容易保证稳定性。如果你拿到的是别人的公共分享地址除非来源非常明确而且自己有验证能力否则我建议不要用在生产环境。3. 从裸机 Linux 到 Docker Desktop三种配置姿势与常见坑3.1 Linux 下的 daemon.json一份能直接抄的配置Linux 上配置镜像源的标准做法是修改 Docker daemon 的配置文件。路径一般是/etc/docker/daemon.json如果文件不存在就自己创建。下面是一份完整的、可以直接抄的配置{ registry-mirrors: [ https://你的专属ID.mirror.aliyuncs.com, https://docker.mirrors.ustc.edu.cn, http://hub-mirror.c.163.com ] }注意几个细节第一registry-mirrors是一个数组可以配多个地址。Docker 客户端拉镜像时会按顺序尝试这些源第一个源不可用就自动换下一个。不过这个自动切换是有代价的每个源失败都要等一轮超时所以并不是配得越多越好。我个人建议最优数量是 2-3 个第一个放最稳定的专属源后面放一个公共源作为兜底。第二daemon.json是非常严格的 JSON 格式。不能用中文引号、不能加注释、不能有多余的逗号。之前遇到过同事把镜像源地址从网页复制过来带了一个肉眼几乎看不见的空白字符结果 Docker 服务起不来。修改完可以先执行docker info如果无法正常输出就说明配置文件有问题。第三网易这个http://hub-mirror.c.163.com是 HTTP 协议不是 HTTPS。直接写进registry-mirrors后部分 Docker 版本会报server gave HTTP response to HTTPS client的错误。如果遇到这个报错需要在 daemon.json 里把 HTTP 地址加进insecure-registries类似{ registry-mirrors: [ https://docker.mirrors.ustc.edu.cn ], insecure-registries: [ http://hub-mirror.c.163.com ] }我个人的建议是如果其他 HTTPS 源够用就不必非要上网易这个源HTTP 明文传输毕竟不理想。改完配置后执行sudo systemctl daemon-reload sudo systemctl restart docker然后验证docker info | grep -A 4 Registry Mirrors看到输出里列出了你配置的地址就算生效了。这里有一个很多人第一次不知道的事实systemctl restart docker会把这个节点上所有没有设置restart策略的容器全部停掉。如果你用docker-compose起的服务重启 Docker 后 compose 项目不会自动恢复需要重新docker compose up -d拉起。所以生产环境改镜像源建议放在维护窗口提前确认容器的restart策略避免重启后线上容器全灭。3.2 Docker Desktop图形界面、WSL2 与 Windows 容器的差异Windows 和 macOS 上大多数朋友用的是 Docker Desktop配置入口和 Linux 不一样。图形界面操作路径是打开 Docker Desktop进入 Settings设置找到 Docker Engine 选项卡在右侧 JSON 编辑区里加入registry-mirrors数组内容和 Linux 版一样点 Apply Restart。Docker Desktop 会用自己的 daemon 配置图形界面里改的 JSON 最终会写到%USERPROFILE%\.docker\daemon.jsonWindows或者~/.docker/daemon.jsonmacOS。特别提醒一个非常常见的坑如果你在 Windows 上启用了 WSL2 后端然后在 WSL 发行版里执行sudo vim /etc/docker/daemon.json这个操作是无效的。因为 WSL2 后端下实际运行的 Docker daemon 还是由 Docker Desktop 管理的正确姿势是去 Docker Desktop 的设置里改而不是在 WSL 内部改。我见过好几个朋友在这个问题上折腾了半天在 WSL 里改了配置然后 restart报错说没有 systemd 或者找不到 docker 服务最后才发现方向错了。另外 Windows 上还有一种模式是切换成 Windows 容器。这种模式下你拉的是mcr.microsoft.com的 Windows 镜像registry-mirrors里配的国内源几乎不会被命中因为镜像源主要同步的是 Docker Hub 的 Linux 镜像。所以如果你的场景是 Windows 容器镜像源列表基本帮不上忙这属于预期管理。3.3 配置成功后顺手拉一遍这些高频镜像验证配好镜像源之后我一般会用几个重量级选手来验证真实效果而不是只拉一个 hello-world。这些镜像体积大、层数多最能暴露加速链路的好坏docker pull mysql:8.0 docker pull redis:7 docker pull gitlab/gitlab-ce:latest docker pull kodbox:latest docker pull nginx:alpine如果你在准备 Dify 或者其他 AI 应用部署强烈建议也拉一遍 Dify 的镜像组合。Dify 的镜像数量多、体积不小加速前经常拉一半就超时加速后基本一路通畅。同理还有青龙面板、Hadoop 镜像这类多阶段 multi-stage 构建出来的大镜像都是很好的试金石。实测的体感大概是这样的一个 200MB 左右的镜像不加速时运气好可能 5-10 分钟运气差直接失败加上好用的加速源后通常 1-2 分钟拉完。几 GB 的大镜像比如gitlab/gitlab-ce加速前后的差距更明显能差出一个数量级。3.4 认准事实Docker 没有命令行临时镜像源参数社区里经常有人问能不能在执行docker pull的时候顺手带一个镜像源参数比如docker pull --registry-mirror https://xxx nginx:latest我先直接把结论说出来docker pull本身没有这个参数。镜像源是 daemon 级别的全局配置你改了/etc/docker/daemon.json之后需要重启 Docker 才生效不存在命令行临时覆盖的说法。有一个看起来像临时指定的写法是直接用镜像源的完整地址去拉docker pull docker.mirrors.ustc.edu.cn/library/nginx:latest这种写法确实能从指定 registry 拉取但它不符合registry-mirrors的回退机制而且拉完后镜像的 tag 会变成docker.mirrors.ustc.edu.cn/library/nginx:latest如果你需要恢复成nginx:latest还得手动再docker tag一次。日常运维不推荐这么搞只适合偶尔做源可用性测试。4. 镜像源失效排查完整链路从报错到换源一步步来4.1 高频报错先对号入座镜像源的问题报错五花八门但高频的其实就那么几种。先把症状和可能的根因对上号错误特征大概率原因下一步动作i/o timeout链路不通、镜像源出口限流或宕机换备用源并探测镜像源接口EOF连接被重置或源不支持 HTTPS 而你配了 HTTPS检查协议和 TLS 配置server gave HTTP response to HTTPS client源是 HTTP 但 daemon 只允许 HTTPS加insecure-registries或换 HTTPS 源manifest unknown/404该源没有同步某个镜像或镜像本身是私有命名空间换官方镜像测试确认源覆盖范围no such host镜像源域名解析不了基本等于域名失效从列表中剔除换新源server misbehaving镜像源过载或主动拒绝稍后重试换源我自己的习惯是只要连续遇到两次来源明确的连接层错误就直接换源不要在同一个源上反复折腾。多数公共镜像源没有 SLA 承诺坏半天甚至坏一天都有可能。4.2 一条命令链定位源到底还在不在先确认你现在实际生效的镜像源配置docker info | grep -A 5 Registry Mirrors这一步能排除我改了配置但没重启这种尴尬情况。如果你在/etc/docker/daemon.json里改了东西但docker info里的Registry Mirrors还是旧的那说明 daemon 没加载到新配置优先检查文件路径、JSON 格式和重启动作。然后直接探测镜像源接口curl -sS -o /dev/null -w %{http_code}\n --connect-timeout 5 https://docker.mirrors.ustc.edu.cn/v2/返回200正常响应返回401也正常说明服务在只是需要认证对于 mirror 用途不影响返回000连不上返回503服务过载或者拒绝服务。再进一步你可以请求一个具体镜像的 manifest验证它是否真的缓存了某个镜像curl -sS https://docker.mirrors.ustc.edu.cn/v2/library/nginx/manifests/latest \ -H Accept: application/vnd.docker.distribution.manifest.v2json | head -n 1如果返回一长串 JSON说明源不仅能连上而且对nginx:latest有缓存或者能正常回源。如果返回 404说明这个源没有同步这个镜像这时候换别的源再测一次。这条链路能让你快速区分是 Docker 客户端问题还是镜像源问题而不是傻傻地一遍遍重试。4.3 即使清单一尘不染也可能变慢峰值限流与跨地域链路有时候你配置没问题镜像源探测也正常但docker pull就是慢。这种慢场景常见诱因有三个第一公共源高峰期限流。晚上 8 点到 11 点是很多人拉镜像的高峰尤其是高校公共源带宽就那么宽大家都在抢。实测中午拉一个大镜像可能 1 分钟晚上同样的镜像可能要 10 分钟。这不是你配置出了问题是拥堵。第二跨网链路。你用的是电信宽带镜像源跑到联通或者移动机房跨网时延和丢包都会明显增加。云厂商的专属加速器在这种场景下优势更明显因为它们在三大运营商骨干网都有接入点。第三冷门镜像回源慢。镜像源本地没有缓存的时候需要先回源到 Docker Hub 拉一次再转给你。这个回源过程取决于镜像源自身的海外链路通常比缓存热门镜像慢得多。所以拉冷门镜像时慢不一定代表源不可用可能就是第一次拉取。应对办法比较简单粗暴错峰拉取、换信源、或者先在备用源那边确认有没有缓存。我见过有人写脚本监控镜像源可用性这个思路放到第 6 章细说。4.4 源全挂的兜底方案导出导入与自建私有仓库如果某一天你手里的所有镜像源都不可用别急着在 daemon 配置里反复横跳。这种全挂的极端情况我更推荐从这些路径应急方案 A手工导出再导入。在另一台网络状态较好的机器上执行docker pull然后docker save nginx:latest -o nginx.tar把 tar 包传到目标机器再docker load -i nginx.tar这种方式不依赖目标机器到 Docker Hub 的链路只依赖两台机器之间能不能传文件。适合单机应急不适合团队大规模使用。方案 B自建私有仓库分发给团队。在一台网络连接良好的服务器上部署 Registry 或者 Harbor让团队成员的 daemon 都配置到这台内网仓库地址。内网仓库可以从可用镜像源同步然后统一分发。这是最治本的方式但前期投入明显更大。5. 同一套思路复制到整个开发环境Ollama、npm、HuggingFace 与 Conda5.1 换个视角所有拉不下来的问题都是 registry 指向问题摸透了 Docker 镜像源的原理后你会发现它本质上是把客户端默认访问一个海外仓库改成访问一个大陆可达的同步仓库。这个思路几乎可以平移到所有依赖远程仓库的生态里。Docker 的仓库概念是 Registrynpm 的仓库概念是 registryPython 的 pip 有 index-urlConda 有 channelHuggingFace 有 HF_ENDPOINTOllama 模型下载有自己的模型仓库地址。每个生态都有默认的上游也都有社区或者云厂商维护的大陆加速通道。你不需要理解每个生态复杂的内在机制只需要知道把默认上游指到大陆可达的源这一件事就够了。5.2 各生态配置速查表这里整理一份速查表都是我用过且目前有效的常用配置。注意新工具版本更新很快具体变量名建议以官方最新文档为准。生态默认上游常用大陆可达替代配置方式Dockerdocker.io第 2 章清单里的镜像源daemon.json 的 registry-mirrorsnpmregistry.npmjs.orghttps://registry.npmmirror.comnpm config set registry https://registry.npmmirror.compippypi.org清华 PyPI / 阿里云 PyPIpip config set global.index-url https://pypi.tuna.tsinghua.edu.cn/simpleCondarepo.anaconda.com清华 Anaconda 镜像修改.condarc里的 channelsHuggingFacehuggingface.co社区公开镜像常见为https://hf-mirror.com设置环境变量HF_ENDPOINThttps://hf-mirror.comOllamaregistry.ollama.ai通过 ModelScope 等平台下载模型后本地导入设置模型目录或用模型平台下载后ollama createComfyUI模型托管在 HuggingFace / Civitai 等先用国内可达平台下载模型文件模型文件放入models对应目录即可这些条目的配置方式各有差异但核心理念完全一致默认源在大陆访问不理想就替换成同步镜像。你在 Docker 上积累的先验证源、再配置、再拉取测试的习惯完全可以平移到这些生态。5.3 加速配置后的效果验证别只看命令有没有报错配置完镜像源之后很多人执行一遍发现没报错就认为成功了。我的建议是再进一步验证确认实际速度真的提高了。比如 npm配置完后执行npm ping看 ping 返回的耗时。再随便npm install一个小包观察下载速度而不是只看命令行有没有红字。pip 也一样真正pip install一个大包观察进度条的速度和稳定性。HuggingFace 这边如果你是做模型下载直接跑一个脚本下载一个几百 MB 的模型文件感受传输速度。Docker 则用我前面提到的 MySQL 8.0 或者 GitLab 这种大镜像。只有真实拉取体验明显改变了这个配置才算生效。ComfyUI 是一个很典型的例子它本身没有ComfyUI 镜像源这种概念但国内装 ComfyUI 之后真正卡住的往往是模型下载。模型托管在 HuggingFace 上时用国内可达的模型平台或者 HF 镜像先把模型文件下回来再放到models/checkpoints或者models/loras目录里效果比在 ComfyUI 界面里等进度条要靠谱得多。6. 把镜像源当基础设施维护我的长期更新策略6.1 配置与使用中的几个反直觉细节这几年维护镜像源配置有几条经验是不踩坑根本不会知道的。第一镜像源不是配得越多越好。很多人以为 registry-mirrors 数组越长越保险实际上 Docker 遇到第一个源失败时会先等待超时然后再按顺序试下一个。如果你配了 4-5 个其中两个失效源排在前面每次拉镜像都要白白等几十秒才轮到后面的可用源体验反而更差。我的经验是保留 2-3 个高质量源第一个放你账号的专属加速地址第二个放一个公共源第三个做为最后的备选。如果发现某个源连续一周不可用就从列表里删掉不要恋战。第二mirror 是只读的不能 push。镜像加速器本质是拉取加速它不是一个你可以在上面上传自定义镜像的仓库。很多人误以为配置了 mirror 就可以docker push到镜像源这是做不到的。如果你需要一个内部团队共享镜像的仓库老老实实部署 Registry 或者 Harbor镜像源只负责日常拉取加速。第三公共源没有 SLA生产环境不能裸奔。高校公共源和云厂商公开源都是尽力而为的免费服务它们可能因为维护、扩容、限流策略调整而随时变化。如果你在跑生产环境我建议至少要保证本地区有一台能通过其他方式拉取镜像的备用机器或者干脆自建一套私有分发仓库不要把所有鸡蛋放在公共源一个篮子里。6.2 定期自检一个最小化可用脚本因为我维护多台服务器不可能每天都手动去 curl 每一个镜像源所以我写了一个很简单的探测脚本扔在 crontab 里每周跑一次。脚本内容不复杂你也完全可以自己维护一份#!/bin/bash # 镜像源探测脚本可用于 crontab 定期执行 for url in \ https://你的专属ID.mirror.aliyuncs.com \ https://docker.mirrors.ustc.edu.cn \ https://docker.mirrors.sjtug.sjtu.edu.cn \ https://hub-mirror.c.163.com; do code$(curl -sS -o /dev/null -w %{http_code} --connect-timeout 5 $url/v2/ 2/dev/null || echo 000) echo $(date %Y-%m-%d %H:%M:%S) $url - $code done把脚本保存为check_mirror.sh然后加到 crontab0 6 * * 1 /opt/scripts/check_mirror.sh /var/log/mirror-check.log 21每周一早上一看日志哪些源返回000、哪些返回503就一目了然。如果主源连续三周探测都不正常就该考虑调整 daemon 配置了。这个方法成本极低但对长期维护一份加速列表来说非常值得。6.3 下一步的进阶玩法自建 Registry 做内部分发如果你维护的不止三五台机器而是二三十台甚至更多公共镜像源其实不是最优解。更可靠的做法是内网自建一个 Registry让公共源变成上游内网仓库从上游同步镜像所有业务节点只需从内网拉取。用官方 Registry 镜像的话关键配置就是打开 mirror 回源模式设置环境变量REGISTRY_PROXY_REMOTEURLhttps://docker.mirrors.ustc.edu.cn然后业务机器的 daemon.json 里把registry-mirrors指到你这个内网仓库地址。这样团队内部所有镜像流量都在内网不会再被公共源限流或者公共源下线影响。Harbor 项目则在界面上直接支持配置代理缓存类型仓库操作起来更快适合团队里不熟悉命令行的同事使用。自建仓库的代价是你要多维护一套服务但换来的是可控性和稳定性的巨大提升。如果业务对 Docker 依赖度高这笔投入是值得的。这几年我最大的体会是镜像源列表更像基础设施维护手册而不是一份一劳永逸的收藏清单。你每天可能压根感觉不到它的存在但一旦失效整个 CI、部署、测试链路都能立刻停下。所以与其到处找最新可用列表不如花半个小时把探测脚本和备用方案搭起来以后镜像源再出问题你手里就永远有牌可打。
2026实测：Docker镜像加速源可用清单与配置避坑全攻略
我平时最怕听到的一句话就是某个同事在群里喊docker pull 又卡住了。不是卡一两次是今天拉不下来、明天超时偶尔还给你返回一个i/o timeout然后整个 CI 都堵住。这几年我养成了一个习惯每隔一段时间就把 Docker 国内镜像源的可用列表翻出来重新验证一遍因为镜像源这东西太不稳定了去年还能用的地址今年可能就变成了no such host。正好今天是 9 月 9 日我把 2026 年目前实测还能稳定工作的加速源整理成一份新清单同时把配置方法、失效排查、以及一批容易踩的坑一起写出来。这篇文章适合刚装好 Docker、Docker Desktop正准备拉 MySQL 8.0、Redis、GitLab、Dify、青龙这些常用镜像但发现速度感人甚至直接失败的朋友参考。1. docker pull 卡在 Downloading 的原因比网速更复杂1.1 一次典型的拉取超时现场先把场景还原一下。你执行了docker pull mysql:8.0输出先是Pulling fs layer然后开始显示Downloading百分比停在某个数字不动过了几十秒直接给你一句failed to resolve source metadata for docker.io/library/mysql:8.0: failed to do request: Head https://registry-1.docker.io/v2/library/mysql/manifests/8.0: i/o timeout或者更常见的是error pulling image configuration: Get https://production.cloudflare.docker.com/...: EOF看完这两条报错你基本就能定位问题不在你本地磁盘也不在 Docker 版本而是 Docker 客户端跟 Docker Hub 之间的网络链路出了问题。我用同一份配置测试过超时和正常拉取的体感差距非常离谱——一个 20MB 的小镜像层不配加速源时可能卡十几分钟配完加速源之后同样的层三五秒就下来了。这种差距不是优化出来的是通路本身换了。1.2 Docker Hub、CDN 和镜像加速器之间的真实关系要说清楚为什么换一个 registry 地址就能提速得先明白 docker pull 背后发生了什么。平时我们直接执行docker pull nginx:latestDocker 客户端其实会按顺序做这么几件事向registry-1.docker.io请求一个认证 token拿 token 请求镜像的 manifest 元数据拿到这个镜像由哪些 layer层组成根据 manifest 里每个层文件的 SHA256 地址去一个 CDN 域名下并行下载 blob 数据全部下载完成后解包、合并、写入本地镜像存储。前两步的域名是docker.io第三步的真正数据下载域名解析之后大多指向海外 CDN。大陆访问 Docker Hub 时这几条路径经常出现高延迟、丢包和连接重置。所以哪怕你家里是千兆宽带该卡还是卡。镜像加速器做的事并不神秘你在 Docker daemon 的配置里声明一个registry-mirrors列表客户端拉镜像时会优先向这些 mirror 地址请求 manifest 和 blob。这些 mirror 服务由国内云厂商或者高校开源镜像站维护它们本身会定期回源同步 Docker Hub 上的热门镜像。如果 mirror 本地没有缓存它会先回源到 Docker Hub 拉一份再返回给你。用个生活化一点的说法不加速等于每次都得跨洋去海外仓库提货加了镜像源相当于在你所在城市设了一个中转仓第一次可能因为中转仓自身也要去海外补货所以慢一点但补完货之后再有人来提就完全不用跨洋了。这也解释了为什么有些冷门镜像第一次通过镜像源拉取还是偏慢——源头没有缓存中转仓要先帮你跑一趟。1.3 先浇一盆冷水镜像源不是网速放大器很多人换完镜像源后发现还是慢于是觉得镜像源没用。这其实是期望错了。镜像源只解决镜像层数据从 Docker Hub 回传到大陆的链路问题它不解决以下这些场景容器启动之后容器内执行apt install、pip install、npm install下载慢不归镜像源管你家或者公司的出口带宽本身只有 1Mbps那怎么加速都白搭镜像源服务商跟你的运营商之间的跨网链路拥堵比如你电信访问一个联通机房的镜像站高峰期依然可能不稳。所以正确的预期是镜像源能让从 Docker Hub 拉容器镜像这件事从不可用变成可用再从可用变成体感不错。但你不能指望它包治百病。2. 9月9日实测存活清单2026年值得优先用的国内镜像加速2.1 我判断能用的三个标准每次整理这种清单我都要先定义一下什么叫能用。不是 ping 得通就算能用我一般按三个标准来筛第一Registry 接口真实可达。直接用curl -sS -o /dev/null -w %{http_code} https://镜像源地址/v2/探测返回200或者401都行因为很多 registry 未认证时会返回 401这至少说明服务在线并正常响应了 registry 协议。如果返回000、503、403基本可以判定不可用或者拒绝访问。第二能实际拉完一个有代表性的镜像。我常用python:3.12-slim或者nginx:alpine做探针因为这两个镜像层数适中、体积不算极端如果它能全程顺畅拉完说明镜像源的数据链路是好的。只用hello-world这种单层极小镜像测试没有说服力很多源可能只缓存了热门小镜像。第三连续观察一段时间不出现三天崩一次。镜像源的可用性本身是波动的高峰时段限流、回源拥堵都常见。所以我一般会连续几天每隔一段时间真实 pull 一次而不是缓存一次结果就一劳永逸。2.2 当前实测稳定可用的镜像源一览下面这张表是这次整理后我目前还在用的地址。特别说明一下域名和服务状态会一直变化所以这份清单我标了实测时间你使用前最好也用 2.1 的方法自己探测一遍。服务商加速地址当前状态备注阿里云容器镜像服务https://你的专属ID.mirror.aliyuncs.com稳定推荐每个账号专属地址需要登录控制台获取腾讯云https://mirror.ccs.tencentyun.com可用腾讯云内网访问效果最好公网不一定快华为云SWRhttps://你的专属ID.mirror.swr.myhuaweicloud.com稳定推荐同样需要控制台看自己账号的专属地址中科大开源镜像站https://docker.mirrors.ustc.edu.cn可用教育网和公网都不错偶尔高峰期限流上海交大镜像站https://docker.mirrors.sjtug.sjtu.edu.cn可用高校源速度波动较大但值得放备选百度智能云https://mirror.baidubce.com可用百度云的公开加速地址网易http://hub-mirror.c.163.com可用注意协议是 HTTP 不是 HTTPS部分环境需要额外配置见 3.1我不建议把一张没有日期的镜像源列表永久收藏然后一直照抄因为能用的源是在持续退化的。有的镜像站调整了访问策略有的域名彻底废弃有的限流到根本不实用。这份清单最能保证稳定性的其实是阿里云和华为云这种账号维度的专属加速器其次是一线云厂商的公开地址最后才是高校公共源。公共源最大的问题是大家都在用高峰期你没得选都得排队。2.3 关于个人专属加速地址必须花两分钟搞定的事很多人看到别人贴出来的阿里云加速地址长得像这样https://qr2xxxxx.mirror.aliyuncs.com就直接复制到自己的 daemon.json 里这是最常见的一个错误。阿里云的个人加速地址跟你的账号是绑定的你用别人的专属地址能不能拉下来完全看运气。正确获取方式如下阿里云登录阿里云控制台搜索容器镜像服务 ACR进入后找到镜像工具下的镜像加速器页面会直接显示属于你这个账号的加速地址。华为云登录华为云控制台进入 SWR容器镜像服务总览在页面下方可以找到镜像加速地址同样是一串专属域名。这两个流程只需要做一次然后把地址存进自己的笔记里。专属地址的优势是限流策略通常比公共源宽松和账号绑定维护方也更容易保证稳定性。如果你拿到的是别人的公共分享地址除非来源非常明确而且自己有验证能力否则我建议不要用在生产环境。3. 从裸机 Linux 到 Docker Desktop三种配置姿势与常见坑3.1 Linux 下的 daemon.json一份能直接抄的配置Linux 上配置镜像源的标准做法是修改 Docker daemon 的配置文件。路径一般是/etc/docker/daemon.json如果文件不存在就自己创建。下面是一份完整的、可以直接抄的配置{ registry-mirrors: [ https://你的专属ID.mirror.aliyuncs.com, https://docker.mirrors.ustc.edu.cn, http://hub-mirror.c.163.com ] }注意几个细节第一registry-mirrors是一个数组可以配多个地址。Docker 客户端拉镜像时会按顺序尝试这些源第一个源不可用就自动换下一个。不过这个自动切换是有代价的每个源失败都要等一轮超时所以并不是配得越多越好。我个人建议最优数量是 2-3 个第一个放最稳定的专属源后面放一个公共源作为兜底。第二daemon.json是非常严格的 JSON 格式。不能用中文引号、不能加注释、不能有多余的逗号。之前遇到过同事把镜像源地址从网页复制过来带了一个肉眼几乎看不见的空白字符结果 Docker 服务起不来。修改完可以先执行docker info如果无法正常输出就说明配置文件有问题。第三网易这个http://hub-mirror.c.163.com是 HTTP 协议不是 HTTPS。直接写进registry-mirrors后部分 Docker 版本会报server gave HTTP response to HTTPS client的错误。如果遇到这个报错需要在 daemon.json 里把 HTTP 地址加进insecure-registries类似{ registry-mirrors: [ https://docker.mirrors.ustc.edu.cn ], insecure-registries: [ http://hub-mirror.c.163.com ] }我个人的建议是如果其他 HTTPS 源够用就不必非要上网易这个源HTTP 明文传输毕竟不理想。改完配置后执行sudo systemctl daemon-reload sudo systemctl restart docker然后验证docker info | grep -A 4 Registry Mirrors看到输出里列出了你配置的地址就算生效了。这里有一个很多人第一次不知道的事实systemctl restart docker会把这个节点上所有没有设置restart策略的容器全部停掉。如果你用docker-compose起的服务重启 Docker 后 compose 项目不会自动恢复需要重新docker compose up -d拉起。所以生产环境改镜像源建议放在维护窗口提前确认容器的restart策略避免重启后线上容器全灭。3.2 Docker Desktop图形界面、WSL2 与 Windows 容器的差异Windows 和 macOS 上大多数朋友用的是 Docker Desktop配置入口和 Linux 不一样。图形界面操作路径是打开 Docker Desktop进入 Settings设置找到 Docker Engine 选项卡在右侧 JSON 编辑区里加入registry-mirrors数组内容和 Linux 版一样点 Apply Restart。Docker Desktop 会用自己的 daemon 配置图形界面里改的 JSON 最终会写到%USERPROFILE%\.docker\daemon.jsonWindows或者~/.docker/daemon.jsonmacOS。特别提醒一个非常常见的坑如果你在 Windows 上启用了 WSL2 后端然后在 WSL 发行版里执行sudo vim /etc/docker/daemon.json这个操作是无效的。因为 WSL2 后端下实际运行的 Docker daemon 还是由 Docker Desktop 管理的正确姿势是去 Docker Desktop 的设置里改而不是在 WSL 内部改。我见过好几个朋友在这个问题上折腾了半天在 WSL 里改了配置然后 restart报错说没有 systemd 或者找不到 docker 服务最后才发现方向错了。另外 Windows 上还有一种模式是切换成 Windows 容器。这种模式下你拉的是mcr.microsoft.com的 Windows 镜像registry-mirrors里配的国内源几乎不会被命中因为镜像源主要同步的是 Docker Hub 的 Linux 镜像。所以如果你的场景是 Windows 容器镜像源列表基本帮不上忙这属于预期管理。3.3 配置成功后顺手拉一遍这些高频镜像验证配好镜像源之后我一般会用几个重量级选手来验证真实效果而不是只拉一个 hello-world。这些镜像体积大、层数多最能暴露加速链路的好坏docker pull mysql:8.0 docker pull redis:7 docker pull gitlab/gitlab-ce:latest docker pull kodbox:latest docker pull nginx:alpine如果你在准备 Dify 或者其他 AI 应用部署强烈建议也拉一遍 Dify 的镜像组合。Dify 的镜像数量多、体积不小加速前经常拉一半就超时加速后基本一路通畅。同理还有青龙面板、Hadoop 镜像这类多阶段 multi-stage 构建出来的大镜像都是很好的试金石。实测的体感大概是这样的一个 200MB 左右的镜像不加速时运气好可能 5-10 分钟运气差直接失败加上好用的加速源后通常 1-2 分钟拉完。几 GB 的大镜像比如gitlab/gitlab-ce加速前后的差距更明显能差出一个数量级。3.4 认准事实Docker 没有命令行临时镜像源参数社区里经常有人问能不能在执行docker pull的时候顺手带一个镜像源参数比如docker pull --registry-mirror https://xxx nginx:latest我先直接把结论说出来docker pull本身没有这个参数。镜像源是 daemon 级别的全局配置你改了/etc/docker/daemon.json之后需要重启 Docker 才生效不存在命令行临时覆盖的说法。有一个看起来像临时指定的写法是直接用镜像源的完整地址去拉docker pull docker.mirrors.ustc.edu.cn/library/nginx:latest这种写法确实能从指定 registry 拉取但它不符合registry-mirrors的回退机制而且拉完后镜像的 tag 会变成docker.mirrors.ustc.edu.cn/library/nginx:latest如果你需要恢复成nginx:latest还得手动再docker tag一次。日常运维不推荐这么搞只适合偶尔做源可用性测试。4. 镜像源失效排查完整链路从报错到换源一步步来4.1 高频报错先对号入座镜像源的问题报错五花八门但高频的其实就那么几种。先把症状和可能的根因对上号错误特征大概率原因下一步动作i/o timeout链路不通、镜像源出口限流或宕机换备用源并探测镜像源接口EOF连接被重置或源不支持 HTTPS 而你配了 HTTPS检查协议和 TLS 配置server gave HTTP response to HTTPS client源是 HTTP 但 daemon 只允许 HTTPS加insecure-registries或换 HTTPS 源manifest unknown/404该源没有同步某个镜像或镜像本身是私有命名空间换官方镜像测试确认源覆盖范围no such host镜像源域名解析不了基本等于域名失效从列表中剔除换新源server misbehaving镜像源过载或主动拒绝稍后重试换源我自己的习惯是只要连续遇到两次来源明确的连接层错误就直接换源不要在同一个源上反复折腾。多数公共镜像源没有 SLA 承诺坏半天甚至坏一天都有可能。4.2 一条命令链定位源到底还在不在先确认你现在实际生效的镜像源配置docker info | grep -A 5 Registry Mirrors这一步能排除我改了配置但没重启这种尴尬情况。如果你在/etc/docker/daemon.json里改了东西但docker info里的Registry Mirrors还是旧的那说明 daemon 没加载到新配置优先检查文件路径、JSON 格式和重启动作。然后直接探测镜像源接口curl -sS -o /dev/null -w %{http_code}\n --connect-timeout 5 https://docker.mirrors.ustc.edu.cn/v2/返回200正常响应返回401也正常说明服务在只是需要认证对于 mirror 用途不影响返回000连不上返回503服务过载或者拒绝服务。再进一步你可以请求一个具体镜像的 manifest验证它是否真的缓存了某个镜像curl -sS https://docker.mirrors.ustc.edu.cn/v2/library/nginx/manifests/latest \ -H Accept: application/vnd.docker.distribution.manifest.v2json | head -n 1如果返回一长串 JSON说明源不仅能连上而且对nginx:latest有缓存或者能正常回源。如果返回 404说明这个源没有同步这个镜像这时候换别的源再测一次。这条链路能让你快速区分是 Docker 客户端问题还是镜像源问题而不是傻傻地一遍遍重试。4.3 即使清单一尘不染也可能变慢峰值限流与跨地域链路有时候你配置没问题镜像源探测也正常但docker pull就是慢。这种慢场景常见诱因有三个第一公共源高峰期限流。晚上 8 点到 11 点是很多人拉镜像的高峰尤其是高校公共源带宽就那么宽大家都在抢。实测中午拉一个大镜像可能 1 分钟晚上同样的镜像可能要 10 分钟。这不是你配置出了问题是拥堵。第二跨网链路。你用的是电信宽带镜像源跑到联通或者移动机房跨网时延和丢包都会明显增加。云厂商的专属加速器在这种场景下优势更明显因为它们在三大运营商骨干网都有接入点。第三冷门镜像回源慢。镜像源本地没有缓存的时候需要先回源到 Docker Hub 拉一次再转给你。这个回源过程取决于镜像源自身的海外链路通常比缓存热门镜像慢得多。所以拉冷门镜像时慢不一定代表源不可用可能就是第一次拉取。应对办法比较简单粗暴错峰拉取、换信源、或者先在备用源那边确认有没有缓存。我见过有人写脚本监控镜像源可用性这个思路放到第 6 章细说。4.4 源全挂的兜底方案导出导入与自建私有仓库如果某一天你手里的所有镜像源都不可用别急着在 daemon 配置里反复横跳。这种全挂的极端情况我更推荐从这些路径应急方案 A手工导出再导入。在另一台网络状态较好的机器上执行docker pull然后docker save nginx:latest -o nginx.tar把 tar 包传到目标机器再docker load -i nginx.tar这种方式不依赖目标机器到 Docker Hub 的链路只依赖两台机器之间能不能传文件。适合单机应急不适合团队大规模使用。方案 B自建私有仓库分发给团队。在一台网络连接良好的服务器上部署 Registry 或者 Harbor让团队成员的 daemon 都配置到这台内网仓库地址。内网仓库可以从可用镜像源同步然后统一分发。这是最治本的方式但前期投入明显更大。5. 同一套思路复制到整个开发环境Ollama、npm、HuggingFace 与 Conda5.1 换个视角所有拉不下来的问题都是 registry 指向问题摸透了 Docker 镜像源的原理后你会发现它本质上是把客户端默认访问一个海外仓库改成访问一个大陆可达的同步仓库。这个思路几乎可以平移到所有依赖远程仓库的生态里。Docker 的仓库概念是 Registrynpm 的仓库概念是 registryPython 的 pip 有 index-urlConda 有 channelHuggingFace 有 HF_ENDPOINTOllama 模型下载有自己的模型仓库地址。每个生态都有默认的上游也都有社区或者云厂商维护的大陆加速通道。你不需要理解每个生态复杂的内在机制只需要知道把默认上游指到大陆可达的源这一件事就够了。5.2 各生态配置速查表这里整理一份速查表都是我用过且目前有效的常用配置。注意新工具版本更新很快具体变量名建议以官方最新文档为准。生态默认上游常用大陆可达替代配置方式Dockerdocker.io第 2 章清单里的镜像源daemon.json 的 registry-mirrorsnpmregistry.npmjs.orghttps://registry.npmmirror.comnpm config set registry https://registry.npmmirror.compippypi.org清华 PyPI / 阿里云 PyPIpip config set global.index-url https://pypi.tuna.tsinghua.edu.cn/simpleCondarepo.anaconda.com清华 Anaconda 镜像修改.condarc里的 channelsHuggingFacehuggingface.co社区公开镜像常见为https://hf-mirror.com设置环境变量HF_ENDPOINThttps://hf-mirror.comOllamaregistry.ollama.ai通过 ModelScope 等平台下载模型后本地导入设置模型目录或用模型平台下载后ollama createComfyUI模型托管在 HuggingFace / Civitai 等先用国内可达平台下载模型文件模型文件放入models对应目录即可这些条目的配置方式各有差异但核心理念完全一致默认源在大陆访问不理想就替换成同步镜像。你在 Docker 上积累的先验证源、再配置、再拉取测试的习惯完全可以平移到这些生态。5.3 加速配置后的效果验证别只看命令有没有报错配置完镜像源之后很多人执行一遍发现没报错就认为成功了。我的建议是再进一步验证确认实际速度真的提高了。比如 npm配置完后执行npm ping看 ping 返回的耗时。再随便npm install一个小包观察下载速度而不是只看命令行有没有红字。pip 也一样真正pip install一个大包观察进度条的速度和稳定性。HuggingFace 这边如果你是做模型下载直接跑一个脚本下载一个几百 MB 的模型文件感受传输速度。Docker 则用我前面提到的 MySQL 8.0 或者 GitLab 这种大镜像。只有真实拉取体验明显改变了这个配置才算生效。ComfyUI 是一个很典型的例子它本身没有ComfyUI 镜像源这种概念但国内装 ComfyUI 之后真正卡住的往往是模型下载。模型托管在 HuggingFace 上时用国内可达的模型平台或者 HF 镜像先把模型文件下回来再放到models/checkpoints或者models/loras目录里效果比在 ComfyUI 界面里等进度条要靠谱得多。6. 把镜像源当基础设施维护我的长期更新策略6.1 配置与使用中的几个反直觉细节这几年维护镜像源配置有几条经验是不踩坑根本不会知道的。第一镜像源不是配得越多越好。很多人以为 registry-mirrors 数组越长越保险实际上 Docker 遇到第一个源失败时会先等待超时然后再按顺序试下一个。如果你配了 4-5 个其中两个失效源排在前面每次拉镜像都要白白等几十秒才轮到后面的可用源体验反而更差。我的经验是保留 2-3 个高质量源第一个放你账号的专属加速地址第二个放一个公共源第三个做为最后的备选。如果发现某个源连续一周不可用就从列表里删掉不要恋战。第二mirror 是只读的不能 push。镜像加速器本质是拉取加速它不是一个你可以在上面上传自定义镜像的仓库。很多人误以为配置了 mirror 就可以docker push到镜像源这是做不到的。如果你需要一个内部团队共享镜像的仓库老老实实部署 Registry 或者 Harbor镜像源只负责日常拉取加速。第三公共源没有 SLA生产环境不能裸奔。高校公共源和云厂商公开源都是尽力而为的免费服务它们可能因为维护、扩容、限流策略调整而随时变化。如果你在跑生产环境我建议至少要保证本地区有一台能通过其他方式拉取镜像的备用机器或者干脆自建一套私有分发仓库不要把所有鸡蛋放在公共源一个篮子里。6.2 定期自检一个最小化可用脚本因为我维护多台服务器不可能每天都手动去 curl 每一个镜像源所以我写了一个很简单的探测脚本扔在 crontab 里每周跑一次。脚本内容不复杂你也完全可以自己维护一份#!/bin/bash # 镜像源探测脚本可用于 crontab 定期执行 for url in \ https://你的专属ID.mirror.aliyuncs.com \ https://docker.mirrors.ustc.edu.cn \ https://docker.mirrors.sjtug.sjtu.edu.cn \ https://hub-mirror.c.163.com; do code$(curl -sS -o /dev/null -w %{http_code} --connect-timeout 5 $url/v2/ 2/dev/null || echo 000) echo $(date %Y-%m-%d %H:%M:%S) $url - $code done把脚本保存为check_mirror.sh然后加到 crontab0 6 * * 1 /opt/scripts/check_mirror.sh /var/log/mirror-check.log 21每周一早上一看日志哪些源返回000、哪些返回503就一目了然。如果主源连续三周探测都不正常就该考虑调整 daemon 配置了。这个方法成本极低但对长期维护一份加速列表来说非常值得。6.3 下一步的进阶玩法自建 Registry 做内部分发如果你维护的不止三五台机器而是二三十台甚至更多公共镜像源其实不是最优解。更可靠的做法是内网自建一个 Registry让公共源变成上游内网仓库从上游同步镜像所有业务节点只需从内网拉取。用官方 Registry 镜像的话关键配置就是打开 mirror 回源模式设置环境变量REGISTRY_PROXY_REMOTEURLhttps://docker.mirrors.ustc.edu.cn然后业务机器的 daemon.json 里把registry-mirrors指到你这个内网仓库地址。这样团队内部所有镜像流量都在内网不会再被公共源限流或者公共源下线影响。Harbor 项目则在界面上直接支持配置代理缓存类型仓库操作起来更快适合团队里不熟悉命令行的同事使用。自建仓库的代价是你要多维护一套服务但换来的是可控性和稳定性的巨大提升。如果业务对 Docker 依赖度高这笔投入是值得的。这几年我最大的体会是镜像源列表更像基础设施维护手册而不是一份一劳永逸的收藏清单。你每天可能压根感觉不到它的存在但一旦失效整个 CI、部署、测试链路都能立刻停下。所以与其到处找最新可用列表不如花半个小时把探测脚本和备用方案搭起来以后镜像源再出问题你手里就永远有牌可打。
