配置 Docker 镜像加速时，docker info 里已经能看到镜像源地址，但实际拉取镜像依然失败。
遇到这种情况，不代表配置完全没生效，也不能只盯着 docker info 这一项反复修改。
docker info 能显示镜像源，只能说明 Docker 已经读取到这项配置，不代表镜像源后面的整条访问链路一定正常。
可以把它理解成通讯录里已经保存了号码，但号码能不能接通，还要看中间的网络和服务是否正常。
docker info 能证明什么
当镜像源地址出现在 docker info 中，通常只能确认：
- 镜像源配置已经被 Docker 读取
- 地址格式至少进入了当前配置
- Docker 当前知道应该尝试使用这个镜像源
它不能直接证明：
- KSpeeder 容器正在正常提供服务
- 群晖反向代理可以正常访问
- 域名、端口和协议完全匹配
- DNS 解析和网络连接正常
- 目标镜像路径能够被正确代理
所以“配置看得见”和“镜像拉得动”是两件事。
KSpeeder中间还有哪些环节
群晖使用 KSpeeder 时，镜像拉取通常还会经过多个环节：
- KSpeeder 容器本身是否正常运行
- 反向代理是否指向正确的服务端口
- 使用的是 HTTP 还是 HTTPS
- 镜像源域名或 URL 是否填写正确
- DNS 是否能够正常解析对应地址
- Container Manager 是否已经重新加载配置
- 上级网络是否能够访问目标服务
其中任何一段出现问题，都可能造成 docker info 已经显示地址，但拉取镜像仍然失败。
建议按这个顺序排查
先不要恢复出厂，也不要一次修改所有配置。
可以依次检查：
- 重启 KSpeeder 容器
- 重启或重新加载 Container Manager
- 核对反向代理使用的域名
- 核对反向代理指向的端口
- 确认 HTTP 和 HTTPS 协议是否一致
- 检查 Docker 中填写的镜像源 URL
- 查看 KSpeeder 容器日志
- 记录拉取镜像时出现的具体报错
如果重启后仍然无法拉取，重点看报错发生在哪一层。
例如，域名无法访问、连接被拒绝、证书异常、超时和镜像路径不存在，排查方向都不一样，不能只用“还是拉不动”来概括。
docker info显示镜像源，只代表配置已经被读取。真正拉取成功，还要看 KSpeeder、反向代理、端口、协议、DNS、网络连通性和目标镜像路径。
能看到配置但拉取失败时，问题通常出在配置之后的访问链路。把反向代理信息、容器日志和具体报错对应起来，比反复重装更容易找到原因。