如果你最近也遇到过docker pull卡在Waiting然后Retrying的尴尬局面那么这篇内容你应该会需要。Docker 与国内镜像源之间的故事从很早以前就开始了而我手上这份清单是 2026 年 9 月 10 日重新整理后的版本既包含了我自己服务器上实测可用的加速地址也把配置步骤和常见报错一次性写全。无论你是刚接触 Docker 的新手还是正在维护多台生产环境的运维照着做都能少走弯路。我尽量不堆理论直接给结论但关键原理会顺带解释清楚免得你以后面对新镜像源时只会抄作业不会判断。1. 为什么Docker镜像拉取这么慢先明白加速器在做什么1.1 镜像仓库的传输链路与瓶颈很多人以为 Docker 镜像就是一个大文件下载慢就是网速不行。实际上 Docker 镜像是“分层”的一个完整镜像由很多只读层叠加组成拉取时需要逐个下载这些层并且每一层都会做校验和索引过程比普通文件下载复杂不少。当你不配置任何镜像源时Docker 默认从 Docker Hub 直接拉取这会面临两个问题。第一是网络链路过长数据包需要跨越较远的物理距离延迟天然偏高第二是并发下载层数过多时连接质量一旦不稳定就容易出现中断。于是你看到的不是进度条稳步前进而是反复出现的Waiting和Retrying最后甚至直接超时失败。这里要特别注意瓶颈不一定在带宽更多时候在“连接质量”。有些服务器带宽很高但到达 Docker Hub 的丢包率高同样拉不动镜像。这也是为什么单纯限速不能解决 Docker 拉取慢的原因必须从源头换一条更顺的传输路径。1.2 镜像加速器就是一座“本地货仓”理解了瓶颈之后镜像加速器的原理就很直白了。它本质上是一个上报缓存代理你配置好registry-mirrors之后Docker daemon 会优先从这个加速器拉取镜像层。加速器收到请求后有两种情况如果这个镜像层已经在它的缓存里直接回传给你速度接近内网如果缓存里没有它会代替你去 Docker Hub 拉取一次再缓存并回传。对于热门镜像如nginx、mysql、redis加速器命中率非常高所以能明显感觉到下载速度提升。用生活里的例子类比Docker Hub 是远在异地的生产厂家每次缺货都要厂家直接发货物流自然慢加速器相当于你家楼下的社区超市热门商品提前备货你下楼就能买到。理解了这一点你也就明白为什么“镜像源列表”总在变——超市的运营成本、经营策略一变可能就不再备货或关门了。1.3 为什么“可用镜像源列表”总在变很多人在网上搜“Docker 国内镜像源”看到一份列表就填进去过段时间发现拉不动了还以为是配置写错。其实原因很简单跑公共镜像加速源是需要持续花钱的带宽、存储、运维成本都不低有些源会因为资源耗尽或者策略调整而停止服务。再加上不同运营商、不同地区访问同一镜像源的体验差异很大。你在电信网络下用某个源很快换到移动网络可能就慢如蜗牛。所以我做这个清单时不会只看网上的“推荐列表”而是会实际拉取几个镜像做对比。同时建议你也把验证步骤学会这样才能在镜像源失效时快速判断而不是干等。2. 2026年9月最新可用的国内镜像源清单2.1 已稳定运营的公共镜像源列表以下是我在 2026 年 9 月 10 日重新验证过的加速源地址。需要说明的是公共源随时可能调整下面的内容只能代表“写稿时点”的状态建议配置前先用后面的验证方法跑一遍。镜像源名称地址特点使用建议腾讯云加速器https://mirror.ccs.tencentyun.com腾讯云内部服务云服务器可用性高腾讯云 ECS 上优先使用网易镜像https://hub-mirror.c.163.com老牌公共源覆盖较广适合做备用源DaoCloud 加速器https://docker.m.daocloud.io第三方源中存活时间较长社区普及度高适合个人电脑和部分服务器百度智能云加速器https://mirror.baidubce.com背靠百度云稳定性较好可做第二备用源阿里云个人加速器https://你的ID.mirror.aliyuncs.com需要登录获取专属地址带宽有保障强烈推荐需要注册注意这里没有把很多网上流传的“中科大源”和“Docker官方中国区”放进去不是因为我忘记了而是它们在最近几次测试中要么响应不稳定要么已经停止对外服务。与其让大家踩坑不如只保留我实际验证过还能用的。2.2 需要注册/登录才能获得的“专属加速器”在上面的表格里阿里云的加速器比较特殊它不是一个公共地址而是每个用户一个专属域名。你需要先登录阿里云容器镜像服务控制台在“镜像加速器”页面找到属于你的地址通常长这样https://xxxx.mirror.aliyuncs.com。为什么我要专门推荐这种需要注册的源因为公共源面向所有用户一旦流量过大就会限流或关闭。而专属源是绑定账号的阿里云会根据你的使用量提供相对稳定的带宽实测下来拉取大镜像的成功率会高不少。如果你已经拥有阿里云账号哪怕只是在个人电脑上用也值得花两分钟拿一下这个地址。除了阿里云腾讯云和百度云也有类似机制。腾讯云的加速器虽然对公网开放但如果你恰好有腾讯云服务器走内网访问会更稳定。这类“云厂商专属加速器”通常需要实名认证但对个人开发者来说门槛不高。2.3 快速验证镜像源是否可用的方法拿到一个镜像源地址后先别急着写入配置文件先用一条命令验证它是否“活”着curl -I --connect-timeout 5 https://docker.m.daocloud.io/v2/如果命令能正常返回HTTP/2 200或401说明这个加速器的服务端口是通的可以尝试配置。如果一直超时或者报Could not resolve host说明这个源目前不可用换下一个。这里有个小知识点Docker Registry 的/v2/端点用于 API 版本协商正常情况下匿名访问会返回 401 Unauthorized少数情况返回 200但只要不是连接失败就代表网络可达。验证完成后再拉一个很小的测试镜像来实际测速time docker pull busybox用time命令计算总耗时如果能在几十秒内完成说明加速效果已经正常。3. 手把手配置Docker国内镜像源Windows/Linux/macOS3.1 用 Docker Desktop 配置加速器最省事Windows 和 macOS 用户最常用的是 Docker Desktop。新版 Docker Desktop 的配置入口在Settings - Docker Engine你可以在右侧 JSON 编辑区直接加入registry-mirrors。以 Windows 为例具体步骤是打开 Docker Desktop点击右上角齿轮图标进入 Settings左侧选择 Docker Engine在 JSON 配置的registry-mirrors字段里填入你要用的源地址然后点击Apply restart应用并重启。我通常在daemon.json里这样写{ registry-mirrors: [ https://你的ID.mirror.aliyuncs.com, https://docker.m.daocloud.io ] }这段代码同样适用于 Linux 的/etc/docker/daemon.json。Docker Desktop 会自动校验 JSON 格式如果格式不对会直接拒绝应用所以不太容易因为少逗号或者多括号而把 Docker 搞挂。3.2 在 Linux 服务器上修改 daemon.jsonLinux 服务器上配置镜像源是最常见的操作。如果你使用systemd管理 Docker步骤基本固定第一步创建或编辑/etc/docker/daemon.json文件sudo mkdir -p /etc/docker sudo tee /etc/docker/daemon.json -EOF { registry-mirrors: [ https://mirror.ccs.tencentyun.com, https://docker.m.daocloud.io ] } EOF第二步重启 Docker 服务让配置生效sudo systemctl daemon-reload sudo systemctl restart docker如果你用的不是 systemd比如一些老系统或 Docker 通过service docker restart管理也能生效。重启完后不要急着拉镜像先用后面的验证命令确认配置到底加上没有。3.3 配置完成后如何验证是否真的生效很多同学配置完就去看拉取速度其实最稳妥的方式是先用 Docker 官方的信息命令确认配置被加载了docker info在输出内容里找到Registry Mirrors这一段。如果你看到Registry Mirrors: https://mirror.ccs.tencentyun.com/ https://docker.m.daocloud.io/说明配置已经生效。如果这里空白说明 daemon 没有读取到你写的配置文件需要检查路径是否正确以及 Docker 是否真的重启了。之后可以连续拉几个常用镜像验证速度比如nginx:alpine和redis:7-alpine。如果拉取速度能达到几 MB/s 以上基本说明加速器在正常工作。3.4 三条配置禁忌第一不要在daemon.json里写注释。Docker daemon 的 JSON 解析器不支持严格 JavaScript 格式注释会导致重启失败。网上有些老教程里写了#注释那是错误的。第二不要贪心把所有加速源都塞进去。Docker 在拉取镜像时会按顺序尝试镜像源如果第一个源连接超时会切换下一个但如果所有源都不可用反而会增加等待时间。建议最多配置两到三个而且把最稳定的放第一位。第三不要把registry-mirrors写在storage-driver或其他字段的上一层。daemon.json的层级必须严格一个常见错误是把镜像源数组写到了log-driver的options下面导致 Docker 无法启动。4. 常见问题与排查技巧实录4.1 配置好了但镜像源不生效先检查这几项我在社群答疑时经常遇到“明明配置了镜像源拉镜像还是慢”的情况逐个排查下来绝大多数集中在三件事上。第一件是配置文件位置不对。Linux 上 Docker daemon 默认读取/etc/docker/daemon.json但如果你是通过 Docker Desktop 或者其他管理工具启动的 Docker它可能读取的是用户目录下的配置比如~/.docker/daemon.json。第二件是重启不到位只改了文件没有systemctl restart docker。第三件是docker info里能看见 Registry Mirrors但拉镜像时依然走官方源这种多半是 Docker 插件或环境变量覆盖了默认配置。排查建议优先用docker info确认当前实际加载的配置。如果配置确实没问题再检查 DNS 是否能正常解析镜像源域名nslookup docker.m.daocloud.io有些内网环境会屏蔽特定域名导致配置了也没用这个问题换一个源就能解决。4.2 Docker Desktop 启动失败处理 virtualization support not detectedWindows 上安装 Docker Desktop 后启动时报错Docker Desktop failed to start because virtualization support was not detected是非常高频的问题。我看到很多新手在这一步就直接卡住其实原因很明确Docker Desktop 依赖 Windows 的虚拟化能力要么通过 WSL2 后端要么通过 Hyper-V 后端而 BIOS/UEFI 中没有开启 CPU 虚拟化或者 Windows 功能没有启用。解决步骤如下打开任务管理器切换到“性能”选项卡看底部“虚拟化”是否显示“已启用”。如果显示“已禁用”需要重启进 BIOS 设置找到Intel Virtualization Technology或SVM Mode开启后保存并重启。开启“Windows 功能”中的“适用于 Linux 的 Windows 子系统”和“虚拟机平台”然后按要求重启。在 PowerShell 执行wsl --status确认 WSL 版本。如果 WSL 异常可以执行wsl --update更新内核。最后再启动 Docker Desktop大概率能通过检查。这里面有个容易忽略的点如果你电脑上安装了其他安全软件或者本身开启了旧版 Hyper-V 和“内核隔离”冲突也会导致虚拟化检测失败。遇到这种情况建议临时关闭第三方安全软件的虚拟化保护再从 BIOS 到 Windows 功能重新检查一遍。4.3 拉取镜像报权限错误Permission deniedLinux 上安装完 Docker 后直接docker pull经常会碰到这样的报错Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock这是因为 Docker daemon 的 socket 文件默认只允许root用户和docker组的用户访问。当前用户不在docker组里自然无法连接。解决办法是把当前用户加入docker组sudo usermod -aG docker $USER newgrp docker然后重新执行docker ps测试。如果还是报错可以考虑重启会话或者重新登录服务器。这里要提醒一句把用户加入docker组等同于赋予该用户 root 权限因为可以通过挂载宿主目录的方式拿到主机文件访问能力所以在多用户生产环境要谨慎。4.4 镜像拉取仍然慢试试这几招配置了镜像源但速度依旧拉胯这种情况我也会遇到。第一个收益最明显的操作是调整 Docker daemon 的并发下载数。Docker 默认并发层数限制是 3在某些环境下调大这个值可以明显提升拉取速度{ registry-mirrors: [ https://docker.m.daocloud.io ], max-concurrent-downloads: 8 }第二个方法是拉取时明确平台架构和需要的 tag。比如docker pull --platform linux/amd64 mysql:8.0可以避免拉取其他平台无关镜像层减少体积。第三个方法是换“冷门源”为“大厂源”尤其在有云服务器的情况下优先使用云厂商自带的内网加速器地址走内网传输速度会有跨越式提升。4.5 镜像pull到一半卡住或卡在 Retrying 的解决办法最让人崩溃的不是一开始拉不动而是拉到 80% 突然卡住然后一直Retrying。这种情况通常是某几个镜像层下载不完整连接被重置。遇到这种问题不要反复点重试而是先把不完整的镜像清理掉docker system prune -f有时候清理不够彻底还需要删除残留的构建缓存。然后重新docker pull如果还是卡在同一层可以考虑切换镜像源因为不同源对同一镜像层的缓存情况不一样也许另一个源恰好有完整缓存。5. 镜像源配置之外的加速技巧与生态扩展5.1 国内源让“Docker安装MySQL 8.0”变得顺滑我经常被问到怎么用 Docker 安装 MySQL 8.0。以前不配置镜像源时光是docker pull mysql:8.0就要等很久配置好镜像源之后整个过程可以压缩到几分钟。提供一个最常用的启动命令做参考docker run -d \ --name mysql8 \ -p 3306:3306 \ -e MYSQL_ROOT_PASSWORDyourpassword \ -e TZAsia/Shanghai \ mysql:8.0镜像加速器在这里的影响只体现在拉取镜像阶段容器运行本身和镜像源无关。不过只有在拉取阶段不卡壳你才可能顺畅地完成后续的数据目录挂载、配置文件映射这些操作所以说镜像源是整个 Docker 使用体验的地基并不过分。5.2 Docker Compose项目拉镜像同样受益如果你的项目使用docker compose up -d启动服务镜像源配置同样起作用因为 Compose 底层也是交给 Docker daemon 去拉取镜像的。只要/etc/docker/daemon.json里的registry-mirrors配置生效Compose 启动时走的也是加速器地址。这里有一个小技巧如果你在docker-compose.yml里写了image: mysql:8.0但内网环境需要固定使用某个源可以在镜像名里直接写明镜像仓库前缀。不过这样做不利于迁移我更建议保持镜像名简洁靠 daemon 层配置统一处理。5.3 其他开发组件的国内镜像源参考Docker 不是唯一会被镜像源问题影响的开源组件。这几年我经常同时维护 Docker 和 AI 相关环境Ollama 模型下载、npm 包安装、conda 包安装都会遇到类似的速度问题。Ollama 可以通过配置OLLAMA_MODELS等环境变量来调整模型存储位置但更关键的是它从模型仓库下载权重时同样依赖网络质量。npm 可以持久设置国内镜像源npm config set registry https://registry.npmmirror.com。conda 可以通过.condarc文件配置清华 TUNA 镜像源。Hugging Face 也有类似的镜像站可以用于加速模型下载。不过这些和 Docker 镜像源有着本质区别Docker 的加速器是运行时代理缓存机制而 npm 和 conda 的镜像源是直接指向一个独立仓库的复制品。配置思路上略有不同但最终目的都一样——降低网络对开发流程的影响。6. 关于镜像源维护我的一些个人经验这份列表从年初第一次整理到现在已经迭代过好几个版本期间有不少公共源关停也出现过同一个源上午快下午慢的情况。我自己的使用习惯是每个季度至少抽查一次服务器上的镜像源可用性并且始终保留一个“云厂商专属源”作为保底。既然配置了加速器就要学会验证它是否在帮我们干活。不要等到线上部署时才发现镜像源已经失效那时候再去翻文档、换地址压力会非常大。最后分享一个很实用的小技巧如果你长期使用 Docker建议把常用的几个镜像源地址做成 shell 脚本批量写入多台服务器的daemon.json。每次更新镜像源后只要在服务器上执行脚本然后自动重启 Docker就可以避免一台一台改配置的繁琐。这个习惯帮我节省了大量时间也让我在面对镜像源失效时能更快响应。
如果你最近也遇到过docker pull卡在Waiting然后Retrying的尴尬局面那么这篇内容你应该会需要。Docker 与国内镜像源之间的故事从很早以前就开始了而我手上这份清单是 2026 年 9 月 10 日重新整理后的版本既包含了我自己服务器上实测可用的加速地址也把配置步骤和常见报错一次性写全。无论你是刚接触 Docker 的新手还是正在维护多台生产环境的运维照着做都能少走弯路。我尽量不堆理论直接给结论但关键原理会顺带解释清楚免得你以后面对新镜像源时只会抄作业不会判断。1. 为什么Docker镜像拉取这么慢先明白加速器在做什么1.1 镜像仓库的传输链路与瓶颈很多人以为 Docker 镜像就是一个大文件下载慢就是网速不行。实际上 Docker 镜像是“分层”的一个完整镜像由很多只读层叠加组成拉取时需要逐个下载这些层并且每一层都会做校验和索引过程比普通文件下载复杂不少。当你不配置任何镜像源时Docker 默认从 Docker Hub 直接拉取这会面临两个问题。第一是网络链路过长数据包需要跨越较远的物理距离延迟天然偏高第二是并发下载层数过多时连接质量一旦不稳定就容易出现中断。于是你看到的不是进度条稳步前进而是反复出现的Waiting和Retrying最后甚至直接超时失败。这里要特别注意瓶颈不一定在带宽更多时候在“连接质量”。有些服务器带宽很高但到达 Docker Hub 的丢包率高同样拉不动镜像。这也是为什么单纯限速不能解决 Docker 拉取慢的原因必须从源头换一条更顺的传输路径。1.2 镜像加速器就是一座“本地货仓”理解了瓶颈之后镜像加速器的原理就很直白了。它本质上是一个上报缓存代理你配置好registry-mirrors之后Docker daemon 会优先从这个加速器拉取镜像层。加速器收到请求后有两种情况如果这个镜像层已经在它的缓存里直接回传给你速度接近内网如果缓存里没有它会代替你去 Docker Hub 拉取一次再缓存并回传。对于热门镜像如nginx、mysql、redis加速器命中率非常高所以能明显感觉到下载速度提升。用生活里的例子类比Docker Hub 是远在异地的生产厂家每次缺货都要厂家直接发货物流自然慢加速器相当于你家楼下的社区超市热门商品提前备货你下楼就能买到。理解了这一点你也就明白为什么“镜像源列表”总在变——超市的运营成本、经营策略一变可能就不再备货或关门了。1.3 为什么“可用镜像源列表”总在变很多人在网上搜“Docker 国内镜像源”看到一份列表就填进去过段时间发现拉不动了还以为是配置写错。其实原因很简单跑公共镜像加速源是需要持续花钱的带宽、存储、运维成本都不低有些源会因为资源耗尽或者策略调整而停止服务。再加上不同运营商、不同地区访问同一镜像源的体验差异很大。你在电信网络下用某个源很快换到移动网络可能就慢如蜗牛。所以我做这个清单时不会只看网上的“推荐列表”而是会实际拉取几个镜像做对比。同时建议你也把验证步骤学会这样才能在镜像源失效时快速判断而不是干等。2. 2026年9月最新可用的国内镜像源清单2.1 已稳定运营的公共镜像源列表以下是我在 2026 年 9 月 10 日重新验证过的加速源地址。需要说明的是公共源随时可能调整下面的内容只能代表“写稿时点”的状态建议配置前先用后面的验证方法跑一遍。镜像源名称地址特点使用建议腾讯云加速器https://mirror.ccs.tencentyun.com腾讯云内部服务云服务器可用性高腾讯云 ECS 上优先使用网易镜像https://hub-mirror.c.163.com老牌公共源覆盖较广适合做备用源DaoCloud 加速器https://docker.m.daocloud.io第三方源中存活时间较长社区普及度高适合个人电脑和部分服务器百度智能云加速器https://mirror.baidubce.com背靠百度云稳定性较好可做第二备用源阿里云个人加速器https://你的ID.mirror.aliyuncs.com需要登录获取专属地址带宽有保障强烈推荐需要注册注意这里没有把很多网上流传的“中科大源”和“Docker官方中国区”放进去不是因为我忘记了而是它们在最近几次测试中要么响应不稳定要么已经停止对外服务。与其让大家踩坑不如只保留我实际验证过还能用的。2.2 需要注册/登录才能获得的“专属加速器”在上面的表格里阿里云的加速器比较特殊它不是一个公共地址而是每个用户一个专属域名。你需要先登录阿里云容器镜像服务控制台在“镜像加速器”页面找到属于你的地址通常长这样https://xxxx.mirror.aliyuncs.com。为什么我要专门推荐这种需要注册的源因为公共源面向所有用户一旦流量过大就会限流或关闭。而专属源是绑定账号的阿里云会根据你的使用量提供相对稳定的带宽实测下来拉取大镜像的成功率会高不少。如果你已经拥有阿里云账号哪怕只是在个人电脑上用也值得花两分钟拿一下这个地址。除了阿里云腾讯云和百度云也有类似机制。腾讯云的加速器虽然对公网开放但如果你恰好有腾讯云服务器走内网访问会更稳定。这类“云厂商专属加速器”通常需要实名认证但对个人开发者来说门槛不高。2.3 快速验证镜像源是否可用的方法拿到一个镜像源地址后先别急着写入配置文件先用一条命令验证它是否“活”着curl -I --connect-timeout 5 https://docker.m.daocloud.io/v2/如果命令能正常返回HTTP/2 200或401说明这个加速器的服务端口是通的可以尝试配置。如果一直超时或者报Could not resolve host说明这个源目前不可用换下一个。这里有个小知识点Docker Registry 的/v2/端点用于 API 版本协商正常情况下匿名访问会返回 401 Unauthorized少数情况返回 200但只要不是连接失败就代表网络可达。验证完成后再拉一个很小的测试镜像来实际测速time docker pull busybox用time命令计算总耗时如果能在几十秒内完成说明加速效果已经正常。3. 手把手配置Docker国内镜像源Windows/Linux/macOS3.1 用 Docker Desktop 配置加速器最省事Windows 和 macOS 用户最常用的是 Docker Desktop。新版 Docker Desktop 的配置入口在Settings - Docker Engine你可以在右侧 JSON 编辑区直接加入registry-mirrors。以 Windows 为例具体步骤是打开 Docker Desktop点击右上角齿轮图标进入 Settings左侧选择 Docker Engine在 JSON 配置的registry-mirrors字段里填入你要用的源地址然后点击Apply restart应用并重启。我通常在daemon.json里这样写{ registry-mirrors: [ https://你的ID.mirror.aliyuncs.com, https://docker.m.daocloud.io ] }这段代码同样适用于 Linux 的/etc/docker/daemon.json。Docker Desktop 会自动校验 JSON 格式如果格式不对会直接拒绝应用所以不太容易因为少逗号或者多括号而把 Docker 搞挂。3.2 在 Linux 服务器上修改 daemon.jsonLinux 服务器上配置镜像源是最常见的操作。如果你使用systemd管理 Docker步骤基本固定第一步创建或编辑/etc/docker/daemon.json文件sudo mkdir -p /etc/docker sudo tee /etc/docker/daemon.json -EOF { registry-mirrors: [ https://mirror.ccs.tencentyun.com, https://docker.m.daocloud.io ] } EOF第二步重启 Docker 服务让配置生效sudo systemctl daemon-reload sudo systemctl restart docker如果你用的不是 systemd比如一些老系统或 Docker 通过service docker restart管理也能生效。重启完后不要急着拉镜像先用后面的验证命令确认配置到底加上没有。3.3 配置完成后如何验证是否真的生效很多同学配置完就去看拉取速度其实最稳妥的方式是先用 Docker 官方的信息命令确认配置被加载了docker info在输出内容里找到Registry Mirrors这一段。如果你看到Registry Mirrors: https://mirror.ccs.tencentyun.com/ https://docker.m.daocloud.io/说明配置已经生效。如果这里空白说明 daemon 没有读取到你写的配置文件需要检查路径是否正确以及 Docker 是否真的重启了。之后可以连续拉几个常用镜像验证速度比如nginx:alpine和redis:7-alpine。如果拉取速度能达到几 MB/s 以上基本说明加速器在正常工作。3.4 三条配置禁忌第一不要在daemon.json里写注释。Docker daemon 的 JSON 解析器不支持严格 JavaScript 格式注释会导致重启失败。网上有些老教程里写了#注释那是错误的。第二不要贪心把所有加速源都塞进去。Docker 在拉取镜像时会按顺序尝试镜像源如果第一个源连接超时会切换下一个但如果所有源都不可用反而会增加等待时间。建议最多配置两到三个而且把最稳定的放第一位。第三不要把registry-mirrors写在storage-driver或其他字段的上一层。daemon.json的层级必须严格一个常见错误是把镜像源数组写到了log-driver的options下面导致 Docker 无法启动。4. 常见问题与排查技巧实录4.1 配置好了但镜像源不生效先检查这几项我在社群答疑时经常遇到“明明配置了镜像源拉镜像还是慢”的情况逐个排查下来绝大多数集中在三件事上。第一件是配置文件位置不对。Linux 上 Docker daemon 默认读取/etc/docker/daemon.json但如果你是通过 Docker Desktop 或者其他管理工具启动的 Docker它可能读取的是用户目录下的配置比如~/.docker/daemon.json。第二件是重启不到位只改了文件没有systemctl restart docker。第三件是docker info里能看见 Registry Mirrors但拉镜像时依然走官方源这种多半是 Docker 插件或环境变量覆盖了默认配置。排查建议优先用docker info确认当前实际加载的配置。如果配置确实没问题再检查 DNS 是否能正常解析镜像源域名nslookup docker.m.daocloud.io有些内网环境会屏蔽特定域名导致配置了也没用这个问题换一个源就能解决。4.2 Docker Desktop 启动失败处理 virtualization support not detectedWindows 上安装 Docker Desktop 后启动时报错Docker Desktop failed to start because virtualization support was not detected是非常高频的问题。我看到很多新手在这一步就直接卡住其实原因很明确Docker Desktop 依赖 Windows 的虚拟化能力要么通过 WSL2 后端要么通过 Hyper-V 后端而 BIOS/UEFI 中没有开启 CPU 虚拟化或者 Windows 功能没有启用。解决步骤如下打开任务管理器切换到“性能”选项卡看底部“虚拟化”是否显示“已启用”。如果显示“已禁用”需要重启进 BIOS 设置找到Intel Virtualization Technology或SVM Mode开启后保存并重启。开启“Windows 功能”中的“适用于 Linux 的 Windows 子系统”和“虚拟机平台”然后按要求重启。在 PowerShell 执行wsl --status确认 WSL 版本。如果 WSL 异常可以执行wsl --update更新内核。最后再启动 Docker Desktop大概率能通过检查。这里面有个容易忽略的点如果你电脑上安装了其他安全软件或者本身开启了旧版 Hyper-V 和“内核隔离”冲突也会导致虚拟化检测失败。遇到这种情况建议临时关闭第三方安全软件的虚拟化保护再从 BIOS 到 Windows 功能重新检查一遍。4.3 拉取镜像报权限错误Permission deniedLinux 上安装完 Docker 后直接docker pull经常会碰到这样的报错Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock这是因为 Docker daemon 的 socket 文件默认只允许root用户和docker组的用户访问。当前用户不在docker组里自然无法连接。解决办法是把当前用户加入docker组sudo usermod -aG docker $USER newgrp docker然后重新执行docker ps测试。如果还是报错可以考虑重启会话或者重新登录服务器。这里要提醒一句把用户加入docker组等同于赋予该用户 root 权限因为可以通过挂载宿主目录的方式拿到主机文件访问能力所以在多用户生产环境要谨慎。4.4 镜像拉取仍然慢试试这几招配置了镜像源但速度依旧拉胯这种情况我也会遇到。第一个收益最明显的操作是调整 Docker daemon 的并发下载数。Docker 默认并发层数限制是 3在某些环境下调大这个值可以明显提升拉取速度{ registry-mirrors: [ https://docker.m.daocloud.io ], max-concurrent-downloads: 8 }第二个方法是拉取时明确平台架构和需要的 tag。比如docker pull --platform linux/amd64 mysql:8.0可以避免拉取其他平台无关镜像层减少体积。第三个方法是换“冷门源”为“大厂源”尤其在有云服务器的情况下优先使用云厂商自带的内网加速器地址走内网传输速度会有跨越式提升。4.5 镜像pull到一半卡住或卡在 Retrying 的解决办法最让人崩溃的不是一开始拉不动而是拉到 80% 突然卡住然后一直Retrying。这种情况通常是某几个镜像层下载不完整连接被重置。遇到这种问题不要反复点重试而是先把不完整的镜像清理掉docker system prune -f有时候清理不够彻底还需要删除残留的构建缓存。然后重新docker pull如果还是卡在同一层可以考虑切换镜像源因为不同源对同一镜像层的缓存情况不一样也许另一个源恰好有完整缓存。5. 镜像源配置之外的加速技巧与生态扩展5.1 国内源让“Docker安装MySQL 8.0”变得顺滑我经常被问到怎么用 Docker 安装 MySQL 8.0。以前不配置镜像源时光是docker pull mysql:8.0就要等很久配置好镜像源之后整个过程可以压缩到几分钟。提供一个最常用的启动命令做参考docker run -d \ --name mysql8 \ -p 3306:3306 \ -e MYSQL_ROOT_PASSWORDyourpassword \ -e TZAsia/Shanghai \ mysql:8.0镜像加速器在这里的影响只体现在拉取镜像阶段容器运行本身和镜像源无关。不过只有在拉取阶段不卡壳你才可能顺畅地完成后续的数据目录挂载、配置文件映射这些操作所以说镜像源是整个 Docker 使用体验的地基并不过分。5.2 Docker Compose项目拉镜像同样受益如果你的项目使用docker compose up -d启动服务镜像源配置同样起作用因为 Compose 底层也是交给 Docker daemon 去拉取镜像的。只要/etc/docker/daemon.json里的registry-mirrors配置生效Compose 启动时走的也是加速器地址。这里有一个小技巧如果你在docker-compose.yml里写了image: mysql:8.0但内网环境需要固定使用某个源可以在镜像名里直接写明镜像仓库前缀。不过这样做不利于迁移我更建议保持镜像名简洁靠 daemon 层配置统一处理。5.3 其他开发组件的国内镜像源参考Docker 不是唯一会被镜像源问题影响的开源组件。这几年我经常同时维护 Docker 和 AI 相关环境Ollama 模型下载、npm 包安装、conda 包安装都会遇到类似的速度问题。Ollama 可以通过配置OLLAMA_MODELS等环境变量来调整模型存储位置但更关键的是它从模型仓库下载权重时同样依赖网络质量。npm 可以持久设置国内镜像源npm config set registry https://registry.npmmirror.com。conda 可以通过.condarc文件配置清华 TUNA 镜像源。Hugging Face 也有类似的镜像站可以用于加速模型下载。不过这些和 Docker 镜像源有着本质区别Docker 的加速器是运行时代理缓存机制而 npm 和 conda 的镜像源是直接指向一个独立仓库的复制品。配置思路上略有不同但最终目的都一样——降低网络对开发流程的影响。6. 关于镜像源维护我的一些个人经验这份列表从年初第一次整理到现在已经迭代过好几个版本期间有不少公共源关停也出现过同一个源上午快下午慢的情况。我自己的使用习惯是每个季度至少抽查一次服务器上的镜像源可用性并且始终保留一个“云厂商专属源”作为保底。既然配置了加速器就要学会验证它是否在帮我们干活。不要等到线上部署时才发现镜像源已经失效那时候再去翻文档、换地址压力会非常大。最后分享一个很实用的小技巧如果你长期使用 Docker建议把常用的几个镜像源地址做成 shell 脚本批量写入多台服务器的daemon.json。每次更新镜像源后只要在服务器上执行脚本然后自动重启 Docker就可以避免一台一台改配置的繁琐。这个习惯帮我节省了大量时间也让我在面对镜像源失效时能更快响应。
