Docker通过Artifactory拉取微软镜像时服务器连接拒绝问题咨询

核心问题定位 #

从报错信息可以判断，服务器2拉取镜像时直接请求公网mcr.microsoft.com地址，没有按照配置走内部Artifactory代理，是异常的根本原因。

可能的故障原因 #

• 服务器2的Docker配置未实际生效：虽然/etc/docker/daemon.json文件内容与服务器1一致，但未执行配置重载和Docker服务重启操作，旧配置仍在运行
• 服务器1存在本地镜像缓存：该镜像此前已经拉取到服务器1本地，无需请求远程Registry，掩盖了Artifactory的配置缺失问题
• Artifactory代理规则不完整：sonarsource/sonar-scanner-cli等镜像属于Docker Hub官方镜像，Artifactory配置的Docker Hub代理规则正常生效，但mcr.microsoft.com是独立的第三方镜像Registry，需要单独配置代理仓库并加入到Docker虚拟聚合仓库的成员列表中
• 服务器2本地存在网络拦截规则：/etc/hosts中有mcr.microsoft.com的硬解析指向公网IP，或是iptables/路由规则将该域名的请求直接转发到公网，绕过了内部Artifactory代理
• 两台服务器Docker版本不一致：低版本Docker不支持Registry重写规则，导致MCR域名的请求无法正确转发到内部代理

排查步骤 #

1. 验证Docker配置生效状态
   在两台服务器分别执行docker info，对比Registry Mirrors、Insecure Registries配置项是否完全一致，确认服务器2的配置和daemon.json内容匹配。若不一致，执行以下命令重载配置：

systemctl daemon-reload && systemctl restart docker

重载后再次尝试拉取镜像验证是否恢复。

2. 排除本地缓存和本地网络拦截

• 在服务器1执行docker rmi mcr.microsoft.com/dotnet/sdk:6.0删除本地缓存后重新拉取，确认是否仍能正常拉取，排除缓存干扰
• 在服务器2执行cat /etc/hosts | grep mcr.microsoft.com、iptables -L -n检查是否存在针对该域名的硬解析或强制转发规则，同时执行curl -v https://mcr.microsoft.com/v2/确认请求走向

3. 检查Artifactory配置
   登录内部Artifactory后台，确认已创建mcr.microsoft.com对应的远程代理仓库，且该仓库已经加入到Docker客户端配置的虚拟聚合仓库的成员列表中。同时查看Artifactory的访问日志，确认服务器2拉取镜像的请求是否到达Artifactory服务。

4. 对比Docker版本
   执行docker --version对比两台服务器的Docker版本，若服务器2版本低于20.10.0，存在代理规则不兼容风险，建议升级到和服务器1一致的版本后重试。

对应解决方案 #

• 配置未生效：重载配置并重启Docker服务即可恢复
• Artifactory规则缺失：在Artifactory中新建MCR镜像源的远程代理仓库，加入到现有Docker虚拟仓库的成员列表即可
• 本地网络拦截：删除对应的hosts硬解析或iptables转发规则即可
• 版本兼容问题：升级服务器2的Docker版本到与服务器1一致即可

内容的提问来源于stack exchange，提问作者Jörg Lang