GitLab更新后远程服务器Docker登录GitLab镜像仓库失败

核心问题回顾 #

• GitLab从15.11.5升级到16.1.2后，远程服务器执行docker login连接GitLab Registry时出现连接拒绝错误：

  Error response from daemon: Get "https://<my-domain>:5050/v2/": dial tcp <my-ip>:5050: connect: connection refused
  

• 直接在远程服务器执行curl -i https://<my-domain>:5050返回200 OK，且执行后流水线的docker login恢复正常。

Curl与Docker Login的处理差异 #

两者在网络请求、证书处理、DNS解析上存在关键区别，这是curl能"修复"问题的核心：

1. DNS解析机制不同 #

• Curl直接使用系统DNS解析器，读取/etc/resolv.conf配置并依赖系统DNS缓存。
• Docker daemon有独立的DNS配置（可通过docker info | grep DNS查看），可能缓存了旧的域名解析结果。GitLab升级后，Registry的IP或反向代理配置可能隐性变更（即使你认为主机没改），curl访问时会触发系统DNS刷新，后续Docker daemon解析域名时就能拿到正确IP，不再连接旧的无效IP导致拒绝。

2. 证书处理逻辑差异 #

• GitLab 16.x版本可能更新了Registry的SSL证书链（包括根证书或中间证书）：
  • Curl会自动验证证书，并将信任的证书写入系统证书缓存（比如/etc/ssl/certs），遇到新证书链时会自动完成信任链更新。
  • Docker daemon依赖系统证书存储，但可能缓存了旧证书信息。当curl触发系统证书缓存更新后，Docker后续请求就能读取到新的有效证书，避免因证书验证失败而伪装成"连接拒绝"（部分场景下证书错误会被Docker返回为连接失败）。

3. 网络栈与连接状态的区别 #

• Curl使用系统原生网络栈发起请求，会触发防火墙、负载均衡或网关的连接状态更新，清理掉之前残留的无效TCP连接（比如TIME_WAIT状态的旧连接）。
• Docker daemon有独立的网络命名空间，之前的请求可能因网络状态残留导致连接失败，curl的请求相当于"打通"了网络路径，让后续Docker的请求能正常建立连接。

为什么Curl能让Docker Login恢复正常？ #

结合上述差异，大概率是以下某一种或多种原因：

1. 刷新了DNS缓存：curl用系统DNS拿到Registry的正确IP，覆盖了Docker daemon缓存的旧IP，解决了"连接到无效IP被拒绝"的问题。
2. 更新了证书信任链：curl验证并存储了新的SSL证书，让Docker daemon后续能通过证书验证，避免了因证书问题导致的连接失败。
3. 清理了网络连接状态：curl的请求触发了网络设备的状态更新，消除了之前阻碍Docker连接的残留连接或规则限制。

永久性修复建议 #

避免依赖curl的临时修复，可以做以下操作：

• 重启Docker daemon：systemctl restart docker，强制刷新Docker的DNS和证书缓存。
• 检查Docker的DNS配置：确保Docker daemon使用的DNS和系统一致，可在/etc/docker/daemon.json中配置"dns": ["x.x.x.x"]指定正确的DNS服务器。
• 手动更新Docker证书：将GitLab Registry的新证书复制到Docker的证书目录/etc/docker/certs.d/<my-domain>:5050/ca.crt。
• 验证Registry的网络可达性：在远程服务器用nslookup <my-domain>对比系统和Docker的解析结果，确认IP一致。

内容的提问来源于stack exchange，提问作者andymel