帮朋友排查Docker环境问题时发现一个特别典型的现状网上搜到的镜像源配置教程大部分还停留在两三年之前列出来的地址要么已经失效要么被限流到没法用最后拉一个最基础的系统镜像都得看运气。这篇文章我打算把2026年初这个时间点上国内网络环境下实际能用的Docker镜像源、加速器配置方式完整梳理一遍再附上我自己常用的测速方法帮你判断到底哪个源值得放进配置里。不管你是刚装好Docker Desktop的新手还是被内网拉镜像折磨的运维都可以直接照着操作。1. 先搞清楚镜像源加速到底在加速什么1.1 一个docker pull命令慢在哪很多人在第一次接触镜像加速时下意识以为Docker镜像就是一个大文件拉取慢纯粹是文件大。其实不对。Docker镜像拉取走的是HTTPS连接整个流程大致分三步请求Docker Hub的认证服务和manifest接口拿到镜像的元数据。根据元数据里的layer列表逐个发起blob下载请求。把各个layer完整下载后解压、合并成可运行的容器文件系统。这三个环节里第二步下载layer占了大头。一个稍微完整点的镜像比如MySQL 8.0解压后可能有好几百MB网络快慢直接决定了你要等10秒还是等10分钟。而第一步的manifest请求虽然数据量不大但如果到Docker Hub的链路本身就超时、断连那连启动拉取都做不到。你如果遇到docker pull卡在Waiting或者反复出现TLS handshake timeout绝大多数情况就是Docker Hub在国内网络环境下访问不稳定。这不是你机器的问题也不是Docker安装出了问题纯粹是链路质量不行。1.2 镜像加速器的本质一个代理加缓存Docker官方从1.13版本开始就支持配置registry-mirrors也就是镜像加速器。它做的事情听起来很简单当你配置了一个加速器地址后Docker拉镜像时不会直接访问registry-1.docker.io而是先请求你配置的这个加速器服务。加速器服务拿到请求后会做两件事把Docker Hub上的manifest和layer拉取下来。在本地做一层缓存下次其他人请求同一个镜像时直接从缓存返回。所以镜像加速器本质上是一个“代理加缓存”的角色。你配了它拉镜像的终端连接从“你的机器到Docker Hub”变成了“你的机器到加速器”只要后半段链路质量好速度就能明显提升。这个机制也解释了为什么会有“冷热镜像”的概念越多人用的热门镜像加速器缓存里越可能有现成文件拉取速度越快冷门镜像第一次拉取时加速器自己也要回源到Docker Hub取一遍速度取决于加速器到Docker Hub的质量。注意在Docker语境里加速器、镜像源、registry mirror三个词指的是同一个东西只是习惯叫法不同。下文统一叫“镜像源”或“加速器”。2. 镜像源盘点哪些目前真的能用2.1 时效性说明和验证逻辑镜像源这个东西最大的问题就是“今天能用明天可能就挂了”。原因很多有的是运营方调整服务策略有的是带宽成本扛不住还有的是DNS被污染后干脆停掉。所以先说结论不要相信任何一篇老文章里的镜像源列表包括公众号截图、博客复制粘贴出来的长串地址只能作为参考。判断一个源是否还能用的标准动作是直接请求它的/v2/接口看返回状态码。我在2026年1月中旬做了一轮批量测试分别用curl请求了市面上流传较广的几个公共镜像源确认了状态。下表是当前相对稳定、适合直接写入配置的源。左侧是我实测后的排序越靠前越推荐优先加入配置。排序镜像源地址备注与特点1https://docker.m.daocloud.ioDaoCloud提供的公共源社区口碑不错当前可用性高2https://mirror.ccs.tencentyun.com腾讯云内部网络专用但公网偶尔也能通适合云服务器场景3https://hub-mirror.c.163.com网易源老牌稳定源速度中等4https://docker.mirrors.ustc.edu.cn中科大源高校源里维护较好的热门镜像比例高5https://mirror.baidubce.com百度源部分网络环境下表现不错6https://你的ID.mirror.aliyuncs.com阿里云个人专属加速器需要登录阿里云控制台获取特别提醒一下阿里云的加速器地址不是统一的每个人在阿里云容器镜像服务控制台里看到的地址都带一串个人ID形如https://xxxxx.mirror.aliyuncs.com需要自己登录后复制。腾讯云也有类似的个人专属地址机制。2.2 已经废掉的老古董网上很多教程还在推荐几个老地址这里点名一下不要再往里放了https://registry.docker-cn.comDocker官方曾经提供的中国加速器多年前就已停止服务。https://dockerhub.azk8s.cn、https://reg-mirror.qiniu.com曾经在特定时间段内可用现在基本处于不可用或者半瘫痪状态。这些地址放进配置里不会报错但等于没配因为请求过去要么超时要么返回404。还会拖慢Docker的拉取流程因为Docker在拉一个镜像时会按registry-mirrors列表顺序逐个尝试第一个不行再试第二个白白增加等待时间。2.3 选源的策略我的建议是不要把鸡蛋放在一个篮子里但也不要一次性塞一大堆。Docker的registry-mirrors支持配置多个地址拉取镜像时会按顺序逐个尝试。配置三到四个质量好的源就够了排序逻辑是第一位放你最信任、当前实测最快的源。第二位放另一个大厂或高校源作为备份。第三、第四位放备用的冷门源。不要盲目塞七八个。某几个老源挂了以后docker pull会在它们身上耗费很长的超时时间反而拖累整体速度。3. 配置实操从Linux到Docker Desktop3.1 Linux环境下的标准配置Linux环境配置镜像源是最核心的场景因为大多数Docker跑在Linux服务器上。核心操作是修改/etc/docker/daemon.json文件。先做备份这是个好习惯sudo cp /etc/docker/daemon.json /etc/docker/daemon.json.bak_$(date %F)然后编辑文件sudo vim /etc/docker/daemon.json写入以下内容{ registry-mirrors: [ https://docker.m.daocloud.io, https://docker.mirrors.ustc.edu.cn, https://hub-mirror.c.163.com ] }如果文件原本就有内容比如你之前配过insecure-registries或者>systemctl daemon-reload systemctl restart docker重启完成后验证配置是否生效docker info | grep -A 5 Registry Mirrors如果返回结果里列出了你写入的地址说明镜像源已经配置成功。3.2 Docker DesktopWindows/macOS的配置方法用Docker Desktop的同学不需要去改文件直接在图形界面里操作。打开Docker Desktop进入右上角的设置齿轮图标找到Docker Engine选项卡可以看到一个JSON编辑框。把你需要加的registry-mirrors配置写进去然后点击Apply RestartDocker会自动重启并应用配置。同样的验证方式是打开终端Windows下是PowerShell或CMD执行docker info | findstr -A 5 Registry Mirrors或者直接看Docker Desktop的主界面状态如果重启后一切正常说明配置没问题。这里有个容易踩的坑Docker Desktop底层在不同系统上有不同的虚拟机实现方案Windows下依赖WSL2或Hyper-VmacOS下有自己的虚拟机。如果你改了daemon.json后Docker Desktop起不来先别慌把刚才写的配置恢复到默认值然后再去检查JSON语法是否出错了。3.3 适合临时调试的启动参数方式有时候你不想改全局配置只想想验证某个镜像源是否可用可以用命令行方式临时指定镜像源启动Docker守护进程。如果你是手动启动dockerd的sudo dockerd --registry-mirrorhttps://docker.m.daocloud.io这种方式的优点是即时生效不用改配置文件、不用全局重启Docker服务缺点是只对本次启动的守护进程生效重启后失效。适合用来对比不同镜像源的拉取速度差异。3.4 一键配置脚本如果你要批量维护多台服务器手打JSON肯定不现实。我自己写了个一键脚本逻辑很简单就是备份、写入、重启、验证#!/bin/bash # setup-docker-mirror.sh set -e MIRRORS[https://docker.m.daocloud.io,https://docker.mirrors.ustc.edu.cn,https://hub-mirror.c.163.com] if [ -f /etc/docker/daemon.json ]; then sudo cp /etc/docker/daemon.json /etc/docker/daemon.json.bak_$(date %F) fi # 检查是否是合法JSON是的话用python合并 sudo python3 - $MIRRORS EOF import json, sys mirrors json.loads(sys.argv[1]) path /etc/docker/daemon.json try: with open(path) as f: data json.load(f) except FileNotFoundError: data {} data[registry-mirrors] mirrors with open(path, w) as f: json.dump(data, f, indent2, ensure_asciiFalse) EOF sudo systemctl daemon-reload sudo systemctl restart docker docker info | grep -A 5 Registry Mirrors用python合并比直接用sed改安全得多至少不会因为手误把JSON写坏导致Docker守护进程起不来。4. 测速方法别凭感觉选源4.1 快速接口连通性检查配置镜像源之前先用curl做一轮基础探测判断哪些源在当前网络下能连通、响应时间是多少。/v2/是Docker Registry API的基础端点群测一下延迟for mirror in \ https://docker.m.daocloud.io \ https://docker.mirrors.ustc.edu.cn \ https://hub-mirror.c.163.com \ https://mirror.baidubce.com; do echo $mirror curl -o /dev/null -s -w HTTP状态码: %{http_code} | 总耗时: %{time_total}s\n \ --connect-timeout 5 \ $mirror/v2/ done返回的HTTP状态码不管是他妈的200还是401都是正常的401代表需要认证但说明链路是通的。如果curl在5秒内连接超时说明这个源在你这张网上很可能不可用。这一步能筛掉大部分不可用的镜像源但是它只能说明“能连通”不能说明“下载快”。真正决定下载速度的是blob传输通道还得靠实际拉镜像来测。4.2 实测拉取选一个镜像当标尺我的方法是选一个体积适中、层数合理的标准镜像比如mysql:8.0或redis:7.2-alpine分别配置不同镜像源后拉取记录时间。具体步骤先确保本机没有缓存该镜像docker rmi mysql:8.0 2/dev/null || true拉取并计时time docker pull mysql:8.0记录输出里的关键信息尤其是最后一行出现的Downloaded和总耗时。这里有一个非常容易被忽略的细节如果你用了镜像源docker pull输出的第一行Pulling from后面跟着的地址会变成对应的镜像源地址。比如配置了DaoCloud后输出会显示Pulling from docker.m.daocloud.io/library/mysql而不是docker.io/library/mysql。看到这个变化才说明配置真的生效了而不是自己在骗自己。建议至少测三个源每个源之间记得执行一次docker rmi清缓存确保公平对比。我实测下来同一个mysql:8.0镜像在一个源下需要2分钟在另一个源下只需要40秒差别非常大。4.3 如何科学地判断“够不够快”因为大家的带宽条件不同纯粹比对绝对值没意义但可以给一个参考区间。以mysql:8.0为例镜像实际下载大小大约200MB左右拉取耗时评价30秒以内当前网络和源都很给力30秒到2分钟可正常使用日常开发不受影响2分钟到5分钟能用但不爽建议换源5分钟以上这个源直接放弃换下一个如果你在多个源之间摇摆不定可以写个脚本把上面的流程串起来自动拉一遍同一镜像并输出时间最后选时间最短的放入daemon.json的第一位。5. 常见问题与排查实录5.1 配置了镜像源但不生效这是遇到最多的问题大部分情况是忘记了重启Docker服务。修改daemon.json后必须执行systemctl daemon-reload systemctl restart docker也可以用docker info确认当前生效的Registry Mirrors列表。如果列表为空说明配置没有被加载优先检查daemon.json的JSON语法是否合法python3 -m json.tool /etc/docker/daemon.json如果这个命令报错说明你的JSON格式有误Docker守护进程根本无法解析甚至可能起不来。5.2 x509证书和HTTPS错误拉取时如果看到类似x509: certificate signed by unknown authority的报错说明你配置的镜像源使用的是不被系统信任的HTTPS证书。正常情况下上面推荐的几个公共源都是正规CA签发的证书不会出现这个问题。如果你用了某个自建的内网镜像源才需要把它的证书加入系统信任列表或者将该地址加入insecure-registries。insecure-registries是另一个Docker配置项用来声明“即使HTTPS证书不可信或使用纯HTTP也允许访问”的仓库地址。但我的建议是不到万不得已不用把自己暴露在明文传输下风险很大。5.3 manifest unknown与镜像源同步不完整如果你从一个镜像源拉取某个不太热门的镜像报错manifest unknown大概率不是你的问题而是这个镜像源的缓存里没有这个镜像的元数据。因为大部分镜像源只会缓存Docker Hub上的热门镜像或者只同步白名单内的namespace。第三方个人上传的镜像如果没被同步到docker pull就会失败。遇到这种情况最快的方式是临时换个源试试或者直接用官方地址拉取。这也是为什么我建议.daemon.json里多配置几个源的原因之一。5.4 Docker Desktop启动失败如果你修改了Docker Desktop的Docker Engine配置后重启时发现Docker Desktop一直停留在启动中或者直接报错先回到设置界面把JSON内容还原为默认配置重启Docker Desktop确认能启动后再逐步加入镜像源配置。Docker Desktop内部自己有配置文件管理比Linux版的daemon.json更“娇气”。我见过有人因为把JSON里的注释符号//也粘贴进去导致解析失败整个桌面应用都起不来。记住一个原则JSON格式里不允许任何注释。5.5 Docker Hub访问本来就慢换源就好一个常见误区是配置了镜像源后所有和Docker Hub相关的操作都变快了。实际上registry-mirrors只对docker pull生效不影响docker push。你自己构建镜像后执行docker push走的还是官方registry上传速度不会因为你配置了加速器而变快。另外docker build过程中需要的基础镜像拉取是走镜像源的但构建过程中的网络请求比如Dockerfile里执行apt-get install仍然跟镜像源无关。6. 别忘了安全镜像源不是拿来乱配的6.1 公共镜像源的安全隐患镜像源看似只是帮我们拉取镜像的“中间人”但如果这个镜像源被恶意控制它可以返回任意它想返回的数据。也就是说你以为你拉的是官方mysql:8.0实际上可能是被篡改过的恶意镜像里面可能包含窃密脚本、挖矿程序或者后门。为什么我会强调优先使用大厂或知名高校提供的镜像源因为它们的信誉、运维水平、安全能力都相对可靠被投毒的概率低得多。换成来路不明的个人镜像源就算拉取速度再快也不要把生产环境的安全交给它。在拉取关键镜像尤其是安全相关的镜像比如nginx、redis、mysql时我建议顺手做一次校验docker images --digests或者直接在配置里用摘要锁定版本docker pull mysql:8.0sha256:xxxxxxxxxxxxxxxxxxxxxxxxx这样的话即使镜像源返回了不同的镜像Docker也会校验digest不一致而拒绝使用。6.2 内网和生产环境的更优解自建镜像缓存如果你在团队里负责基础设施维护着多台服务器我不建议每台机器都直连公共镜像源更好的方案是在内网搭一个镜像缓存层让所有节点统一从内网拉取镜像。常见方案有两个Harbor功能全面的容器镜像仓库支持代理缓存Proxy Cache功能可以配置为Docker Hub的缓存上游内网节点配置Harbor地址为镜像源。Nexus Repository Manager除了管Java依赖包也支持Docker Proxy Repository通过配置远程仓库指向Docker Hub再缓存到本地。自建缓存的核心价值不只是内网速度快更在于网络隔离环境下的可控性。内网节点不需要直接访问外网只需要能访问你自建的Harbor或Nexus服务。我记得第一次在生产环境推进这个方案时花了半天把Harbor的代理缓存配好之后所有节点拉同一个热门镜像第一次回源后后续速度直接从分钟级变成秒级效果立竿见影。6.3 长效维护镜像源地址要定期复测镜像源没有一劳永逸的配置。公共镜像源可能会因为运营调整、成本压力、网络环境变化而失效或降速。我的习惯是每季度写个小脚本把所有候选镜像源跑一遍测速把结果和当前daemon.json的配置对比一遍如果发现第一位源已经不给力了就调整顺序。写成定时任务也完全可以0 4 1 * * /opt/scripts/docker_mirror_check.sh /var/log/docker_mirror_check.log 21脚本核心就是前面提到的curl检查和time docker pull再把结果写到日志里。运维同学可以在月初扫一眼上个月的日志就能判断是否需要调整。另外如果你给新人或自己的新电脑配环境建议直接把配置命令存成一个Markdown或脚本放Git仓库里省得每次装新机器时都去搜索引擎里翻还容易翻到过时教程。最后再分享一个我自己的习惯在家里的开发机上我会把docker.m.daocloud.io放在第一位把中科大源放第二位第三位放网易源三个源基本覆盖了我日常开发中90%以上的拉取需求。如果哪天某个源突然不行了docker pull会自动尝试下一个源虽然偶尔会有几秒等待但至少不影响干活。如果你刚好也在排查Docker拉取速度的问题希望这篇文章能帮你少走点弯路。配置好镜像源后再用上面的测速方法验证一遍把真正合适的源留下来用完记得回来告诉我你测试的结果我也想知道基础镜像之外那些冷门镜像拉取速度到底怎么样。
帮朋友排查Docker环境问题时发现一个特别典型的现状网上搜到的镜像源配置教程大部分还停留在两三年之前列出来的地址要么已经失效要么被限流到没法用最后拉一个最基础的系统镜像都得看运气。这篇文章我打算把2026年初这个时间点上国内网络环境下实际能用的Docker镜像源、加速器配置方式完整梳理一遍再附上我自己常用的测速方法帮你判断到底哪个源值得放进配置里。不管你是刚装好Docker Desktop的新手还是被内网拉镜像折磨的运维都可以直接照着操作。1. 先搞清楚镜像源加速到底在加速什么1.1 一个docker pull命令慢在哪很多人在第一次接触镜像加速时下意识以为Docker镜像就是一个大文件拉取慢纯粹是文件大。其实不对。Docker镜像拉取走的是HTTPS连接整个流程大致分三步请求Docker Hub的认证服务和manifest接口拿到镜像的元数据。根据元数据里的layer列表逐个发起blob下载请求。把各个layer完整下载后解压、合并成可运行的容器文件系统。这三个环节里第二步下载layer占了大头。一个稍微完整点的镜像比如MySQL 8.0解压后可能有好几百MB网络快慢直接决定了你要等10秒还是等10分钟。而第一步的manifest请求虽然数据量不大但如果到Docker Hub的链路本身就超时、断连那连启动拉取都做不到。你如果遇到docker pull卡在Waiting或者反复出现TLS handshake timeout绝大多数情况就是Docker Hub在国内网络环境下访问不稳定。这不是你机器的问题也不是Docker安装出了问题纯粹是链路质量不行。1.2 镜像加速器的本质一个代理加缓存Docker官方从1.13版本开始就支持配置registry-mirrors也就是镜像加速器。它做的事情听起来很简单当你配置了一个加速器地址后Docker拉镜像时不会直接访问registry-1.docker.io而是先请求你配置的这个加速器服务。加速器服务拿到请求后会做两件事把Docker Hub上的manifest和layer拉取下来。在本地做一层缓存下次其他人请求同一个镜像时直接从缓存返回。所以镜像加速器本质上是一个“代理加缓存”的角色。你配了它拉镜像的终端连接从“你的机器到Docker Hub”变成了“你的机器到加速器”只要后半段链路质量好速度就能明显提升。这个机制也解释了为什么会有“冷热镜像”的概念越多人用的热门镜像加速器缓存里越可能有现成文件拉取速度越快冷门镜像第一次拉取时加速器自己也要回源到Docker Hub取一遍速度取决于加速器到Docker Hub的质量。注意在Docker语境里加速器、镜像源、registry mirror三个词指的是同一个东西只是习惯叫法不同。下文统一叫“镜像源”或“加速器”。2. 镜像源盘点哪些目前真的能用2.1 时效性说明和验证逻辑镜像源这个东西最大的问题就是“今天能用明天可能就挂了”。原因很多有的是运营方调整服务策略有的是带宽成本扛不住还有的是DNS被污染后干脆停掉。所以先说结论不要相信任何一篇老文章里的镜像源列表包括公众号截图、博客复制粘贴出来的长串地址只能作为参考。判断一个源是否还能用的标准动作是直接请求它的/v2/接口看返回状态码。我在2026年1月中旬做了一轮批量测试分别用curl请求了市面上流传较广的几个公共镜像源确认了状态。下表是当前相对稳定、适合直接写入配置的源。左侧是我实测后的排序越靠前越推荐优先加入配置。排序镜像源地址备注与特点1https://docker.m.daocloud.ioDaoCloud提供的公共源社区口碑不错当前可用性高2https://mirror.ccs.tencentyun.com腾讯云内部网络专用但公网偶尔也能通适合云服务器场景3https://hub-mirror.c.163.com网易源老牌稳定源速度中等4https://docker.mirrors.ustc.edu.cn中科大源高校源里维护较好的热门镜像比例高5https://mirror.baidubce.com百度源部分网络环境下表现不错6https://你的ID.mirror.aliyuncs.com阿里云个人专属加速器需要登录阿里云控制台获取特别提醒一下阿里云的加速器地址不是统一的每个人在阿里云容器镜像服务控制台里看到的地址都带一串个人ID形如https://xxxxx.mirror.aliyuncs.com需要自己登录后复制。腾讯云也有类似的个人专属地址机制。2.2 已经废掉的老古董网上很多教程还在推荐几个老地址这里点名一下不要再往里放了https://registry.docker-cn.comDocker官方曾经提供的中国加速器多年前就已停止服务。https://dockerhub.azk8s.cn、https://reg-mirror.qiniu.com曾经在特定时间段内可用现在基本处于不可用或者半瘫痪状态。这些地址放进配置里不会报错但等于没配因为请求过去要么超时要么返回404。还会拖慢Docker的拉取流程因为Docker在拉一个镜像时会按registry-mirrors列表顺序逐个尝试第一个不行再试第二个白白增加等待时间。2.3 选源的策略我的建议是不要把鸡蛋放在一个篮子里但也不要一次性塞一大堆。Docker的registry-mirrors支持配置多个地址拉取镜像时会按顺序逐个尝试。配置三到四个质量好的源就够了排序逻辑是第一位放你最信任、当前实测最快的源。第二位放另一个大厂或高校源作为备份。第三、第四位放备用的冷门源。不要盲目塞七八个。某几个老源挂了以后docker pull会在它们身上耗费很长的超时时间反而拖累整体速度。3. 配置实操从Linux到Docker Desktop3.1 Linux环境下的标准配置Linux环境配置镜像源是最核心的场景因为大多数Docker跑在Linux服务器上。核心操作是修改/etc/docker/daemon.json文件。先做备份这是个好习惯sudo cp /etc/docker/daemon.json /etc/docker/daemon.json.bak_$(date %F)然后编辑文件sudo vim /etc/docker/daemon.json写入以下内容{ registry-mirrors: [ https://docker.m.daocloud.io, https://docker.mirrors.ustc.edu.cn, https://hub-mirror.c.163.com ] }如果文件原本就有内容比如你之前配过insecure-registries或者>systemctl daemon-reload systemctl restart docker重启完成后验证配置是否生效docker info | grep -A 5 Registry Mirrors如果返回结果里列出了你写入的地址说明镜像源已经配置成功。3.2 Docker DesktopWindows/macOS的配置方法用Docker Desktop的同学不需要去改文件直接在图形界面里操作。打开Docker Desktop进入右上角的设置齿轮图标找到Docker Engine选项卡可以看到一个JSON编辑框。把你需要加的registry-mirrors配置写进去然后点击Apply RestartDocker会自动重启并应用配置。同样的验证方式是打开终端Windows下是PowerShell或CMD执行docker info | findstr -A 5 Registry Mirrors或者直接看Docker Desktop的主界面状态如果重启后一切正常说明配置没问题。这里有个容易踩的坑Docker Desktop底层在不同系统上有不同的虚拟机实现方案Windows下依赖WSL2或Hyper-VmacOS下有自己的虚拟机。如果你改了daemon.json后Docker Desktop起不来先别慌把刚才写的配置恢复到默认值然后再去检查JSON语法是否出错了。3.3 适合临时调试的启动参数方式有时候你不想改全局配置只想想验证某个镜像源是否可用可以用命令行方式临时指定镜像源启动Docker守护进程。如果你是手动启动dockerd的sudo dockerd --registry-mirrorhttps://docker.m.daocloud.io这种方式的优点是即时生效不用改配置文件、不用全局重启Docker服务缺点是只对本次启动的守护进程生效重启后失效。适合用来对比不同镜像源的拉取速度差异。3.4 一键配置脚本如果你要批量维护多台服务器手打JSON肯定不现实。我自己写了个一键脚本逻辑很简单就是备份、写入、重启、验证#!/bin/bash # setup-docker-mirror.sh set -e MIRRORS[https://docker.m.daocloud.io,https://docker.mirrors.ustc.edu.cn,https://hub-mirror.c.163.com] if [ -f /etc/docker/daemon.json ]; then sudo cp /etc/docker/daemon.json /etc/docker/daemon.json.bak_$(date %F) fi # 检查是否是合法JSON是的话用python合并 sudo python3 - $MIRRORS EOF import json, sys mirrors json.loads(sys.argv[1]) path /etc/docker/daemon.json try: with open(path) as f: data json.load(f) except FileNotFoundError: data {} data[registry-mirrors] mirrors with open(path, w) as f: json.dump(data, f, indent2, ensure_asciiFalse) EOF sudo systemctl daemon-reload sudo systemctl restart docker docker info | grep -A 5 Registry Mirrors用python合并比直接用sed改安全得多至少不会因为手误把JSON写坏导致Docker守护进程起不来。4. 测速方法别凭感觉选源4.1 快速接口连通性检查配置镜像源之前先用curl做一轮基础探测判断哪些源在当前网络下能连通、响应时间是多少。/v2/是Docker Registry API的基础端点群测一下延迟for mirror in \ https://docker.m.daocloud.io \ https://docker.mirrors.ustc.edu.cn \ https://hub-mirror.c.163.com \ https://mirror.baidubce.com; do echo $mirror curl -o /dev/null -s -w HTTP状态码: %{http_code} | 总耗时: %{time_total}s\n \ --connect-timeout 5 \ $mirror/v2/ done返回的HTTP状态码不管是他妈的200还是401都是正常的401代表需要认证但说明链路是通的。如果curl在5秒内连接超时说明这个源在你这张网上很可能不可用。这一步能筛掉大部分不可用的镜像源但是它只能说明“能连通”不能说明“下载快”。真正决定下载速度的是blob传输通道还得靠实际拉镜像来测。4.2 实测拉取选一个镜像当标尺我的方法是选一个体积适中、层数合理的标准镜像比如mysql:8.0或redis:7.2-alpine分别配置不同镜像源后拉取记录时间。具体步骤先确保本机没有缓存该镜像docker rmi mysql:8.0 2/dev/null || true拉取并计时time docker pull mysql:8.0记录输出里的关键信息尤其是最后一行出现的Downloaded和总耗时。这里有一个非常容易被忽略的细节如果你用了镜像源docker pull输出的第一行Pulling from后面跟着的地址会变成对应的镜像源地址。比如配置了DaoCloud后输出会显示Pulling from docker.m.daocloud.io/library/mysql而不是docker.io/library/mysql。看到这个变化才说明配置真的生效了而不是自己在骗自己。建议至少测三个源每个源之间记得执行一次docker rmi清缓存确保公平对比。我实测下来同一个mysql:8.0镜像在一个源下需要2分钟在另一个源下只需要40秒差别非常大。4.3 如何科学地判断“够不够快”因为大家的带宽条件不同纯粹比对绝对值没意义但可以给一个参考区间。以mysql:8.0为例镜像实际下载大小大约200MB左右拉取耗时评价30秒以内当前网络和源都很给力30秒到2分钟可正常使用日常开发不受影响2分钟到5分钟能用但不爽建议换源5分钟以上这个源直接放弃换下一个如果你在多个源之间摇摆不定可以写个脚本把上面的流程串起来自动拉一遍同一镜像并输出时间最后选时间最短的放入daemon.json的第一位。5. 常见问题与排查实录5.1 配置了镜像源但不生效这是遇到最多的问题大部分情况是忘记了重启Docker服务。修改daemon.json后必须执行systemctl daemon-reload systemctl restart docker也可以用docker info确认当前生效的Registry Mirrors列表。如果列表为空说明配置没有被加载优先检查daemon.json的JSON语法是否合法python3 -m json.tool /etc/docker/daemon.json如果这个命令报错说明你的JSON格式有误Docker守护进程根本无法解析甚至可能起不来。5.2 x509证书和HTTPS错误拉取时如果看到类似x509: certificate signed by unknown authority的报错说明你配置的镜像源使用的是不被系统信任的HTTPS证书。正常情况下上面推荐的几个公共源都是正规CA签发的证书不会出现这个问题。如果你用了某个自建的内网镜像源才需要把它的证书加入系统信任列表或者将该地址加入insecure-registries。insecure-registries是另一个Docker配置项用来声明“即使HTTPS证书不可信或使用纯HTTP也允许访问”的仓库地址。但我的建议是不到万不得已不用把自己暴露在明文传输下风险很大。5.3 manifest unknown与镜像源同步不完整如果你从一个镜像源拉取某个不太热门的镜像报错manifest unknown大概率不是你的问题而是这个镜像源的缓存里没有这个镜像的元数据。因为大部分镜像源只会缓存Docker Hub上的热门镜像或者只同步白名单内的namespace。第三方个人上传的镜像如果没被同步到docker pull就会失败。遇到这种情况最快的方式是临时换个源试试或者直接用官方地址拉取。这也是为什么我建议.daemon.json里多配置几个源的原因之一。5.4 Docker Desktop启动失败如果你修改了Docker Desktop的Docker Engine配置后重启时发现Docker Desktop一直停留在启动中或者直接报错先回到设置界面把JSON内容还原为默认配置重启Docker Desktop确认能启动后再逐步加入镜像源配置。Docker Desktop内部自己有配置文件管理比Linux版的daemon.json更“娇气”。我见过有人因为把JSON里的注释符号//也粘贴进去导致解析失败整个桌面应用都起不来。记住一个原则JSON格式里不允许任何注释。5.5 Docker Hub访问本来就慢换源就好一个常见误区是配置了镜像源后所有和Docker Hub相关的操作都变快了。实际上registry-mirrors只对docker pull生效不影响docker push。你自己构建镜像后执行docker push走的还是官方registry上传速度不会因为你配置了加速器而变快。另外docker build过程中需要的基础镜像拉取是走镜像源的但构建过程中的网络请求比如Dockerfile里执行apt-get install仍然跟镜像源无关。6. 别忘了安全镜像源不是拿来乱配的6.1 公共镜像源的安全隐患镜像源看似只是帮我们拉取镜像的“中间人”但如果这个镜像源被恶意控制它可以返回任意它想返回的数据。也就是说你以为你拉的是官方mysql:8.0实际上可能是被篡改过的恶意镜像里面可能包含窃密脚本、挖矿程序或者后门。为什么我会强调优先使用大厂或知名高校提供的镜像源因为它们的信誉、运维水平、安全能力都相对可靠被投毒的概率低得多。换成来路不明的个人镜像源就算拉取速度再快也不要把生产环境的安全交给它。在拉取关键镜像尤其是安全相关的镜像比如nginx、redis、mysql时我建议顺手做一次校验docker images --digests或者直接在配置里用摘要锁定版本docker pull mysql:8.0sha256:xxxxxxxxxxxxxxxxxxxxxxxxx这样的话即使镜像源返回了不同的镜像Docker也会校验digest不一致而拒绝使用。6.2 内网和生产环境的更优解自建镜像缓存如果你在团队里负责基础设施维护着多台服务器我不建议每台机器都直连公共镜像源更好的方案是在内网搭一个镜像缓存层让所有节点统一从内网拉取镜像。常见方案有两个Harbor功能全面的容器镜像仓库支持代理缓存Proxy Cache功能可以配置为Docker Hub的缓存上游内网节点配置Harbor地址为镜像源。Nexus Repository Manager除了管Java依赖包也支持Docker Proxy Repository通过配置远程仓库指向Docker Hub再缓存到本地。自建缓存的核心价值不只是内网速度快更在于网络隔离环境下的可控性。内网节点不需要直接访问外网只需要能访问你自建的Harbor或Nexus服务。我记得第一次在生产环境推进这个方案时花了半天把Harbor的代理缓存配好之后所有节点拉同一个热门镜像第一次回源后后续速度直接从分钟级变成秒级效果立竿见影。6.3 长效维护镜像源地址要定期复测镜像源没有一劳永逸的配置。公共镜像源可能会因为运营调整、成本压力、网络环境变化而失效或降速。我的习惯是每季度写个小脚本把所有候选镜像源跑一遍测速把结果和当前daemon.json的配置对比一遍如果发现第一位源已经不给力了就调整顺序。写成定时任务也完全可以0 4 1 * * /opt/scripts/docker_mirror_check.sh /var/log/docker_mirror_check.log 21脚本核心就是前面提到的curl检查和time docker pull再把结果写到日志里。运维同学可以在月初扫一眼上个月的日志就能判断是否需要调整。另外如果你给新人或自己的新电脑配环境建议直接把配置命令存成一个Markdown或脚本放Git仓库里省得每次装新机器时都去搜索引擎里翻还容易翻到过时教程。最后再分享一个我自己的习惯在家里的开发机上我会把docker.m.daocloud.io放在第一位把中科大源放第二位第三位放网易源三个源基本覆盖了我日常开发中90%以上的拉取需求。如果哪天某个源突然不行了docker pull会自动尝试下一个源虽然偶尔会有几秒等待但至少不影响干活。如果你刚好也在排查Docker拉取速度的问题希望这篇文章能帮你少走点弯路。配置好镜像源后再用上面的测速方法验证一遍把真正合适的源留下来用完记得回来告诉我你测试的结果我也想知道基础镜像之外那些冷门镜像拉取速度到底怎么样。
