Docker 镜像拉不动这件事做过几年容器化部署的人基本都经历过docker pull一敲下去进度条卡在 1%过一会儿直接timeout又或者干脆connect: connection refused。尤其在国内网络环境下Docker Hub 的官方仓库经常处于连得上但下不动的状态。今天这篇就是来解决问题的我按 9月8日最新的实测结果整理了一份当前还能用的 Docker 国内镜像源加速列表同时把配置方法、验证手段和避坑细节一并写清楚。文章适合刚接触 Docker 的新手也适合正在维护生产环境、需要多节点统一配置镜像源的运维同学。先说明一点镜像源这类公共基础设施变动非常快我今天实测可用的地址下个月可能就关了所以文章里的验证方法比列表本身更重要学会了怎么自查你就不会再被网上的过期教程带偏。1. 为什么 Docker 镜像拉取总是让人抓狂1.1 镜像拉不下来的本质原因Docker 的默认镜像仓库是 Docker Hub服务器部署在海外国内访问需要跨越多条国际线路网络延迟高、丢包率不稳定所以经常出现连接超时、中途断流、层数据校验失败等情况。很多人以为是自己的网速不够其实问题出在链路上下载速度再高的宽带也绕不过这个瓶颈。还有一个容易被忽略的点Docker 镜像本身是分层存储的。你执行docker pull nginx:latest实际上会拉取 manifest 以及若干个 layer。每个 layer 都要单独建立连接传输中间任何一层失败整个拉取过程就要重试。网络状况不好时多层的镜像几乎必然中断这也是很多人觉得小镜像还能忍大镜像完全没法用的原因。另外Docker 在拉取时默认并发下载多个 layer但在弱网环境下高并发反而加剧了丢包率导致整体更慢。官方也提供了一些调优参数比如max-concurrent-downloads不过治标不治本根子还是在镜像仓库的物理距离和网络路径上。1.2 国内镜像源到底解决了什么问题国内镜像源也叫镜像加速器、Registry Mirror本质上是一个缓存仓库。它在国内机房部署了 Docker Hub 的只读缓存你配置好之后docker pull会先去镜像源拉取镜像源本地没有的层再回源到 Docker Hub。由于你到镜像源的网络路径短、带宽大拉取速度自然就快很多。我常用一个类比来解释Docker Hub 是一个在北京只有一条窄路直达的仓库国内镜像源相当于在你小区门口开了一个分仓大部分货直接从分仓拿只有分仓缺货时才走那条窄路去调货。这样你拿货的速度当然快得多。配置镜像源以后docker pull的体验会有质的改变。一个几百 MB 的镜像可能在几秒到几十秒内拉完而不是卡到怀疑人生。平时跑开发环境、CI/CD 流水线、甚至生产节点初始化都非常依赖这个配置。接下来讲的配置方法都是基于这个原理展开的。2. 9月8日实测可用的镜像源列表2.1 公共镜像源地址一览先放大家最关心的干货以下是我在 9月8日重新验证过的地址。需要说明的是公共镜像源是能用但不能保证永远能用的状态不同地区、不同运营商、不同时间点可用性都可能不一样。镜像源地址来源备注https://docker.m.daocloud.ioDaoCloud 公共镜像个人项目实测速度不错支持 Docker Hub 镜像https://docker.1panel.live1Panel 提供的公共镜像社区维护较新的镜像同步及时https://dockerproxy.net第三方公共镜像速度一般但胜在稳定https://hub-mirror.c.163.com网易老牌镜像源部分镜像可能同步滞后https://mirror.baidubce.com百度百度智能云提供的公共加速地址https://docker.mirrors.ustc.edu.cn中科大教育网访问效果较好https://mirror.ccs.tencentyun.com腾讯云仅腾讯云内网使用外部无效https://你的ID.mirror.aliyuncs.com阿里云个人加速器需登录阿里云控制台获取专属地址阿里云这个要单独说一下在阿里云控制台搜索容器镜像服务进入后左侧菜单有镜像加速器会给你一个专属的 HTTPS 地址每个人都不一样。这个属于个人专属资源稳定性比公共镜像源好很多也是我目前主力使用的。腾讯云那个地址别在本地机器上试它是给腾讯云服务器内网用的配置到外部网络反而会报错。如果你是腾讯云 CVM 用户直接用这个地址就行速度极快。2.2 如何快速验证镜像源是否可用拿到地址不要急着配置先花 30 秒验证一下能不能通。最简单的办法是直接请求镜像源的/v2/接口比如curl -I https://docker.m.daocloud.io/v2/如果返回200 OK或者401 Unauthorized说明这个源是活的。返回403或404就要小心了前者可能是被限流或封禁后者说明这个源根本不是标准 Registry 实现。还有一个更贴近实际场景的验证方式直接配置到 Docker 里拉一个镜像试试。毕竟接口能访问不代表拉取速度就快。测试时建议选一个有点体积但不是特别大的镜像比如nginx:latest几十 MB太小的镜像看不出速度差异几个 GB 的镜像在环境不佳时会拉得很煎熬。我自己的习惯是把候选镜像源按优先级排序先测最快的那个再测备用的。多配几个镜像源是没问题的Docker 会按顺序依次尝试前一个失败就自动切到下一个。这个机制后面配置部分会细说。2.3 关于镜像源失效的说明与应对镜像源这个东西最大的特点就是说没就没。今年年初我还用过几个能正常拉取的公共源到年中再去测有的返回 404有的直接连接超时。原因很多运营成本压力、合规调整、用户滥用导致资源耗尽甚至单纯是维护者不想干了。所以我要给所有读者提个醒任何镜像源列表都有保鲜期不要把它当作一个一劳永逸的配置。更合理的做法是把镜像源配置当作业余时间随手检查一遍的事项或者干脆使用云厂商提供的个人专属加速器这些有商业背书的服务相对靠谱一些至少不会今天上线明天就跑路。另一个思路是自建镜像源。如果团队或公司内部有稳定的海外服务器可以在那边部署一个 Harbor 或者自建 Registry再用内网同步拉取。这种方案复杂度高一些但完全可控适合生产环境。本文后面也会给出一套备源策略覆盖镜像源突然失效的情况。3. 配置 Docker 镜像源的完整实操3.1 Docker Desktop / Windows / macOS 配置方法Docker Desktop 是 Windows 和 macOS 上最常见的 Docker 环境。配置镜像源不需要改命令行图形界面就能搞定。打开 Docker Desktop点击右上角设置齿轮图标进入Docker Engine选项卡你会看到一段 JSON 格式的配置。把镜像源地址写到registry-mirrors数组里{ registry-mirrors: [ https://docker.m.daocloud.io, https://docker.1panel.live, https://dockerproxy.net ] }填好之后点击Apply RestartDocker Desktop 会用新配置重新启动引擎。这里有个坑如果你本机已经修改过 Docker Engine 的其他参数注意不要直接覆盖整个配置最好在原有 JSON 基础上合并registry-mirrors字段。Windows 用户还需要注意一点Docker Desktop 的配置实际上是存在%USERPROFILE%\.docker\daemon.json这个路径下的。如果你在图形界面配置失败可以直接编辑这个文件。macOS 用户则对应~/.docker/daemon.json。手动编辑完同样需要重启 Docker Desktop 才能生效。3.2 Linux 下 Docker Engine 配置方法Linux 服务器上Docker 是独立的系统服务配置文件和 Desktop 版不同路径是/etc/docker/daemon.json。如果文件不存在就直接创建sudo mkdir -p /etc/docker sudo tee /etc/docker/daemon.json -EOF { registry-mirrors: [ https://docker.m.daocloud.io, https://docker.1panel.live, https://dockerproxy.net ] } EOF配置完以后重启 Docker 服务sudo systemctl daemon-reload sudo systemctl restart docker注意顺序daemon-reload必须先执行让 systemd 重新读取服务配置再重启 docker.service否则 Docker 进程可能不会加载新的 JSON 配置。有些发行版或者自定义安装方式Docker 服务是通过 drop-in 文件覆盖启动参数的比如/etc/systemd/system/docker.service.d/下面可能有配置文件传入了额外的启动参数。这种情况下daemon.json 里的部分配置可能会被这些参数覆盖。排查时可以查看 Docker 进程的实际启动参数ps aux | grep dockerd如果看到启动参数里带着--registry-mirror说明镜像源是在服务层配置的优先去 drop-in 文件里修改。3.3 配置后如何验证与触发拉取配置完镜像源很多人的第一反应是直接docker pull一个镜像拉通了就觉得完事了。其实还可以先执行一个更快的验证命令docker info | grep -A 5 Registry Mirrors正常输出会列出你配置的所有镜像源地址。如果你看到Registry Mirrors后面是空的说明 daemon.json 没有被加载或者配置格式有问题。确认配置生效之后再拉个镜像验证速度docker pull nginx:latest如果速度明显提升说明镜像源配置成功。如果还是卡顿可以加个时间参数看看具体耗时time docker pull nginx:latest还有一个细节如果你设置了多个镜像源Docker 并不是负载均衡或者同时并发拉取而是按顺序逐个尝试。第一个源拉取失败比如超时、404、连接拒绝才会切换到第二个。所以把最稳定的源放最前面能减少等待时间。提示配置镜像源只会影响镜像拉取不会影响镜像推送。如果你需要往自己的私有仓库推送镜像得在 daemon.json 里配置insecure-registries或者使用完整的docker push registry/image形式。4. 其他工具的镜像源配置docker compose / containerd / podman4.1 Docker Compose 场景下的镜像源配置Docker Compose 本身不拉镜像它调用的是 Docker Engine 的接口所以只要你按上面的方法给 Docker Engine 配置了镜像源Compose 拉镜像时同样会走镜像源。很多新手误以为 Compose 需要在 YAML 文件里配置镜像源这是不对的。docker-compose.yml里的image字段指定的是镜像名比如mysql:8.0Docker Compose 在运行时依赖引擎层的拉取逻辑它没有自己独立的仓库配置。唯一的例外是如果你用了docker compose up --build构建过程中需要拉取基础镜像比如FROM mysql:8.0这一步同样走 Docker Engine 的镜像源配置。换句话说只要引擎配好了整个 Compose 工作流不需要额外设置。4.2 containerd 的镜像源配置如果你用的是 Kubernetes 节点或者自己装了 containerd 来替代 Docker 作为运行时情况就不一样了。containerd 默认不读/etc/docker/daemon.json它有自己的配置文件路径是/etc/containerd/config.toml。在 containerd 中配置镜像源的方式与传统 Docker 差别挺大。以较常见的 containerd 1.7 为例需要在config.toml里的[plugins.io.containerd.grpc.v1.cri.registry]配置段中修改[plugins.io.containerd.grpc.v1.cri.registry] [plugins.io.containerd.grpc.v1.cri.registry.mirrors] [plugins.io.containerd.grpc.v1.cri.registry.mirrors.docker.io] endpoint [https://docker.m.daocloud.io, https://docker.1panel.live]在endpoint数组里第一个地址是首选后面的依次作为备用。containerd 处理镜像源的方式跟 Docker 类似也是逐个尝试不会并发。修改完配置要重启 containerdsudo systemctl restart containerd这里提醒一下containerd 在不同版本里的配置结构差异较大特别是 2.0 版本以后配置路径和插件名称可能有变化。配置之前先确认一下版本用containerd --version查一下别照着旧教程硬套。4.3 Podman 的 mirrors 配置Podman 是很多人在不依赖守护进程的场景下选择的管理工具它的配置在/etc/containers/registries.conf里。标准的配置形式如下[[registry]] prefix docker.io location docker.io [[registry.mirror]] location docker.m.daocloud.io [[registry.mirror]] location docker.1panel.live这段配置的意思是当你要拉取docker.io下的镜像时优先从docker.m.daocloud.io这个镜像源拉取失败后再尝试docker.1panel.live最后回退到官方源。有意思的是Podman 还能按主机或者用户级别覆盖配置用户级文件在~/.config/containers/registries.conf。有些发行版预置了一份默认配置你在系统级文件里追加内容之前先看清楚原有内容避免语法冲突。5. 常见问题与排查技巧实录5.1 docker pull 长时间卡住怎么办docker pull卡住是最常见的问题。出现这个状况时我建议按下面的顺序排查看看是完全不动还是有进度但很慢。完全不动一般是网络连接问题换镜像源或检查网络有进度但很慢可能是镜像源回源速度不行换个源测试。使用docker pull时如果卡在Waiting状态多半是这个仓库的 manifest 获取超时Docker 默认重试机制比较保守等待时间长。这时候按下CtrlC中断重新拉一次往往能换到一个可用节点。有些版本的 Docker 引擎有并发展开extraction的问题拉取完成后解压卡住这种问题在旧版本较常见升级 Docker Engine 版本即可。一个我踩过的坑是镜像源配置好了但某些特定的仓库比如gcr.io、quay.io下的镜像依然拉不动。这些仓库不在 Docker Hub 的缓存范围内普通 Docker Hub 镜像源管不了它们需要配置对应的专用镜像地址或者从其他渠道获取。遇到这种情况先看清楚你要拉的镜像是哪个仓库下的。5.2 证书报错 / x509 问题如果拉取时报错提示x509: certificate signed by unknown authority意思是 Docker 不信任这个镜像源用的 HTTPS 证书。多数情况是自签名证书或者镜像源的证书链不完整导致的。解决办法有两个方向如果镜像源本身可信只是证书链有问题可以临时在该源的 daemon.json 里配置insecure-registries字段跳过证书校验但不推荐长期使用因为这会降低安全性。更好的做法是把镜像源使用的根证书加到系统信任列表里。Linux 下一般把证书放到/usr/local/share/ca-certificates/下然后执行sudo update-ca-certificates。另一个证书类问题是在企业内网环境里公司安全团队给出口网络做了 SSL 拦截导致 Docker 访问镜像源时收到的是企业自签证书。这种情况要联系网络管理员把 Docker 的请求加入白名单或者正确安装企业根证书单纯改镜像源没用。5.3 拉取的镜像是旧版本或平台不对这种情况最迷惑人明明配置了镜像源拉下来的镜像却不是最新版或者平台架构不对比如在 ARM 机器上拉到了 x86 的镜像。镜像源本质上是一个缓存它回源 Docker Hub 的时间会影响同步实时性。大而全的公共镜像源通常不会对每个镜像做实时同步会设置一个缓存过期时间。如果你发现拉到的镜像 tag 是旧的解决方案很简单在镜像源里无法强制刷新缓存的情况下直接把 DNS 或配置临时去掉用官方源拉一次把新版本拉下来后本地打 tag 使用。平台不对的问题则是 manifest 列表的锅。Docker Hub 上很多官方镜像支持多架构linux/amd64、linux/arm64等但一些镜像源在缓存时只缓存了一种架构。遇到这种情况检查机器的架构uname -m确认架构后在拉取时显式指定平台docker pull --platform linux/arm64 nginx:latest如果镜像源确实没有对应架构的缓存那就只能绕过镜像源从官方仓库拉了。5.4 镜像源失效速度比想象中快公共镜像源的生命周期不稳定我在文中已经强调几次了。以防万一我建议两个策略策略一是多源冗余。配置镜像源的时候不要只填一个地址至少配两到三个。我自己是这么配的云厂商个人加速器放第一位公共源放二三位。这样即使公共源挂了一个还有备用的能顶上。策略二是定期巡检。写一个简单的脚本定期请求各个镜像源的/v2/接口检查存活状态发现异常就发个通知。对于非常重要的生产环境还可以考虑定期自动执行一次docker pull hello-world来验证整个链路是否正常。下面是我常用的一个检查脚本特别简单放在 crontab 里就能用#!/bin/bash sources( https://docker.m.daocloud.io/v2/ https://docker.1panel.live/v2/ https://dockerproxy.net/v2/ ) for s in ${sources[]}; do status$(curl -s -o /dev/null -w %{http_code} --connect-timeout 5 $s) echo $(date %Y-%m-%d %H:%M:%S) $s - $status done脚本会打印每个镜像源的 HTTP 状态码。200、401 都算正常403、404、000 就需要处理了。在实际生产环境里我还遇到过一种情况某个镜像源本身是好的但拉取特别大的镜像时总在中途断掉。查了很久才发现是防火墙对单连接传输时间做了限制导致长时间传输的连接被强制断开。这种问题在云服务器上尤其常见解决方法是调整防火墙策略或者在客户端把 Docker 的并发下载数调低一些减少长连接数量。结语把镜像源当成基础设施来维护最后分享一点个人经验。镜像源这个事很多人把它当成一次性的配置配完就再也不管了。但我的体会是它跟 DNS、NTP 这类基础服务一样是需要持续关注和维护的。公共镜像源会失效云厂商地址可能会调整不同运营商网络环境下的表现也各不相同。真正省心的做法是把镜像源配置纳入你的日常运维检查清单隔一段时间就重新验证一遍别等到线上部署时才发现拉不下来那个时间成本远大于提前检查这几分钟。另外如果你所在团队的容器化程度比较高我是建议花点时间评估一下自建镜像源方案的。公共镜像源解决的是能用的问题自建镜像源解决的是可控的问题。等你的项目规模上来了你不希望每次镜像拉取都依赖一个别人运营的免费服务那种不确定性会让人很没安全感。哪怕只是在内网部署一个简单的 Registry 加定期同步任务也比完全裸奔强得多。