2026 年 9 月，我猜你可能又被docker pull卡住了。这不是个例，我自己的笔记本和几台云服务器都遇到过：镜像层下载到一半就 timeout，重试几次还是不行。Docker 镜像源加速这件事，和两年前相比已经有了很大变化，很多曾经挂在收藏夹里的公共加速站要么关停、要么只对内网开放，网上还在流传的列表，十有八九配置完是跑不通的。
这篇文章我打算用一份“可以直接照着做”的清单来写：先给出我在 2026 年 9 月实际探活后觉得值得配置的国内 Docker 镜像源列表，再说明配置方法、原理、验证手段，以及镜像源失效之后怎么应对。适合直接在服务器上操作，也适合 Docker Desktop 用户和 k8s 节点维护者参考。
1. 2026 年的镜像源版图：别再迷信收藏夹里的老地址
这几年我印象最深的不是镜像源变少了，而是“看起来很多，能用的没几个”。有些源浏览器能打开，但docker pull拉不下来；有些源curl返回 401，实际又能用；还有些源前一天还正常，第二天整个服务就没了。要理解我下面这份清单，得先知道现在国内的 Docker 镜像源到底分哪几类。
1.1 还在正常运转的源大概分三类
第一类是云厂商个人加速器。阿里云 ACR 个人版、腾讯云内网加速这类服务，要求你先注册/登录，再拿到一个带个人标识的专属加速地址。它们的调度系统相对成熟，速度也比较稳定，但一般会有容量和频率限制，不适合大规模 CI 构建。这类是目前最靠谱的，缺点是每个账号的地址不一样，没法直接抄。
第二类是高校和开源社区镜像站。中科大、清华 TUNA、上海交大、DaoCloud 这些历史上是主力，但 2024 年以后大量收紧，很多已经不对 Docker Hub 做代理了。能通的时候速度是真快，但不保证长期可用，更适合作为替补而不是主源。
第三类是第三方公益加速和公司内网源。公司内部往往有统一的 Harbor 或自建 Registry，适合内部开发环境；第三方公益源则时好时坏，必须配合探活脚本用。如果你在公司内网，优先问问运维有没有现成的内部镜像仓库，比折腾公共源省心得多。
1.2 我的探活口径与候选清单
先说明一下我的验证方式：用curl -I https://<镜像源地址>/v2/探活，返回 200 或 401 都说明服务可能在运行；然后再实际docker pull nginx:alpine记录耗时，这样能排除“只通健康检查接口、不通数据面”的假活情况。下面这张表是我在 2026 年 9 月自己网络环境下探活的结果。
| 源名称 | 加速地址 | 类型 | 当前状态（我这里） | 适用场景 |
|---|---|---|---|---|
| 阿里云 ACR 个人加速器 | https://<你的ID>.mirror.aliyuncs.com | 云厂商 | 稳定，需登录控制台获取 | 个人服务器、Docker Desktop |
| 腾讯云内网加速 | https://mirror.ccs.tencentyun.com | 云厂商内网 | 腾讯云服务器内网稳定 | 腾讯云 CVM 等内网节点 |
| DaoCloud 加速 | https://docker.mirrors.daocloud.io | 社区公益 | 可用，偶发限流 | 临时救急、个人开发机 |
| 网易 | https://hub-mirror.c.163.com | 老牌公共 | 可探通，速度一般 | 备胎位 |
| 百度 | https://mirror.baidubce.com | 公共 | 可探通，稳定性一般 | 备胎位 |
| 中科大 | https://docker.mirrors.ustc.edu.cn | 高校 | 我的网络环境探不通 | 不建议首选 |
| 清华 TUNA | https://docker.mirrors.tuna.tsinghua.edu.cn | 高校 | 已限制 Docker Hub 回源 | 不建议首选 |
表格里写的“我这里”只是我本地网络环境的探测结果，不代表你那边也一样。不同地域、运营商、DNS 解析出来的结果差异很大，建议你按这张表跑一遍后面的探活脚本再配置。另外，像华为云 SWR 这类绑定账号的镜像服务也值得关注，但通常需要有自己的命名空间，这里就不展开说了。
1.3 为什么“看起来通，拉下来就断”
我遇到过不少这种情况：一个镜像源在浏览器里打开首页秒开，curl -I也返回 200，结果docker pull一跑就卡住。原因通常有三个层面。
DNS 层面，公共镜像站可能做了地区解析，你在 A 地能解析到合适的边缘节点，在 B 地可能就解析到了源站或已经下线的节点，速度自然天差地别。应用层面，很多源为了降低流量费用，对/v2/这种健康探测路径做了放宽处理，但真正回源拉 blob 时就暴露了限流策略。数据层面更实际：有的源只缓存了部分热门镜像，冷门 tag 要回 Docker Hub 取，Docker Hub 在境内的访问链路本身就不那么稳定，于是又慢回去了。
所以我对列表里的每个源都加了一句备注：优先缓存热门基础镜像的源，加速效果是可感知的；冷门镜像不要抱太大期望。
2. registry-mirrors 的原理与最大误区
配置镜像加速之前，我还是想花点篇幅讲讲原理。因为很多人配置完不生效，或者生效了但不明白为什么，最后要么乱改一通，要么把加速地址直接写进 Dockerfile，留下一个隐患。
2.1 一次 docker pull 的完整路径
假设你执行docker pull nginx:alpine，Docker Engine 会先去本地找镜像层，找不到就去配置的 registry（默认是 Docker Hub）拉取 manifest，再按 manifest 里的层列表逐个下载 blob，最后组装成镜像。
配置了registry-mirrors之后，Docker Engine 会把这个 mirror 当作“上游缓存代理”来用。大致顺序是：本地没有 → 请求第一个 mirror → mirror 有缓存就直接返回，没有就回源 Docker Hub → 返回镜像层并缓存到本地。所以从 Docker Engine 的视角看，加速器是一个透明的缓存代理，你的 Dockerfile 不用改，依然写FROM nginx:alpine。
打个生活化的比方：镜像加速器有点像小区门口的快递代收点。你平时不直接去快递总仓，而是让代收点帮你跑腿，它在门口囤了一批常买的包裹（缓存），常见的能直接给你，冷门的它要去总仓取，取回来再给你。代收点离你越近、囤货越多，你拿到快递就越快。
2.2 多个 mirror 是怎么“兜底”的
Docker Engine 对registry-mirrors数组是逐个尝试的。如果第一个源返回 404 / manifest unknown，它会继续尝试下一个；但如果第一个源直接超时，Docker 经常是直接报错，而不是等到超时再去切换下一个。
很多人忽略了这个顺序问题，把最先失效的公共源放在第一位，把最稳定的云厂商源放在第二位，结果就是明明配了加速，却永远在超时。我的建议是：一定要把最稳定的源放在数组最前面，探活不可靠的源放在后面当备胎，而不是反过来。
2.3 最大的误区：把加速地址写进 FROM
我见过不少 Dockerfile 长这样：
FROM docker.mirrors.daocloud.io/library/nginx:alpine这种写法的确能绕过 daemon 层面的配置，直接走第三方仓库拉取，但代价很大。一旦这个第三方源挂了，或者清理了缓存镜像，你的 Dockerfile 就会构建失败；换源时还得把所有历史镜像路径全部改一遍。我的建议是：除非只是本地临时测一个镜像，否则千万别这么干。正确姿势是让 daemon 层统一处理加速，Dockerfile 保持FROM nginx:alpine，换源只改一台机器上的daemon.json，所有镜像自动跟着变。
另一个容易踩的坑是：registry-mirrors只对 Docker Hub 生效。如果你拉的是quay.io、ghcr.io、gcr.io上的镜像，配多少国内 Docker Hub 加速器都没用，需要单独处理这些仓库的访问问题。
3. 配置实操：Linux 服务器、Docker Desktop、containerd 各有各的改法
原理讲完，下面直接上操作。不同运行时的配置入口不一样，我按 Linux 服务器、Docker Desktop、containerd/K3s/Podman 三类分别说明。
3.1 Linux 服务器上的 Docker Engine 配置
在 Linux 服务器上，Docker Engine 的配置文件是/etc/docker/daemon.json。先创建目录，再编辑文件：
sudo mkdir -p /etc/docker sudo vim /etc/docker/daemon.json写入以下内容（以阿里云专属加速器和 DaoCloud 为例，实际请替换为你自己的地址）：
{ "registry-mirrors": [ "https://<你的ID>.mirror.aliyuncs.com", "https://docker.mirrors.daocloud.io" ] }保存后重启 Docker：
sudo systemctl daemon-reload sudo systemctl restart docker这里有个细节：改了daemon.json后，最好先执行systemctl daemon-reload再重启 Docker，虽然大多数情况下直接restart docker也能生效，但按这个顺序走能让 systemd 重新读取服务配置，避免一些奇怪的问题。
3.2 快速验证：docker info 与实测拉取
重启完先确认配置是否被加载：
docker info --format '{{json .RegistryMirrors}}'如果输出里能看到你配置的地址列表，说明配置已经生效。然后挑一个体积中等、不太可能命中缓存的镜像实测，比如：
docker pull nginx:alpine如果你的机器上之前已经拉过这个镜像，速度会虚高，看不出真实效果。想要更准确，可以先docker rmi nginx:alpine清掉本地缓存，再重新拉取；或者直接拉一个冷门 tag，绕开缓存。
3.3 Docker Desktop 的入口
Windows 和 macOS 上的 Docker Desktop 修改方式类似：打开 Docker Desktop，进入 Settings（设置）→ Docker Engine，会看到一段 JSON 配置，把registry-mirrors加进去，然后点击 Apply & Restart。
{ "registry-mirrors": [ "https://docker.mirrors.daocloud.io" ] }Docker Desktop 偶尔会出现修改不生效的情况，尤其是旧版本缓存了默认配置。这时候可以重启 Docker Desktop 进程，或者查看 Docker Desktop 的日志确认是否有加载错误。另外，Docker Desktop 本身跑在 Linux 虚拟机里，某些场景下还需确认虚拟机的网络能访问到你配置的镜像源。
3.4 containerd、K3s、Podman 的对应位置
服务器上不用 Docker Engine、而是用 containerd 作为容器运行时的场景越来越常见，K3s 和很多云原生节点默认就是 containerd。配置位置完全不同。
containerd 的配置文件一般是/etc/containerd/config.toml，需要在里面增加类似如下配置：
[plugins."io.containerd.grpc.v1.cri".registry.mirrors] [plugins."io.containerd.grpc.v1.cri".registry.mirrors."docker.io"] endpoint = ["https://docker.mirrors.daocloud.io", "https://hub-mirror.c.163.com"]改完重启 containerd：sudo systemctl restart containerd。
K3s 用户改的是/etc/rancher/k3s/registries.yaml，内容示例：
mirrors: docker.io: endpoint: - "https://docker.mirrors.daocloud.io"Podman 则修改/etc/containers/registries.conf，在[[registry]]段里配置prefix = "docker.io"和location。不同版本字段略有差异，建议先看官方文档。总之，不要拿着 Docker Engine 的配置方式直接套到 containerd 上，这是我在答疑时见过最多的错误。
4. 源挂了怎么优雅自救：探活、多源、自建缓存
配置完镜像源，不等于一劳永逸。2026 年这个时间节点，公共源的状态变化非常快，我今天探活的地址，可能下周就失效。所以我会做三件事：定时探活、多源容灾、条件允许时自建缓存。
4.1 用探活脚本定期检查可用性
下面这个脚本是放在服务器上定期跑的，只依赖curl，不需要额外安装工具：
#!/usr/bin/env bash mirrors=( "https://docker.mirrors.daocloud.io" "https://hub-mirror.c.163.com" "https://mirror.baidubce.com" ) for url in "${mirrors[@]}"; do code=$(curl -s -o /dev/null -w "%{http_code}" --connect-timeout 5 --max-time 10 "$url/v2/") echo "$(date '+%Y-%m-%d %H:%M:%S') $url -> $code" done把脚本放到/usr/local/bin/check-docker-mirror.sh并加执行权限：
chmod +x /usr/local/bin/check-docker-mirror.sh然后用crontab -e加一条定时任务：
0 */6 * * * /usr/local/bin/check-docker-mirror.sh >> /var/log/docker-mirror-check.log 2>&1脚本输出的状态码这样解读：200 表示服务正常；401 表示服务存活但需要认证，这也是正常的；404 表示路径可能不对或服务未开放；000 表示连接失败或超时。如果某个源连续几次都是 000，就该考虑把它从daemon.json里移除了。
4.2 多源配置的优先级与坑
前面说过，Docker 不会在所有网络错误下都自动 fallback，所以“多源”不等于“高可用”。我的建议是：第一位置放最稳定的源（通常是云厂商专属加速器），第二第三位置放公共源。如果最稳定的源超时，Docker 报错概率很高，公共源不一定有机会被尝试到。
想要更自动化的容灾，可以把探活脚本和配置生成结合起来：脚本定期检查所有候选源，把仍然存活且速度较快的源按优先级写入/etc/docker/daemon.json，再在低峰期重启 Docker。需要注意的是，重启 Docker 会让正在运行的容器中断，生产环境千万别在业务高峰期自动重启。
4.3 自建内网 Registry 当缓存
如果团队内部有大量 Docker 节点，与其依赖公共源，不如自己部署一个缓存型 Registry。用 Docker 自带的registry:2镜像就能实现：
mkdir -p /data/registry docker run -d -p 5000:5000 --name registry-mirror \ -e REGISTRY_PROXY_REMOTEURL=https://registry-1.docker.io \ -v /data/registry:/var/lib/registry \ --restart=always \ registry:2REGISTRY_PROXY_REMOTEURL指定了上游仓库地址，也就是 Docker Hub。启动之后，内网其他节点只要把registry-mirrors指到这台 Registry 的地址，就能共享缓存，第一次拉取慢一点，后续节点再拉就直接命中内网缓存，速度比任何公共源都稳定。
如果这台 Registry 没有配 HTTPS，需要在客户端daemon.json里加一行：
{ "registry-mirrors": ["http://<registry-ip>:5000"], "insecure-registries": ["<registry-ip>:5000"] }或者在内网 DNS/网关层给 Registry 配好证书，避免用 insecure 模式。我个人建议有条件就直接配证书，省得后续排查各种 TLS 问题。
5. 加速之外还能做些什么：镜像瘦身、离线迁移和 digest 锁定
解决了“拉不动”的问题，还有几个和镜像获取效率相关的习惯，我在实际项目中受益很大，一并分享出来。
5.1 用 docker save / load 做离线搬运
如果服务器在很差的网络环境里，在线拉取已经严重影响了交付进度，可以在一台网络环境好的开发机或跳板机上先拉好镜像，再打包搬运：
docker pull nginx:alpine docker save nginx:alpine | gzip > nginx-alpine.tar.gz scp nginx-alpine.tar.gz user@target-server:/tmp/目标服务器上解压导入：
gunzip -c /tmp/nginx-alpine.tar.gz | docker load这样只依赖一跳网络传输，不需要在目标服务器上反复重试。要注意docker save默认保存的是当前节点架构的镜像，如果目标服务器是 ARM，而跳板机是 x86，需要提前用docker pull --platform linux/arm64 nginx:alpine指定架构。
5.2 多架构镜像按需拉取
现在 ARM 服务器、树莓派、M 系列 Mac 和 x86 机器混用很常见。Docker Hub 上很多官方镜像都支持多架构，但默认行为是自动拉取当前平台架构，不一定会把需要的架构准确拉全。如果你在做镜像迁移，最好显式指定平台：
docker pull --platform linux/amd64 nginx:alpine docker pull --platform linux/arm64 nginx:alpine指定平台还有一个好处：有些镜像的特定架构层在镜像源里根本没被缓存，显式指定后能看出到底是源的问题还是架构的问题，排查效率高很多。
5.3 用更小的基础镜像，少拉就是快
镜像加速只是让拉取链路更顺畅，镜像本身的体积依然决定了拉取耗时。同样的 nginx，官方nginx:latest和nginx:stable-alpine体积差了不少；Python 基础镜像里，python:3.12-slim也比完整版小得多。如果对底层 glibc 没有硬性要求，优先选 alpine 或 slim 变体，既省带宽又省磁盘。
想直观看到镜像每一层的大小，可以用docker history：
docker history nginx:alpine在确定基础镜像前，先看一眼层的体积，比上线后才发现镜像巨大要舒服得多。
5.4 用 digest 锁定镜像，避免镜像源漂移
公共镜像源本质上是一个个缓存代理，理论上可能出现“同 tag 不同镜像”的情况。对生产环境要求高的朋友，建议把镜像锁定到 digest：
docker pull nginx:alpine@sha256:xxxxxxxxxxxxxxxxxxxx这样即使镜像源缓存漂移，或者有人恶意篡改，拉取时也能校验内容一致性。日常开发可以不用，但一旦进入生产发布链路，digest 锁定是成本最低、收益最明显的一道防线。
一路写下来你会发现，2026 年国内 Docker 镜像源这件事，核心并不是找到某个“永远可用”的神级地址，而是形成一套自己的探活、配置和容灾流程。我个人现在的做法是：每台服务器上放一个探活脚本，定时跑一遍，发现可用源变化就在维护窗口更新daemon.json；同时在公司内部固定维护一台缓存型 Registry，公共源只是应急兜底。这套组合下来，即使今天某个源挂了，明天也不至于全公司一起卡在docker pull上。希望这份经验对你有用。
