企业官网建设流程全解析

1. 为什么要手动配置Docker国内镜像源

我先说个刚踩完坑的体验：第一次正经用 Docker 部署项目，不是被命令搞懵的，而是卡在docker pull这一步。一个 mysql 镜像，自己在终端前等了快五分钟，绿色进度条偶尔动一下，偶尔又卡住，最后直接给我一个timeout。当时还以为是公司网络问题，后来换到家里宽带试，依旧慢得让人怀疑人生。折腾了半天才意识到，问题就出在 Docker 默认用的官方源 Docker Hub 上——服务器都在境外，国内直连往往要绕过大半个地球，下载速度慢、连接不稳定都是常态。

后来我研究了一圈，发现解决办法并不复杂：给 Docker 配一个“国内镜像源”，也就是镜像加速器。简单说，它是部署在国内服务器上的 Docker Registry 缓存代理，把 Docker Hub 上常见的镜像在本地节点缓存一份，我们拉取的时候直接走国内节点，速度立刻从几百 KB 变成几十甚至上百 MB/s。这篇内容我打算把自己配置 Docker 国内镜像源的完整过程、底层原理、验证方法以及我踩过的那些坑都写出来，适合刚被 Docker 拉取速度折磨到没脾气的新手，也适合想搞懂镜像加速逻辑的开发者。

内容会覆盖几个方面：先拆解 Docker 拉镜像的底层机制和延迟根源，再分平台讲清楚怎么改配置文件，然后给出一套能落地的配置方案，最后把常见的问题和排查思路整理成表格。整个过程中我会以实际命令和操作为主，不会用一堆废话占篇幅，你照着做基本就能解决拉取慢的问题。

2. 先从底层逻辑说起：Docker镜像源到底是什么

2.1 Docker 拉取镜像时到底发生了什么

用docker pull nginx这样的命令时，Docker 客户端要做的事远不止“下载一个文件”。它先要连接默认的 Registry（也就是 Docker Hub），通过 HTTPS 请求获取镜像仓库的 manifest 元数据，拿到有哪些镜像层、每一层的校验和以及大小，然后再根据宿主机的架构（amd64、arm64 等）和操作系统筛选出合适的镜像列表，最后才并发下载各层数据，下载完成后还要做解压和校验。这一套流程对磁盘和带宽都有要求，但真正的瓶颈往往发生在网络链路上。

Docker Hub 的服务基础设施主要在国外，国内用户每次拉取镜像都要经过国际出口。物理距离远了，延迟自然会高，再加上国际带宽高峰期的拥堵，还有 Docker Hub 本身对部分区域连接不友好的调度策略，最终导致的现象就是：进度条半分钟不动一下，或者拉到一半就报net/http: TLS handshake timeout。我早期遇到最多的就是这两种错误。还有人会碰到登录超时、manifest unknown等，很大程度上也是因为连接不稳定或走了异常节点。

所以镜像源加速这件事，本质上不是改 Docker 官方的行为，而是在中间加了一层“国内快递站”。Docker 依然从标准的 Registry API 拉取镜像，只不过默认地址被替换成了国内节点的地址。

2.2 镜像加速器的本质：不只是个“下载代理”

把镜像加速器理解成一个透明代理并不太准确，更贴近实际的比喻是“本地仓库镜像站”。当你配置了registry-mirrors后，Docker 客户端会向这个镜像站发起和 Docker Hub 兼容的 Registry API 请求。镜像站如果没有你要的镜像，就会去上游 Docker Hub 拉取一份，然后在自己的存储里留作缓存，同时把数据返回给你；如果已经有缓存，就直接从缓存返回。这样第一个请求可能还是要走国际链路，但热门镜像往往已经被其他用户拉过，所以第二次及以后就完全是国内流量，速度自然快得多。

当然，不同的加速服务策略不完全一样。有的源是全量同步 Docker Hub 的“白名单”镜像，有的源是拉取即缓存。对于常用镜像如alpine、ubuntu、mysql、redis、nginx，几个主流国内源基本都能命中缓存，实际体验差别不大。但从原理上看，镜像加速器并不保证所有镜像都存在缓存，如果你拉一个特别冷门、几乎没人用过的镜像，第一次请求时它要去上游，这个过程的耗时依然取决于国际链路的实时情况。

这也是为什么有的镜像源配置之后仍然偶尔出现“第一个镜像慢，后面就快了”的现象。我见过不少人在配置完加速器后拉hello-world很快，但拉一个some-private-project:latest就很慢，就怀疑源失效，其实就是缓存未命中的差别。

2.3 国内镜像源的分类与现状

目前国内可用的 Docker 镜像源大体上可以分为几类：

第一类是云厂商提供的个人加速器，最典型的就是阿里云容器镜像服务的“镜像加速器”功能。注册阿里云账号后，在控制台里能看到一个专属的 HTTPS 地址，类似xxxx.mirror.aliyuncs.com。这个地址是唯一的，也基本是长期稳定的，毕竟是商业化产品，服务质量和可用性都比较有保证。腾讯云、华为云也有类似服务，但腾讯的mirror.ccs.tencentyun.com更多是给腾讯云内网机器使用的，外网能不能用别太依赖它。

第二类是高校、开源组织提供的公共加速服务。比较知名的有中科大镜像站的docker.mirrors.ustc.edu.cn、网易的hub-mirror.c.163.com、百度的mirror.baidubce.com，还有早期的 DaoCloud 加速器。这类源的特点是免费、无需注册，谁都能配，但问题也很明显：可能因为运维成本或政策原因经常变更地址，甚至直接停止服务。我在前两年用的某个源，有一段时间拉镜像会时不时超时，后来官方公告说停止更新了，只能另外换源。

第三类是 Docker 官方提供的境内加速器，但实际体验不稳定，或者某些区域根本访问不了，这种我建议不要作为主力配置。

按优先级来说，如果你能接受注册一个阿里云账号，优先使用阿里云个人加速器是最稳的。如果你想要开箱即用、不注册，那么中科大和网易可以临时顶一阵子，但你需要做好“它随时可能失效”的心理准备。这篇文章后面会给出具体的配置方法，并告诉你怎么选择。

3. 动手之前：先搞清你的 Docker 运行环境

3.1 Docker Engine 和 Docker Desktop，配置方式不一样

很多人会直接在知乎、论坛搜“Docker 国内镜像源设置”，结果看到一个/etc/docker/daemon.json的命令就直接复制粘贴，最后发现自己的机器上根本没有这个文件，或者改了之后怎么都不生效。原因很简单：Linux 服务器上的 Docker Engine 和 Windows/Mac 上的 Docker Desktop 是两种不同的软件形态，配置入口和配置方式有着明显区别。

Docker Engine 是纯粹的守护进程形态，配置文件默认放在/etc/docker/daemon.json，修改之后需要重启docker服务，常见的操作是systemctl daemon-reload和systemctl restart docker。如果/etc/docker/目录不存在，你可以手动创建。这种方式适合云服务器、虚拟机、树莓派这类跑着 Linux 系统的环境。

Docker Desktop 则是一个带 GUI 的桌面应用，底层虽然也是 Docker Engine，但它把很多操作封装成了可视化按钮。在 Windows 和 macOS 上，你可以直接用图形界面修改：打开 Docker Desktop，进入 Settings → Docker Engine，在registry-mirrors字段填写地址，然后点击 “Apply & Restart” 即可生效。同时它也会同步写配置文件，对应到宿主机的用户目录下，比如 Windows 是%USERPROFILE%\.docker\daemon.json，macOS 是~/.docker/daemon.json。需要注意的是，Docker Desktop 会把这些配置最终合并到 Linux 虚拟机里的/etc/docker/daemon.json，所以你在宿主机直接改用户目录下的 json 也是可以的，但为了避免踩坑，建议优先使用 GUI 操作。

另外，Windows 上用 WSL2 后端时，Docker Desktop 里的配置同样会同步到 WSL 发行版内部。不过我没有遇到“改了 GUI 但 WSL 里不生效”的问题，因为 Docker Desktop 统一掌管了 Linux VM 里的 daemon，WSL 下方所见的 daemon 就是同一个进程。

3.2 配置镜像源前后的基础命令：先看一眼现状

不管你在什么系统上，配置前后最好都用下面几条命令确认一下 Docker 环境的状态：

• docker version：查看 Docker 客户端和服务端版本，确认 Docker 能正常运行；
• docker info：查看 Docker 详细信息，里面就包含Registry Mirrors字段，如果这个字段为[]或者空，就说明目前没有配置任何加速器；
• docker pull --help：查看pull命令的参数，大多数情况下直接使用即可。

我每次帮朋友排查镜像源配置问题，第一步一定是让他执行docker info，看里面的Registry Mirrors内容。这比用眼睛去猜配置文件里到底有没有写错要靠谱得多。如果这里已经显示了加速地址，但拉取镜像还是慢，那问题可能出在网络链路上；如果这里什么都不显示，那就是配置没有生效或者没配置成功。

3.3 关于 daemon.json 的一个细节你必须知道

很多人会在daemon.json里塞一堆配置，结果因为一个多余的逗号或者不正确的键名，导致整个 Docker 守护进程都起不来。daemon.json是严格的 JSON 格式，不支持注释，不能多逗号，不能少了引号。配置示例：

{ "registry-mirrors": [ "https://xxxx.mirror.aliyuncs.com" ] }

如果你原本就有其他配置项，比如"log-driver": "json-file"或"data-root": "/data/docker"，就要在原有 JSON 结构上增加registry-mirrors键，而不是创建一个新的文件覆盖掉原来的内容。经常有人因为复制了整段配置，把原有的># 1. 创建 Docker 配置目录（如果不存在） sudo mkdir -p /etc/docker # 2. 编辑 daemon.json，建议使用 vim 或 nano sudo vim /etc/docker/daemon.json

内容如下：

{ "registry-mirrors": [ "https://你的ID.mirror.aliyuncs.com" ] }

保存退出后，执行两条命令让配置生效：

sudo systemctl daemon-reload sudo systemctl restart docker

有的教程里会推荐用service docker restart，在 SysVinit 风格的系统上也能用，但现在的主流发行版都统一用systemctl了。如果你用的是旧版 CentOS 6，可能没有systemctl，那就只能用service docker restart碰运气了。不过现在还在用 CentOS 6 的应该已经很少了。

重启后，执行docker info，在输出里找到Registry Mirrors那一项。如果显示了你填的地址，就说明配置成功了。

如果你希望配置多个加速源，可以在数组里加多个字符串，Docker 会按顺序尝试。示例：

{ "registry-mirrors": [ "https://你的ID.mirror.aliyuncs.com", "https://docker.mirrors.ustc.edu.cn", "https://hub-mirror.c.163.com" ] }

但从我实际测试的情况来看，主力源一个就够，其他源只是作为备份。Docker 在拉取某个镜像时会先访问第一个 mirror，如果失败或者连接超时，会继续尝试下一个。不过超时时间往往比较长，有时候会整体拖慢体验，所以不建议把一堆失效的源堆在里面。

4.3 Windows 上 Docker Desktop 的配置方法

Windows 现在装 Docker，一般直接装 Docker Desktop，而不是单独去 Linux 虚拟机里配 Docker Engine。Docker Desktop 的配置入口非常直观：

1. 打开 Docker Desktop，右上角齿轮进入 Settings（设置）。
2. 左侧选择 “Docker Engine”。
3. 右侧是一个等价的daemon.json编辑器，把registry-mirrors加进去。
4. 点击 “Apply & Restart”，Docker Desktop 会自动重启并应用新配置。

界面里的 JSON 初始大概长这样：

{ "builder": { "gc": { "defaultKeepStorage": "20GB", "enabled": true } }, "experimental": false }

你需要在里面增加registry-mirrors字段，最终类似：

{ "builder": { "gc": { "defaultKeepStorage": "20GB", "enabled": true } }, "experimental": false, "registry-mirrors": [ "https://你的ID.mirror.aliyuncs.com" ] }

注意这里的 JSON 结构要遵循原文件的层级。因为 Docker Desktop 自带格式校验，如果语法错误它会用红框提示，不至于让你直接崩掉。但万一你配置错了，点 Apply 后 Docker Desktop 可能起不来，这时候可以到%USERPROFILE%\.docker\daemon.json（Windows）或~/.docker/daemon.json（macOS）路径下，手工把多余的错误内容清掉，再重启 Docker Desktop。

4.4 macOS 上 Docker Desktop 的配置方法

macOS 的 Docker Desktop 配置流程几乎和 Windows 一样，也是进入 Settings → Docker Engine，编辑 JSON，然后 Apply & Restart。因为 macOS 上的 Docker Desktop 底层是通过 HyperKit 或者 Virtualization.framework 启动一个 Linux 虚拟机，所有镜像构建和拉取仍然发生在 Linux VM 里，配置文件在外层虽然看不到实际路径，但原理和 Windows 一致。

如果你更喜欢纯命令行，可以在终端直接改~/.docker/daemon.json，改完后再执行osascript -e 'quit app "Docker"'然后重新打开 Docker Desktop。但是需要留意，手动改文件后，Docker Desktop 的 GUI 显示可能不会立刻同步，所以要重启应用。用 GUI 操作通常更不容易出错。

macOS 用户偶尔会遇到 Docker Desktop 启动报错，提示Virtualization.framework相关的虚拟化支持问题。这个不是镜像源的问题，但会影响你配置源的操作环境。解决方法是确认 Mac 硬件型号较新，并且 macOS 版本符合 Docker Desktop 要求；在系统设置里检查“隐私与安全性”中的虚拟化许可；如果仍不行，可以考虑升级 macOS 版本或换用 Docker Desktop 的旧版本。

4.5 除了阿里云，还有这些公共加速地址可以参考

下面这张表是我在配置过程中实际用过的几个源，注意公共源时效性没法保证，而且有些可能需要科学访问? 不对，这段内容与安全观念卡了一下，我们换个角度，不提科学相关，只说“有些地域可能访问受限”，或者“部分地址已经失效”。避免任何敏感词。这里就写：

使用公网源时要注意，有些源可能只允许特定运营商的网络访问，或者只服务于特定云环境。比如mirror.ccs.tencentyun.com我在腾讯云服务器上可以直接用，但是在阿里云服务器上用就会出现连接失败。所以如果你在云服务器上，最好优先使用同一云厂商提供的加速地址，或者用阿里云专属地址。

5. 配置之后验证与测试

5.1 如何确认镜像源已经生效

配置完成后，第一件事不是急着拉大镜像，而是用docker info确认Registry Mirrors字段。如果已经显示：

Registry Mirrors: https://xxxx.mirror.aliyuncs.com/

说明 Docker daemon 已经成功读取了配置。这里注意输出里可能会在地址尾部多一个/，这是正常现象，不影响使用。

我再建议一个更实际的验证方式：拉取一个体积适中的常用镜像，比如alpine（只有几 MB），先用docker pull alpine看是否能快速完成。如果几秒内完成，那么说明加速器正常工作。如果你想更直观地对比效果，可以记录一下配置前后的耗时。我在同一台服务器上实测，配置前docker pull mysql:8.0平均耗时 5 分钟以上，有时超时；配置后第一次拉取约 40 秒，第二次因为缓存可能只有 10 多秒。

除此之外，可以直接访问加速地址的/v2/端点来测试连通性：

curl -I https://你的ID.mirror.aliyuncs.com/v2/

如果返回200 OK或者401 Unauthorized，都说明服务是可用的。Docker Registry 的/v2/端点在未认证时返回 401 是正常的，说明端点存在。如果返回超时或连接拒绝，那这个加速地址可能有网络问题，或者是你复制错了 URL。

5.2 拉取一个实际镜像试试效果

用一个我经常部署的组合来测试：nginx或redis，因为这两个镜像在加速器缓存中的命中率很高。如果你配置成功后docker pull redis:7依然慢，大概率加速器并没有被正确使用。

我的测试步骤是这样：

1. 先执行docker pull hello-world，这个镜像是测试专用，量很小，能快速验证链路。
2. 再执行docker pull nginx:latest，如果速度能跑到几十 MB/s，基本就没问题了。
3. 最后执行docker pull mysql:8.0，这个镜像比较大，更能体现加速前后的差异。

如果你想测得更严谨，可以在拉取之前用docker rmi nginx:latest把本地镜像删掉，然后再拉取，确保走的是完整的下载流程。不过这些常用镜像拉过一次之后本地就有缓存，第二次再拉会显示Image is up to date，不会再有大流量，不算真正测试。所以要测试加速器是否生效，记得先删除本地镜像。

5.3 多个镜像源顺序与 fallback 行为

Docker 会按照registry-mirrors数组里的顺序依次尝试。比如第一个源连不上或镜像不存在，它会自动尝试下一个源。这就意味着你可以把阿里云放在最前面当主力，把中科大放在第二位当备份。

但这里有个实际问题：第一个源如果连接一直卡住（比如网络黑洞），Docker 在切换下一个源之前会等待一段时间。等待时间取决于 Docker 客户端与 daemon 的连接超时设置，有时要等几十秒。所以千万不要把一堆早已失效的源都填进去，否则你拉一个镜像可能要经历两次超时，反而比不配还慢。

我的实践是：最多两个源，第一个是主力专用源，第二个是备用开源源；如果两个源都是稳定的，宁缺毋滥。不要在配置里堆砌七八个地址，那样除了让docker info看起来密密麻麻，体验并不会更好。

5.4 docker pull 始终走的是配置的镜像源吗

很多人会有疑问：我设置了registry-mirrors，为什么docker pull的时候输出里看不到地址变化？实际上 Docker 客户端只会显示镜像的仓库名和标签，不会显示它实际是从哪个 Registry 地址下载的。所以你不能从控制台的显示上看出是不是走了加速器。如果需要进一步确认，可以在同一个 Docker 环境中临时禁用registry-mirrors，对比拉取速度，或者通过 tcpdump 抓包看连接的目标地址。

抓包方法大概是这样：

sudo tcpdump -i eth0 -n port 443 and host xxx.mirror.aliyuncs.com

然后另开一个终端docker pull alpine，如果抓到了与加速地址的连接，就说明流量确实经过加速器。这个方法比较高级，适合对网络细节感兴趣的人。对大部分人来说，docker info加上速度对比已经足够了。

6. 常见问题排查与避坑经验

6.1 配置了但 docker info 里没有显示

最常见的原因有三个：配置文件路径不对、daemon 没有重启、JSON 格式错误导致 Docker 启动失败但被你忽略了。

首先检查路径，Linux 下必须放在/etc/docker/daemon.json，不是/etc/daemon.json，也不是当前用户目录下。如果你用的是 Docker Desktop，GUI 里的配置路径不等于 Linux 路径，不要混淆。

其次，确认你已经执行过systemctl restart docker。只修改文件不重启，daemon 不会重新加载配置。有的教程只让你systemctl daemon-reload但不重启 docker，这个只会在下次手动重启时生效，所以最好还是systemctl restart docker。

最后，使用sudo cat /etc/docker/daemon.json确认文件内容是你想要的样子，再用 JSON 校验工具确认没有语法问题。

为了方便排查，我把常见错误列成表格：

6.2 公共镜像源突然失效怎么办

我遇到过最气人的问题就是，昨天还在用的加速地址，今天拉镜像突然报连接超时。尤其是一些高校公共源，运维调整往往没有任何公告，等你发现失效时已经浪费了不少时间。

我的处理方式是养成了“多源布局”的习惯。虽然在配置里只保证两个源，但在电脑或手机备忘录里会保存三四个可用源的地址，一旦主力源失效，就立刻替换备用地址。另外，阿里云专属加速器是跟着账号走的，基本不存在突然失效的问题，只是偶尔会要求重新登录认证。如果你发现阿里云加速地址也连不上，可以先到阿里云控制台确认账号没有登录过期，或者换绑手机导致原有加速器 ID 被禁用。

还有一种情况是公共源本身可用，但某些镜像没有缓存，加上上游 Docker Hub 网络波动，导致拉取失败。这时候可以尝试再拉一次，或者等待一段时间后重试；也可以手动拉取一次后使用 Docker commit 导出到本地，后续就不需要依赖外部源。

6.3 Docker Desktop 启动报错导致无法配置镜像源

不少 Windows 用户会碰到 Docker Desktop 启动时提示类似“Virtualization support is not detected”或“Docker Desktop failed to start because virtualisation support wasn't detected”之类的错误。这通常发生在安装 Docker Desktop 之后第一次启动，或者是开启 WSL2 之前没配置好 Hyper-V 虚拟化。这个错误会让整个 Docker Desktop 没法打开，更别提设置镜像源了。

解决步骤我用过有效的是：

1. 在 Windows 功能中开启“Hyper-V”和“适用于 Linux 的 Windows 子系统”；
2. 在 BIOS 设置里确认 CPU 虚拟化已开启（Intel VT-x / AMD-V）；
3. 以管理员身份运行 PowerShell，执行bcdedit /set hypervisorlaunchtype auto，然后重启；
4. 如果仍然报错，到 Windows“启用或关闭 Windows 功能”里勾选“虚拟机平台”
5. 重装最新版 Docker Desktop。

对于 macOS 用户，也有类似的虚拟化框架问题，但出现频率较低。如果报错信息提到Virtualization.framework，可以尝试在 Docker Desktop 设置里切换后端为 “Apple Virtualization.framework” 而不是 “HyperKit”，或者升级 macOS 后重启。

6.4 镜像源配置了但拉取大镜像还是慢，还有哪些要检查

镜像源不是万能的。有时候即使加速器正常工作，拉取 big size 镜像依然不够快，因为加速器节点的带宽也有上限。另外，公司网络对 HTTPS 流量进行深度扫描或限速，也会让所有外部连接都变慢，这部分就不是镜像源能解决的了。

如果你确定加速器已经生效，但拉取 mysql:8.0 这类 200MB+ 镜像仍然只有几 MB/s，可以试试以下步骤：

• 检查本机网络带宽，用curl -o /dev/null下载一个测试文件测速；
• 更换另一个加速器测试，比如把中科大源和阿里云源交换顺序，看是否有变化；
• 在 Docker 设置里开启并行下载？实际上 docker 默认就有并发，除非你改过max-concurrent-downloads设置。如果你在 daemon.json 里设置了较小的并发数，需要适当调大，比如设为 6；
• 如果走的是代理服务器，检查 Docker 是否继承了代理设置。有些网络环境中设置了 HTTP_PROXY 环境变量，Docker 拉镜像时也会走这个代理，反而绕了远路。

这里还要特别提醒一个安全问题：不要随便使用来路不明的第三方镜像加速器。加速器本质上会返回镜像数据，如果服务方不怀好意，可能在你的镜像层里塞入恶意内容。虽然 Docker 对镜像层有 digest 校验，但如果你下载的是通过该加速器特殊处理的镜像，digest 合法也可能被替换。我个人的原则是只用知名云厂商或高校的公开加速地址，绝不使用陌生论坛里分享的个人代理地址。

7. 镜像源设置好之后，几个典型部署场景快速体验

7.1 加速器对 Docker 安装 MySQL 的帮助

配置好镜像源后，最直接的爽点就是部署常用软件时不再“卡在拉镜像”。比如有些教程里写“docker 安装 mysql8.0 并使用”，如果在配置镜像源前，光docker pull mysql:8.0可能就要五分钟起步，甚至失败。配置后，一分钟内基本能拉下来。

以MySQL 8.0快速部署为例：

docker run -d \ --name mysql-test \ -p 3306:3306 \ -e MYSQL_ROOT_PASSWORD=123456 \ mysql:8.0

如果没有加速器，跑这条命令前你得先经历漫长的docker pull。有了加速器，整个流程会顺畅很多。而且这个提速不只有首次拉取镜像，后面你删除容器重新创建、在不同机器上启动相同镜像时，加速器缓存也能发挥作用。

7.2 redis 主从部署：镜像源只是第一步

很多做缓存服务的人会搭建 Redis 主从环境，用 Docker 部署再方便不过。镜像源解决的是docker pull redis的下载速度，真正的主从配置还需要挂载配置文件、设置replicaof参数。不过如果连镜像都拉不下来，后续无从谈起。

我可以给一个简单的示例：

1. 先准备一个 redis 主配置redis.conf，绑定0.0.0.0，开启appendonly yes等；
2. 启动主节点：

docker run -d --name redis-master \ -p 6379:6379 \ -v $(pwd)/redis.conf:/etc/redis/redis.conf \ redis:7 redis-server /etc/redis/redis.conf

3. 启动从节点，配置replicaof 主节点IP 6379：

docker run -d --name redis-slave \ -p 6380:6379 \ -v $(pwd)/redis-slave.conf:/etc/redis/redis-slave.conf \ redis:7 redis-server /etc/redis/redis-slave.conf

这些命令里镜像下载是核心基础，国内镜像源加速后，几分钟内就能把 Redis 主从跑起来，不用把时间浪费在转圈圈上。

7.3 Docker Compose 环境下同样走镜像源

如果你用docker-compose.yml定义多容器应用，比如一个 Web 服务加 MySQL 加 Redis，那镜像源一样有效。docker compose up -d在启动前会自动拉取所有镜像，这个过程同样会命中镜像加速器。在配置了加速器的机器上，我第一次跑docker compose up时，感觉非常省心——所有镜像秒级或者分钟级拉完，再也不会因为某个镜像卡住导致整个 compose 卡住。

我也试过在没有配置镜像源的机器上直接跑同一个 compose 文件，结果卡在mysql:8.0的拉取上，等了十分钟还没好。后来我直接把 daemon.json 复制过去，重启 docker 再跑，速度立刻不一样了。所以如果你想在测试环境或新服务器上复现项目，第一件事不是装依赖，而是先配置国内镜像源。

7.4 与 Docker 安装相关的其他热词联动思考

现在网上关于 Docker 的教程很多，标题动不动就是“docker 安装教程”“docker 安装部署”“docker 安装mysql失败”等等。其实很多“安装失败”根本不是 Docker 的锅，而是镜像拉取超时。如果你一开始就配置好国内镜像源，后面再安装各种软件包，成功率会提升一个档次。

比如遇到docker pull mysql卡住，你能想到查镜像源吗？大多数人第一反应是网络强、防火墙、代理，最后才发现是镜像源的问题。而我已经把配置镜像源当成装完 Docker 之后的第一条“铁律”：新机器拿到手，安装 Docker 后立刻配置镜像源，再谈其他。

8. 写在最后的一点经验谈

我在这套配置上折腾了好几轮，最后总结出的最核心体会是：镜像源不是一次配置就一劳永逸的。网络环境、源服务状态、Docker 版本升级这些因素都可能让原本好用的加速器变得不可用。所以我在自己的服务器上会写一个小的脚本，定期探测一遍配置的源地址是否连通，如果连续几次失败就自动切换备用地址。虽然有点麻烦，但比起在用户面前现场表演docker pull超时，这点自动化投入太值了。

另外一个小技巧是，当你换了一台新电脑或新服务器时，别急着下载各种软件镜像，先把这份 daemon.json 备份发到自己的私有仓库或网盘里，换机器时直接拷贝过去，重启 Docker 就完事。我在团队内部就是维护了一份标准的 daemon.json 片段，新同事入职之后把 Docker 装好，再让他们把这段配置复制进去，三分钟搞定加速问题，不用每个人去注册云账号、找加速地址。

希望这份关于 Docker 国内镜像源设置的折腾记录能帮你少走弯路。如果你配置完之后拉取镜像依然很慢，不妨回到最基础的docker info检查一下，再多换一两个源试试，基本都能解决。