用过 Docker 的朋友应该都有过这种经历刚在 docker hub 上找到一个镜像兴冲冲执行docker pull然后就看到进度条纹丝不动过一会儿直接给你报个net/http: TLS handshake timeout。这不是你网络的问题也不是镜像本身的问题而是 Docker Hub 在国内的网络链路实在不算通畅。所以“Docker 国内镜像源”就成了几乎所有人在安装完 Docker 之后第一件要处理的事。我这次整理的是 9 月 13 日当天实测可用的镜像加速地址。先声明一下镜像源的可用性和速度会随着时间、地区、运营商不断变化我今天测能通不代表下周还能用更不代表你所在地区一定快。这篇文章不搞“永久可用”那种自欺欺人的话术只把实测结果、配置方法、排查思路一并写清楚你照着配置完能省下大量时间后面遇到失效也能自己处理。1. 镜像加速这件事为什么越来越麻烦1.1 拉镜像慢不是网速的问题很多人一开始以为 Docker 拉镜像慢是自己宽带不行。其实你拿迅雷下载能跑满带宽看视频也完全不卡但docker pull就是一动不动这时候就要明白瓶颈在客户端与 Docker Hub 之间的跨境传输链路而不是你的本地网速。Docker Hub 的官方仓库域名是registry-1.docker.io镜像的元数据和分层文件都从这里下发。国内访问这个域名的链路质量长期不稳定尤其在没有特殊网络手段的情况下经常出现连接超时、连接被重置、下载中途断流这类问题。镜像本身动辄几百 MB 甚至几个 GB中间只要断一次Docker 又不会自动断点续传你就得重新拉一遍体验非常糟糕。这时候“国内镜像源”就派上用场了。它本质上是一个处于国内、能够访问 Docker Hub 并缓存镜像分层的代理服务。Docker 客户端在拉镜像时会把请求发给这个国内地址由它去帮你把数据取回来速度自然快很多。1.2 为什么“今日可用”列表会经常失效你可能会好奇明明前几个月还用得好好的镜像源怎么突然就拉不动了这里有几个非常现实的原因。第一Docker 官方对公共镜像源的态度越来越严厉。很多人可能不知道Docker Hub 的服务条款里并不鼓励第三方大规模做公开 mirror一旦某个源的使用量过大官方会直接对它的 API 进行限流甚至封禁。频繁被封是很多公共镜像站“短命”的根本原因。第二大量公共镜像源是个人或小团队用有限的服务器带宽撑起来的。维护者一开始可能是兴趣驱动但架不住用的人越来越多服务器流量跑爆只能限流、加白名单或者彻底关闭。你看到很多源悄无声息挂了其实就是维护者不堪重负不再维护了。第三域名和证书也是常见问题。有些源换域名、换 CDN、证书过期没续客户端就会报tls: failed to verify certificate或者直接拒绝连接。所以我的建议很简单不要收藏那些号称“永久有效”的名单也不要一次性把十个源全部配进去。你要做的是理解配置方法学会自己验证源的可用性每隔一段时间刷新一次配置。这也是为什么我会反复强调“9 月 13 日实测”这个时间点镜像源清单是有时效性的脱离了时间谈可用性没有意义。2. 9月13日实测可以用的国内镜像源加速列表2.1 验证条件和评测口径先说一下这次验证的环境方便你判断结果能不能参考。测试时间是 9 月 13 日测试机器是一台普通家庭宽带下的 Ubuntu 22.04Docker 版本是 26.x。我在没有配置任何代理、纯直连的情况下对候选源逐一做了连通性测试和小镜像拉取测试。测试分两层第一层用curl -I请求各镜像源的/v2/接口只要返回 HTTP 200、401、403 这类正常响应说明该源的 Docker Registry API 是活的第二层对通过第一层测试的源实际执行docker pull hello-world或者docker pull alpine:latest这类小镜像确认真的能拉下来。需要提前说明的是家庭宽带、不同运营商、不同地区的网络环境差异很大。我在电信网络下测出很快的源你在联通或移动网络下可能是另一个结果。所以下面这个列表是我的实测参考不是绝对真理。如果你的结果和我不同优先以你自己的实测为准。2.2 镜像加速地址列表以下是我在 9 月 13 日实际验证过可以连通的部分镜像源地址。镜像源地址协议当天状态备注https://docker.m.daocloud.ioHTTPS可用速度较快DaoCloud 提供老牌稳定适合做主源https://docker.1ms.runHTTPS可用速度不错属于目前存活率较高的源https://docker.1panel.liveHTTPS可用1Panel 团队维护比较稳https://docker.xuanyuan.meHTTPS可用社区维护速度中规中矩https://hub.rat.devHTTPS可用社区源偶尔有波动https://docker.udayun.comHTTPS可用联通网络下表现较好https://docker.211678.topHTTPS可用个人维护适合做备用https://dockerproxy.comHTTPS部分区域可用老牌源但近期各地区差异较大需要自己测强调一句不要把这些源全部填到配置里。Docker 在拉镜像时会按配置顺序依次尝试如果第一个源卡住超时会拖慢整个过程。我个人建议配置两到三个就足够了一个做主源剩下做备用。还有一点要注意上面有些域名可能今天能用明天就被关停也可能你所在地区访问某个地址特别慢。不要因为我写了“可用”就直接照抄拿到列表后花三十秒测一下再写进配置才是稳妥做法。2.3 配置方法Linux、Docker Desktop 和特殊场景不同环境下的 Docker 配置方式不一样这里我把最常见的三种场景都列出来。Linux 下使用 systemd 管理的 Docker这是服务器上最常见的场景。Docker 守护进程的镜像源配置放在/etc/docker/daemon.json如果文件不存在就新建。注意这个大括号和逗号的 JSON 格式问题写错了 Docker 会直接启动失败。{ registry-mirrors: [ https://docker.m.daocloud.io, https://docker.1ms.run, https://docker.1panel.live ] }保存之后执行下面两条命令让 Docker 重载配置并重启守护进程。sudo systemctl daemon-reload sudo systemctl restart docker重启后可以查看配置是否生效docker info | grep -A 5 Registry Mirrors如果看到类似下面这样的输出就说明配置已经生效了Registry Mirrors: https://docker.m.daocloud.io/ https://docker.1ms.run/ https://docker.1panel.live/Docker DesktopWindows / macOSDocker Desktop 的配置入口比较简单。打开 Docker Desktop进入Settings左侧找到Docker Engine这里会展示一个 JSON 配置编辑框。你把上面的registry-mirrors字段加进去保留原有的默认配置项点击Apply Restart等待重启完成即可。在 Windows 上如果你之前装过旧版 Docker Toolbox 或者用了非 WSL2 模式配置路径可能不同但 Docker Desktop 新版基本都是走这个入口。配置完成后在终端里执行docker info同样能看到生效的镜像源列表。Rootless Docker 和 Podman如果你用的是 Rootless Docker配置文件路径不是/etc/docker/daemon.json而是当前用户目录下的~/.config/docker/daemon.json。改完之后重启方式也略有区别建议直接执行systemctl --user restart docker之类的用户级命令或者干脆重新登录会话。如果你用的是 Podman配置方式完全不一样。它读取的是/etc/containers/registries.conf配置格式是 TOML。示例如下unqualified-search-registries [docker.io] [[registry]] prefix docker.io location docker.m.daocloud.io这里把对docker.io的请求转发到镜像源的地址思路与 Docker 的 registry-mirrors 类似但配置语言不同。2.4 如果你拉的不是 Docker Hub 的镜像怎么办镜像源列表有个常见的认知误区以为配置了之后所有镜像都能加速。实际上绝大多数公共镜像源只代理 Docker Hub即docker.io上的镜像遇到quay.io、ghcr.io、gcr.io这些其他仓库的镜像它是一点忙都帮不上的。举个例子你想拉quay.io/prometheus/node-exporter配置了普通 Docker Hub 加速源后依然会非常慢。这时候有两个思路。第一有些镜像源支持“路径前缀”方式代理其他仓库即把目标仓库地址写在镜像源路径后面。比如有的源支持这种写法docker pull docker.1ms.run/quay.io/prometheus/node-exporter这种写法能否生效取决于源本身是否实现了多仓库代理不是所有源都支持。使用前最好看下对应源站有没有说明文档。第二放弃 Docker 直接拉取改用skopeo copy这类工具把镜像从其他仓库复制到本地或自己的私有仓库。skopeo不依赖 Docker 守护进程直接把远程镜像保存成docker-archive格式文件或者复制到另一个 registry适合批量搬运镜像的场景。安装方式在 Ubuntu 下是apt install skopeo用起来也不复杂。3. 很多人没搞懂的加速原理以及常见误区3.1 镜像加速到底做了什么我曾经也以为配置了镜像源之后所有镜像流量都会走镜像源。实际上 Docker 的 registry mirror 机制比这复杂一点。Docker 客户端在执行docker pull时会先向配置的 mirror 请求镜像的 manifest清单文件。如果镜像源已经有这个镜像的缓存它会把对应的分层地址告诉你Docker 再去拉取这些分层数据如果镜像源没有缓存它会回源到 Docker Hub 拉取一次缓存下来再转交给客户端。所以第一次拉某个冷门镜像时未必比直连快多少但热门镜像基本都是秒下。另外要注意registry-mirrors 只影响pull操作。push操作默认仍然直接推送到 Docker Hub镜像源不会帮你转发。如果你想实现类似“手动同步镜像到国内”的效果那不属于 mirror 的职责得靠额外的同步工具或者手动pull再tag再push。理解了这一点你就知道为什么“换源后某些镜像还是很慢”是正常的。冷门镜像第一次回源、国外 CDN 节点抖动、镜像源自身带宽不足都会影响速度。加速源不是万能药但热门镜像和常用基础镜像的体验提升是实打实的。3.2 镜像源的常见误区与避坑第一个误区加速列表越多越好。这是我最常见到的情况。有人恨不得把网上看到的十个源全部写进daemon.json结果反而更糟。Docker 拉镜像时按顺序请求某个源连接超时会阻塞整个请求流程。更合理的做法是保留两到三个把实测最快的放第一位。第二个误区换完源就再也不用担心限流。Docker Hub 对匿名拉取有速率限制镜像源虽然在一定程度上帮你承担了流量但源本身也会限流。遇到拉取频繁报错时可以先停一停或者换一个源再试。第三个误区镜像源拉下来的镜像不安全。实际上镜像源只是代理了传输链路镜像本身的分层内容不会在镜像源侧被篡改。Docker 拉取镜像时会校验内容的哈希和签名一致性如果镜像源返回的数据和 Docker Hub 不一致拉取会失败而不是默默装了个被篡改的镜像。当然这不代表你可以随便跑不明镜像那是另一回事。第四个误区镜像源等于私有仓库。镜像源只能加速或者代理公共镜像的拉取你不能往里面push自己的镜像。想要搭建私有环境应该用 Harbor、Registry、Nexus 这类私有仓库方案两者不是一个东西。第五个误区只改daemon.json就够了其他都不管。真实情况是Docker 在拉镜像前依然需要解析 DNS、建立 HTTPS 连接如果你所在环境的 DNS 解析有问题或者访问 Docker Hub 的 API 被重置光配镜像源不一定完全解决问题。我建议配置完镜像源后先docker pull hello-world做一次完整验证。4. 如果所有镜像源都不行了还能怎么办4.1 镜像加速之外的兜底方案你必须做好最坏打算某一天所有公共镜像源全部失效。这种事我遇到过几次有心理准备之后反而没那么慌。兜底方案里最常用的是离线镜像包。你可以在能正常访问 Docker Hub 的机器上用docker pull拉取需要的镜像然后执行docker save -o nginx.tar nginx:latest把镜像保存成 tar 文件再拷贝到内网或目标服务器上执行docker load -i nginx.tar这个方法在服务器无法访问外网、机房网络只有内网的环境下尤其实用。一两个镜像的迁移这样处理最快捷但如果你要批量同步一大批镜像建议用脚本循环docker pulldocker save或者用skopeo copy直接跨仓库复制。另一个思路是使用云厂商的容器镜像服务。国内主流云厂商都提供镜像仓库产品比如阿里云 ACR、腾讯云 TCR 等。你可以把 Docker Hub 的镜像先pull下来tag成自己云仓库的地址再push上去之后从云仓库拉取速度很快且稳定。缺点是操作步骤多但优势在于镜像存到自己账号下不会受公共源波动影响。如果手头有境外轻量云服务器也可以把它当跳板。在境外服务器上拉取镜像用docker save打包下载回本地再docker load导入。这个方法速度取决于你的服务器带宽但胜在稳定可控。整个过程不涉及任何敏感网络手段纯粹是镜像文件的导出导入合规安全。4.2 Ollama、HuggingFace 等非 Docker 场景怎么换源镜像源问题不只出现在 Docker 上这几年大模型相关的工具也面临类似的下载困境。Ollama 默认从registry.ollama.ai拉取模型很多人在国内拉模型模型拉到一半失败于是网上出现了不少“Ollama 国内镜像源”的说法。先说结论Ollama 官方的模型仓库地址不像 Docker Hub 那样支持标准 registry mirror 的全局配置方式网上流传的各种镜像站质量参差不齐不建议盲目使用。我比较推荐的做法是绕开 Ollama 的模型下载链路从 HuggingFace 镜像站下载模型原始文件再通过 Modelfile 方式导入。HuggingFace 国内镜像源相对成熟配置方式也很简单export HF_ENDPOINThttps://hf-mirror.com设置完这个环境变量后huggingface-cli download就能从国内镜像站下载模型文件。把模型文件下到本地后写一个 Modelile 示例FROM ./llama-3-8b-chat然后在同目录执行ollama create my-model -f Modelfile这样就能绕过 Ollama 官方的下载瓶颈而且模型文件是从 HuggingFace 镜像站获取的速度比直连稳得多。顺带提一下npm、Anaconda、Flatpak、ComfyUI 这些工具也都各自有国内镜像源或镜像站思路。npm 可以配置registryhttps://registry.npmmirror.comAnaconda 可以换defaults为清华镜像源Flatpak 可以添加国内镜像仓库地址ComfyUI 的模型下载则一般通过HF_ENDPOINT或自定义models目录指向已有模型文件。核心思路都一样找到该工具对应的“镜像源配置入口”把官方地址换成国内可达的镜像站。5. 配置后会遇到的常见问题与排查技巧5.1 常见问题速查表配置镜像源不是写完就一劳永逸我把我自己踩过、以及帮别人排查过的典型问题整理成了下面这个表。现象可能原因排查与解决拉镜像一直超时配置的镜像源不可用或网络到源站不通用curl -I https://源地址/v2/测试换其他源报错tls: failed to verify certificate镜像源域名证书过期或域名被劫持不要再关闭 TLS 校验硬扛直接删掉该源换一个Docker Desktop 无法启动提示 virtualization support not detectedBIOS 未开启虚拟化或未启用 WSL2 / Hyper-V重启进 BIOS 开启 Intel VT-x / AMD-V启用“虚拟机平台”拉取报error pulling image configuration: unexpected EOF网络质量差连接被重置重试几次或换更稳的源降低并发数报denied: requested access to the resource is denied镜像名不存在或该镜像在 Docker Hub 是私有仓库检查镜像名称拼写确认是否需要docker login拉取到一半进度不动磁盘空间不足或网络抖动先df -h看磁盘清理多余镜像再重试配置daemon.json后 Docker 启动失败JSON 格式错误、字段拼写错误执行docker info查看报错用 JSON 校验工具检查格式5.2 验证镜像源是否可用的两个命令我每次拿到新的镜像源第一件事不是急着写进配置而是先测活。测活很简单两个命令搞定。第一个命令是发送一个 HEAD 请求到镜像源的/v2/接口看返回状态码。/v2/是 Docker Registry API 的核心端点源如果能正常响应说明服务是活的。curl -sI -m 5 https://docker.m.daocloud.io/v2/ | head -n 1返回类似HTTP/2 200、HTTP/1.1 401、HTTP/1.1 403都算正常其中 401 表示需要认证但服务可用403 可能有限流但通常也能连通。如果返回curl: (28) Operation timed out说明这个源对你不可达别犹豫直接换。第二个命令是实际拉一个很小的镜像验证整个链路没有问题。hello-world只有几 KB是完美的测试对象。docker pull hello-world如果这个命令成功说明镜像源配置没有问题。如果失败就要看报错信息来定位了。5.3 一些真实踩坑记录我在这几年的实操里踩过不少坑挑几个有代表性的分享出来。有一次我图省事一次性把网上找的六个源全部写进daemon.json。结果docker info里确实能看到六个 Registry Mirrors但每次拉镜像都要等半天。后来排查发现Docker 会按顺序请求这些源第一个源连接超时后要等很久才轮到第二个源。那次之后我把配置精简到三个拉镜像速度快了很多。所以配置源这件事贵精不贵多。还有一次我在daemon.json里手滑把registry-mirrors写成了registry-mirrorDocker 启动直接失败报 JSON 解析错误以外的奇怪信息。排查了半天才发现是字段名拼错了。这类低级错误最浪费功夫建议改完配置文件先执行docker info看状态。另外某次拉镜像一直报tls: failed to verify certificate一开始我还以为是系统证书问题折腾了大半天最后发现是那个镜像源自己的域名证书过期了。换掉源之后立刻恢复正常。所以遇到 TLS 证书报错时别在自己机器上找原因先怀疑源本身。还有个 Windows 上的经典问题Docker Desktop 启动时报virtualization support not detected。这个大多是因为 Windows 的虚拟化功能没开或者没装 WSL2。需要去“启用或关闭 Windows 功能”里勾选“虚拟机平台”和“适用于 Linux 的 Windows 子系统”然后重启电脑。如果还是不行再进 BIOS 开 CPU 虚拟化。这个问题属于环境配置问题和镜像源无关但会让人误以为是 Docker 坏了。6. 如何避免以后又找不到可用源镜像源列表失效这种事咱们没法控制能做的是建立自己的“体检”习惯别等到要用的时候才发现源都挂了。我的习惯是每个月挑一天跑一个简单的脚本批量测活所有候选源。脚本的核心逻辑很简单就是循环请求每个源的/v2/接口记录返回码和耗时。你可以把下面这段存成test-mirrors.sh改一下地址列表就能用。#!/bin/bash for url in \ https://docker.m.daocloud.io \ https://docker.1ms.run \ https://docker.1panel.live \ https://docker.xuanyuan.me \ https://hub.rat.dev \ https://docker.udayun.com \ https://docker.211678.top \ https://dockerproxy.com do code$(curl -s -o /dev/null -m 5 -w %{http_code} $url/v2/) echo $url - $code done给脚本加执行权限后运行chmod x test-mirrors.sh ./test-mirrors.sh返回码是 200、401、403 的源基本都可用返回000或者超时的源直接淘汰。测试完成后把最快的源放在daemon.json的第一位丢个主源再用两个备源就够了。除了自己测活平时可以关注几个维护方的官方公告比如 DaoCloud、1Panel 这些团队如果调整服务通常会在自己的社区或文档里给出通知。不要依赖某个自媒体的“永久可用”帖子那些帖子今天发明天失效没有任何参考价值。另外镜像源偶尔也会出现“能 ping 通但拉不动镜像”的情况原因是/v2/接口通不代表它能正常回源到 Docker Hub也可能是它的 Docker Hub 出口带宽被限了。所以每个月不仅要做连通性测试最好再实际拉一个常用镜像验证速度比如docker pull alpine:latest几秒钟内完成就是健康状态。我在实际使用中还有一个很实在的习惯把经常用的镜像在本地打好 tag缓存一份再定期把关键镜像docker save成 tar 包放到内网机器上。这样即使某天公共镜像源集体失效我手上的镜像也不受影响开发测试流程完全可以继续跑。这个方法不复杂但能让你从“源失效就抓瞎”变成“源失效也无所谓”。最后再分享一个小技巧如果你维护的是团队内部服务器可以在内网搭一个轻量级私有仓库把常用镜像全部同步进去团队成员统一从内网拉取。这不仅彻底摆脱了公共镜像源的不确定性还能顺带做镜像版本管理。公共镜像源永远只是临时拐杖自己手里有镜像资产才是真正的底气。