配 Docker 镜像加速地址，动作本身只有两步：把加速地址写进 daemon 的配置文件，重启 Docker。真正决定成败的是两个前置判断，一是你要拉的镜像是否来自 docker.io，二是 dockerd 有没有读到这份配置。下面按排查顺序拆开讲：可核对的事实、最容易搞错的点、可直接执行的步骤和验证方式。
registry-mirrors 只对 docker.io 的镜像生效，并且必须让 dockerd 真正读到配置文件才会起作用。先确认镜像引用里没带别的 registry 域名，再改配置并重启 Docker，最后用 docker info 的 Registry Mirrors 段加一次全新拉取来验证。配完不验证，很容易以为已经生效。
Docker镜像加速地址：先把能核对的事实摆清楚
先把对象和前提列清楚，这一步不下结论，只记录能核对的东西。
配置对象在 Linux 上通常是 /etc/docker/daemon.json，字段名固定为 registry-mirrors，值是一个字符串数组。Docker Desktop 的入口在 Settings 里的 Docker Engine 面板，写的是同一份 JSON。如果这个文件已经存在别的键（比如 data-root、log-driver），不是覆盖它，而是把数组加进去，否则原有配置会被冲掉。
前提条件有两项可以自己核对：一是要拉的镜像确实属于 docker.io，例如 nginx、library/redis 这类不带域名前缀的引用；二是加速地址本身可达，可以用下面这条命令先探一下服务端身份：
curl -I https://<加速地址>/v2/返回 200 或 401 通常说明这是一个能正常应答的 Registry v2 服务（401 表示需要认证但端点存在）；返回 404、连接超时或证书错误，说明地址、路径或网络有问题，这时候改 daemon.json 没有意义。
可核对的现象集中在几处：docker info 输出里的 Registry Mirrors: 段，这是 daemon 实际读到的值；ps -ef | grep dockerd 看启动参数里是否额外带了 --registry-mirror（有些安装方式把加速地址写在服务单元或环境文件里，跟 daemon.json 是两条路径）；日志在 journalctl -u docker，重启失败时先看这里；Docker Desktop 则看应用内的日志和 Engine 面板的报错提示。
Docker镜像加速地址最容易搞错的一点
最常见的误解，是把 registry-mirrors 当成全局拉取代理。它不是。registry-mirrors 只对 Docker Hub（docker.io）的镜像引用生效，判断分界线就看镜像名里有没有 registry 域名。
docker pull nginx、docker pull library/postgres:16：没有域名前缀，默认解析到 docker.io，会走加速地址。docker pull ghcr.io/org/app:tag、docker pull quay.io/org/app、docker pull registry.example.com/team/app：带域名前缀，直连对应 registry，加速地址不参与。
区分这两种情况，有一个检查动作很直接：先拉一张不带前缀的公共镜像，再拉一张带其它域名前缀的镜像，中间用 journalctl -u docker -n 100 --no-pager 观察 dockerd 实际请求的目标域名。如果两类镜像的请求目标一致，说明镜像引用被改写成了带域名的形式（例如从某个私有仓库同步过来的镜像），加速配置本来就不会生效。另一种同样常见的情况是：docker info 里 Registry Mirrors 是空的，那问题不在镜像来源，而在于 daemon 压根没读到配置——两个方向要分开排查。
Docker镜像加速地址：一个照着就能做完的做法
以下以 Linux + systemd 的 dockerd 为例。先把已有配置备份并校验，避免改坏原有键：
sudo cp /etc/docker/daemon.json /etc/docker/daemon.json.bak 2>/dev/null
sudo mkdir -p /etc/docker
sudo cat /etc/docker/daemon.json 2>/dev/null || echo '{}'如果上一步输出是 {}，可以直接写入；如果已有内容，把 registry-mirrors 作为新键加进去，不要删掉原有键。写入后立刻做一次语法校验，JSON 不合法 dockerd 会启动失败：
sudo tee /etc/docker/daemon.json >/dev/null <<'EOF'
{
"registry-mirrors": ["https://<加速地址>"]
}
EOF
sudo python3 -m json.tool /etc/docker/daemon.jsonjson.tool 正常会把格式化后的 JSON 打印出来，此时能看到 registry-mirrors 数组就是对的；报 Expecting value 之类错误就先修 JSON，再往下走。然后重启 Docker 并读取 daemon 的生效配置：
sudo systemctl restart docker
sudo systemctl is-active docker
docker info | sed -n '/Registry Mirrors/,+3p'is-active 这一步应该输出 active；如果输出 failed，先执行 journalctl -u docker -n 50 --no-pager，多数情况是 daemon.json 写坏或加速地址格式不对（少了 https://、多了结尾斜杠以外的路径）。docker info 那一段应该能看到你写入的地址，行内出现这一条，才说明配置被 daemon 读到了。加速地址从哪里取，各家容器服务的控制台或自建 registry 的部署说明里都会给出，具体字段和可用区域需要结合你的环境确认，页面上的限速与额度说明也要以那里为准。
Docker镜像加速地址：怎么验证结果对不对
验证分两层，第一层确认配置被读到，第二层确认拉取行为符合预期。
第一层用 docker info 的 Registry Mirrors: 段，正常结果是你配置的地址逐条列在下面；该段为空或整段不出现，说明配置没被读到，回到 daemon.json 的路径、JSON 语法和是否有多份配置冲突上查。
第二层需要一次不带缓存的拉取，先删本地镜像再拉：
docker rmi nginx:latest
docker pull nginx:latest
docker images nginx正常结果是拉取过程能完整走完，docker images 能看到 nginx 的镜像 ID 和大小，且 docker run --rm nginx:latest nginx -v 能打印出版本号。如果拉取阶段长时间停在某一层或报 manifest unknown、net/http: TLS handshake timeout，先回到 curl -I https://<加速地址>/v2/ 确认端点是否可用，而不是反复改 daemon.json。
想进一步确认镜像到底从哪个源取的，可以把 dockerd 日志级别临时调高后重试一次拉取，观察日志里的请求目标；但这属于排查手段，确认完建议恢复默认级别，长期开着会增加日志量。对于带域名前缀的镜像，例如 ghcr.io 或自建 registry，验证方式同样是一次全新拉取，但要清楚这类镜像不受 registry-mirrors 影响，拉不动时应从该 registry 的访问权限和网络连通性入手，而不是继续在加速地址上找原因。