2026最新Docker国内镜像源加速列表与配置实操指南

前两天有个朋友跟我说，他把项目打包成 Docker 镜像后，在服务器上docker pull

一个基础镜像，愣是等了十几分钟没动静，最后直接超时失败。这不是个例，但凡在国内网络环境下用过 Docker 的人，基本都经历过“镜像拉不下来”“进度条半天不走”的折磨。原因很简单，Docker Hub 的服务器在海外，默认走官方源拉取镜像，网络链路上动不动就丢包、限速，尤其是那些体积动辄几百 MB 甚至几个 GB 的镜像，拉取体验可以说是灾难级的。

解决这个问题的核心手段就是配置国内镜像源，也就是把 Docker 的默认镜像仓库替换成国内可访问的加速地址。我最早接触到镜像加速这个概念，还是在用旧版本 Docker 的时候，当时大家普遍用的是某云厂商提供的公共加速器，后来一部分地址陆陆续续失效了，社区里就开始出现了各种“最新可用镜像源”的整理帖。这篇文章是我在 9 月 8 日重新梳理过的版本，针对 2026 年当前的可用性做了实测，整理了一份Docker 国内镜像源加速列表

，并且把配置方式、验证方法、常见坑都一并写清楚，方便你直接照着操作。

这篇文章适合谁看？如果你用过docker pull

但经常卡住，或者刚接触 Docker 想少走弯路，又或者你所在团队需要批量部署镜像、对拉取速度有硬性要求，那这份清单和实操指南都能帮上忙。文章不会只丢给你一串地址，还会解释这些加速地址的工作原理、为什么有些地址用着用着就失效了，以及遇到问题该怎么排查。

1. 为什么要用国内镜像源：镜像拉取慢的根源与加速原理

1.1 镜像仓库的“就近访问”逻辑

先梳理一个基本概念。Docker 镜像不是单个大文件，而是一层层只读文件系统的集合，每一层对应 Dockerfile 里的一条指令。docker pull

的时候，Docker 客户端会去镜像仓库里拉取这些层，然后组合成最终的镜像。默认情况下，这个仓库就是 Docker Hub，官方仓库的服务器分布在海外，从国内直连的路径长、出口带宽小，再加上频繁的链路抖动，拉取一个几十 MB 的层都可能失败重试。

国内镜像源解决的本质问题是“就近访问”。加速器本质上是一个反向代理或镜像缓存服务，它在国内有服务器节点，你配置了registry-mirrors

之后，Docker 客户端在拉取镜像时会优先访问这个国内地址，而不会直接去连官方仓库。可以把它类比成一个社区代收点：你家楼下有了快递代收点，就不必每次都等快递员从遥远的仓库专门跑一趟，速度自然快得多。

1.2 为什么很多加速地址说失效就失效

这里想多说一点，因为太容易踩坑了。很多人网上找了一个镜像源地址，配上去之后发现时好时坏，今天能拉明天不能拉，以为是自己的配置出了问题，其实很可能是对方服务端的限制。国内镜像源大多面向公众免费开放，服务器成本很高。运营者通常会设置拉取频率上限、限制 IP 归属地、或者限制只对特定网络环境开放。一旦某个地址被大量滥用，服务端就会收紧策略，反映到客户端就是“403 Forbidden”或者连接超时。

另外，Docker 本身对 mirror 地址的检测机制也比较严格。当你配置了多个registry-mirrors后，Docker 会按照顺序逐个尝试，遇到某个镜像源不稳定或不存在，它会自动跳过并尝试下一个。但如果所有源都失效，拉取就会直接失败。所以有一个相对规律：镜像源列表需要定期更新和维护

，不存在一劳永逸的配置。

1.3 加速源能做到什么、不能做到什么

心里有底之后再说加速源的边界。它能加速的是 Docker Hub 官方镜像，以及常见的开源镜像，比如nginx、mysql、redis、ubuntu

这些。对于某些私有仓库或者自建 Harbor，配置 mirror 是不会生效的。另外，加速源只优化“拉取”过程，不会加速“推送”过程。你想把自己构建的镜像推到 Docker Hub，该慢还是慢，这是另一个话题了。

还有一点要留意，不同的镜像源在层同步机制上有差别。有的源会实时回源 Docker Hub，有的则是定时缓存。这意味着你可能在拉取一个刚发布的最新 tag 时遇到版本滞后的情况，比较少见，但会有。

2. 2026 年 9 月实测可用的国内镜像源地址清单

2.1 当前可用列表与使用建议

这份列表是我在 9 月 8 日逐一手动验证过的，验证方式很简单：对每个地址发起一次docker pull hello-world或docker pull nginx:alpine

，能成功拉取并返回状态的标记为可用。需要特别说明的是，镜像源可用性随时可能变化，建议你配置时至少写 3 个地址作为备选，不要只填一个。

这里讲一个我实际测试中的细节：docker.1ms.run和docker.xuanyuan.me这两个地址在连续拉取多个镜像时表现比较稳定，速度能维持在一个可接受的区间；docker.m.daocloud.io在国内部分网络环境下偶尔会出现证书校验异常，如果遇到可以尝试在后面加一层registry-mirrors顺序调整来规避；dockerproxy.net和hub.rat.dev

适合作为备用，不建议作为首选。

2.2 如何自己判断一个镜像源是否“真可用”

网上流传的镜像源地址很多，但不少是残废的——能打开首页，但真正拉取镜像时却报 403。教大家一个快速验证的方法，不需要真的去配 Docker：

curl -I https://docker.1ms.run/v2/

如果返回的 HTTP 状态码是200或者401，说明这个地址是活的。/v2/是 Docker Registry HTTP API V2 的基础路径，服务端如果不返回404，就代表它对 Docker 客户端是可用的。如果返回403、502

、超时，那就直接换下一个。

这个方法是我在实际排查时用得最多的，比盲配 Docker 配置文件高效得多。此外还可以用curl获取某个具体镜像的 manifest 信息，不过对普通使用来说，检测/v2/

就够了。

2.3 不要盲目相信“永久可用”的说法

很多人在论坛里看到“某某镜像源 2026 永久可用”的帖子，配置完几天后又失效，然后又回去骂娘。我的建议是，但凡看到“永久”两个字，先在心里打个折。公共镜像源的生命周期受到外部政策、运营成本、域名备案、网络环境等多重因素影响，谁也无法承诺永久。比较理性的做法是定期更新自己的镜像源列表，要么每季度手动检查一次，要么关注一些持续维护的社区文档。

我自己维护了一个脚本，每个月跑一遍，把常见的镜像源地址全部curl

一遍，自动生成一份“可用性排名”，配到服务器上之前先看一眼。后面会把脚本思路放在文章里，你可以照着做一个自己的版本。

3. Docker 配置国内镜像源完整实操：Linux 与 Windows 双端覆盖

3.1 Linux 环境下配置daemon.json

在 Linux 服务器上配置镜像源，修改的是 Docker 守护进程的配置文件/etc/docker/daemon.json

。如果你之前没手动建过这个文件，默认情况下它是不存在的，建一个就行。

具体操作步骤：

1. 编辑配置文件：

sudo mkdir -p /etc/docker sudo vim /etc/docker/daemon.json

1. 在文件里写入以下内容：

{ "registry-mirrors": [ "https://docker.1ms.run", "https://docker.xuanyuan.me", "https://docker.1panel.live", "https://hub.rat.dev", "https://docker.m.daocloud.io", "https://dockerproxy.net" ] }

1. 重启 Docker 服务：

sudo systemctl daemon-reload sudo systemctl restart docker

1. 验证配置是否生效：

docker info | grep -A 6 "Registry Mirrors"

看到配置的地址列表出现在输出里，就说明生效了。然后随便拉一个镜像试试实际速度：

docker pull nginx:alpine

整个流程走下来，正常情况下十几秒内就能拉完。注意，如果 Docker 的内存占用很大或者你开了很多容器，重启服务会中断所有运行中的容器，建议选择业务低峰期操作，或者先用docker ps

看一眼有没有重要的容器在跑。

3.2 Windows 与 Docker Desktop 的配置路径

Windows 上如果你用的是 Docker Desktop，配置方式跟 Linux 有点不一样。Docker Desktop 有自己的配置文件，路径通常在%UserProfile%\.docker\daemon.json

，但更推荐在 GUI 界面里操作，不容易出错。

打开 Docker Desktop，在右上角找到设置（齿轮图标），进入Docker Engine标签页。这里有一段 JSON 配置，默认有一个{}或者基础配置项，把上面的registry-mirrors配置合并进去，然后点击Apply & restart

即可。

这个页面本质就是在编辑 Docker 守护进程的配置，只是多了 Docker Desktop 的重启逻辑。部分旧版本 Docker Desktop 可能没有可视化Docker Engine入口，或者配置路径有差异，遇到的时候优先去查 Docker Desktop 自带的配置文档，不要乱改系统级的/etc/docker/daemon.json

，因为 Docker Desktop 运行在 WSL2 后端上，宿主机的配置文件未必会生效。

我这里补充一个超高频的问题：WSL2 环境下配置镜像源后不生效，大概率是因为 Docker Desktop 在 WSL2 发行版里也部署了一个 Docker 上下文，命令行里执行docker info

连的还是 Docker Desktop 的守护进程，此时配置文件路径以 Docker Desktop 的设置为准。

3.3 配置多个镜像源时 Docker 的选取机制

很多人会有疑问：配置了多个地址，Docker 是怎么选的？是选第一个能用的吗？并不是。Docker 的registry-mirrors机制实际上是并行尝试与顺序回退的组合

。更准确地说，Docker 在拉取镜像时会逐个尝试 mirror 地址，如果当前地址返回错误或超时，会切换到下一个。

这里面的超时时间比较长，所以在某些极端情况下，你配置了 6 个镜像源，但第一个已经失效，Docker 可能会卡在第一个地址上等很久，最终才跳过。这也是为什么建议把当前最稳定的地址放在最前面，失效地址尽量不要留着占位置，定期清洗列表本身就是维护工作的一部分。

3.4 不需要修改 Docker 配置的临时加速方案

如果只是临时拉一次镜像，不想动服务器的全局配置，还有另一个思路：使用--registry-mirror参数临时指定。不过严格来说，docker pull本身不支持--registry-mirror这个参数，它只在 docker daemon 启动时有效。更简单的方式是通过设置环境变量DOCKER_HOST

指向一个已经配置好加速器的远端 Docker 实例，但这就不是同一台机器的操作了。

所以我的建议是，该改配置文件就改配置文件，一次性配好，后面长期受益。动手之前可以先备份原配置：

sudo cp /etc/docker/daemon.json /etc/docker/daemon.json.bak

万一发生配置错误导致 Docker 启动失败，还可以恢复回去。这个习惯我一直保持，别嫌多此一举，关键时刻能救命。

4. 加速配置后仍然拉取失败的排查思路与避坑技巧

4.1 典型失败场景：证书校验与“握手失败”

配置好镜像源以后，偶尔会遇到类似下面的报错：

Error response from daemon: Get "https://docker.1ms.run/v2/": tls: failed to verify certificate: x509: certificate signed by unknown authority

看到x509

基本可以判断是证书链路问题。有些镜像源服务端做了 HTTPS 证书的代理转发，而 Docker 客户端校验证书时发现签发者不在系统信任链中，就会直接中断连接。

遇到这种问题，有几种处理思路。先确认一下镜像源的官方文档里有没有提供证书下载地址，如果有，下载后放到系统信任目录，执行update-ca-certificates重新加载；如果镜像源本身并不提供证书，那就换一个地址，不要为了一个加速源去修改 Docker 的insecure-registries

配置。

4.2insecure-registries

是双刃剑，不建议随意使用

真的不建议为了拉取镜像去配置insecure-registries

。这个参数的作用是告诉 Docker“访问这些地址的时候，不要校验 HTTPS 证书，可以用 HTTP 访问”。看起来解决了问题，但同时也意味着镜像在传输过程中没有了加密保护，中间人攻击风险瞬间拉满。万一你往一个不可信的镜像源推送了包含业务代码的镜像，后果是灾难性的。

我的原则是：宁可不用，也不要把安全防线轻易拆掉

。镜像源地址失效了可以换，证书有问题也可以换，但 Docker 守护进程的信任链一旦被破坏，影响的是这台机器上所有容器的安全性。

4.3 检查 Docker 能否访问外网资源

镜像源本身没问题、配置也没问题，但拉取还是失败，这个时候要检查的不是 Docker，而是网络出口本身。国内一些云服务器的安全组默认只放行 80、443 等常用端口，如果 Docker 需要的镜像层下载端口被安全组拦截，就会出现“拉取超时”的假象。

排查思路比较简单：

1. 先用curl访问一个镜像源地址，看通不通：

   curl -I https://registry-1.docker.io/v2/

2. 再ping一下公网域名，排除 DNS 解析问题。
3. 在配置了镜像源的情况下，如果curl能通但docker pull不行，大概率是 Docker 守护进程的代理配置有问题，查看一下~/.docker/config.json里有没有设置代理，或者服务级环境变量里有没有HTTP_PROXY。

强调一个容易忽略的点：很多人在 Linux 服务器上为其他软件配置过 HTTP 代理，代理变量会影响到子进程的环境。如果 Docker 守护进程是通过 systemd 启动的，可能继承了一组代理变量，导致拉取国外镜像时先走代理、再走镜像源，链路更长更容易出问题。

4.4 如何验证镜像源真正被使用而不是走了默认源

有时候配完registry-mirrors

，拉取速度还是很慢，这时怀疑点不是镜像源失效，而是 Docker 根本没走镜像源。可以这样确认：执行一次拉取，同时观察 Docker 守护进程日志中目标地址的变化。

sudo journalctl -u docker --since "5 minutes ago" | grep "docker.io"

如果日志里出现了docker.io字样，说明请求还是回到了官方仓库。此时大概率是配置没有加载成功，或者 Docker 服务没有正确重启。再确认一次docker info输出的Registry Mirrors

列表，不要只凭记忆判断。

4.5 常见问题速查表

把我在过往项目中遇到的高频问题整理成一个速查表，方便你按图索骥：

现象	可能原因	处理方式
docker pull卡在等待状态	镜像源超时或不可用	换用其他镜像源，减少镜像源数量并优先稳定源
报错x509: certificate signed by unknown authority	镜像源证书链异常	检查镜像源公告，必要时换源
报错403 Forbidden	镜像源拒绝了当前 IP 或超出频率限制	更换镜像源，或稍后再试
配置了镜像源但速度依旧慢	未重启 Docker 服务或配置未生效	执行sudo systemctl restart docker后重新验证
docker info看不到 Registry Mirrors	daemon.json 路径错误或 JSON 语法错误	检查文件路径与格式，用python -m json.tool校验
拉取特定镜像超时	镜像体积大，且镜像源缓存不完整	换拉取时间，或选择体积更小的 tag 版本

4.6 定期维护：写一个自动检测镜像源可用性的小脚本

前面说过我每个月会手动验证一次镜像源，后来觉得麻烦，就写了一个简单的 Bash 脚本，用curl检查所有地址的/v2/响应状态，再用awk和sort

输出可用性排名。逻辑不复杂，核心代码如下：

#!/bin/bash mirrors=( "https://docker.1ms.run" "https://docker.xuanyuan.me" "https://docker.1panel.live" "https://hub.rat.dev" "https://docker.m.daocloud.io" "https://dockerproxy.net" ) for mirror in "${mirrors[@]}"; do status=$(curl -o /dev/null -s -w "%{http_code}" --connect-timeout 5 --max-time 8 "$mirror/v2/") if [ "$status" = "200" ] || [ "$status" = "401" ]; then echo "[OK] $mirror (HTTP $status)" else echo "[FAIL] $mirror (HTTP $status)" fi done

脚本原理很简单：curl -w "%{http_code}"会输出 HTTP 响应码，200和401都算服务端正常响应。执行后你就能清楚看到哪些镜像源还能用。这个脚本不会伤害任何解析链路，/v2/

是 Registry API 的规范路径，属于标准请求。

我执行完生成的可用性列表，再去更新服务器上的daemon.json

，这样就避免反复重启 Docker 服务。你也可以加一个计划任务，每月自动跑一次并把结果发送到邮箱或消息通知里，自动化起来之后，镜像源维护就变成了一件没有存在感的定期小事。

5. 从 Docker 镜像源扩展到更多生态的加速思路

5.1 除了 Docker Hub，还有哪些镜像仓库可以加速

镜像加速的思路可以复制到其他生态里。很多国内用户不只是拉 Docker 镜像慢，还经常从quay.io、ghcr.io

拉取特定项目镜像，或者从 Python 的 PyPI、Node 的 npm 仓库下载依赖包。加速原理大同小异——都是把海外的软件仓库前置到国内节点，缩短链路。

比如 Python 的 pip 就支持-i参数指定镜像源，常见的有清华 TUNA 镜像、阿里云镜像；Node.js 的 npm 可以设置npm config set registry切换到国内镜像；Anaconda 的 conda 也可以配置channels

指向国内镜像地址。这些镜像源和 Docker 国内镜像源没有直接关系，但维护思路完全一致：写进配置后不定期验证可用性，不用频繁更新。

5.2 自建镜像缓存：内网环境的终极方案

如果团队内网环境规模比较大，或者有多台服务器经常拉取相同镜像，光靠公共镜像源还是不够稳定。这时候可以考虑自建镜像缓存服务，常见方案是部署一个Harbor

，开启它的仓库代理功能。它可以根据配置，把需要的外部镜像缓存到本地，内部服务器拉取镜像时直接访问内网 Harbor 即可。

这个方案的优点是彻底摆脱外部源不稳定的问题，缺点是运维成本高，需要单独一台服务器作为缓存节点，还要考虑磁盘存储、垃圾回收和证书管理。对小型项目来说，用公共镜像源加几个备用地址就够了，没必要一上来就上自建。

5.3 最新热词里的 Ollama 镜像源问题

最近热词里频繁出现“ollama国内镜像源”，有人拉取 Ollama 模型时也会尝试用 Docker 镜像源加速。严格来说，Ollama 镜像源的原理和 Docker 类似，但它加速的是模型文件，不是容器镜像。模型文件动辄几个 GB，如果本地网络条件不好，同样会遇到拉取中断的问题。

如果你只是要部署 Ollama，直接参考官方安装脚本即可；如果你要拉取模型，建议使用官方的模型库，并确保磁盘空间充足。这里不推荐把 Docker 的 registry mirror 配置错用到 Ollama 上，两者协议不同，配置方向错误不仅不能加速，反而可能引发异常。

6. 写在最后：镜像源维护是日常工程习惯的一部分

我做了这么多年容器化相关的工作，对镜像源最大的感受是：它不是配一次就完事的静态资源，而是需要持续观察的动态服务

。过去经常会看到有人因为一个镜像源失效，临时抱佛脚去搜索“最新可用列表”，然后继续踩同样的坑。比较实际的做法，是把镜像源验证、更新变成自己日常工作流的一部分，哪怕每个月只花十分钟跑一遍脚本，也比临时排查省心得多。

个人建议是，在你的服务器上准备一个统一的 Docker 配置库存放这些公共配置，新服务器初始化时直接复制过去，验证完再启动服务。遇到镜像源失效，先跑一遍脚本，确认可用的地址后再更新配置，不要盲目重启 Docker。一路实操下来，你会发现镜像拉取不再是瓶颈，真正阻塞你的反而是应用本身的构建和部署逻辑。

最后再分享一个小技巧：如果你的镜像源列表已经配置得很干净，但拉取某些镜像时还是慢，可以检查一下是否用了特别大的基础镜像，有些镜像的多个 layer 加起来可能有数 GB，这类下载慢是物理层面的问题，再好的加速器也帮不了太多。选镜像时优先选择 Alpine 等轻量基础镜像，既减小体积，也减少网络传输时间。这个思路和配置镜像源同样重要。