Docker 拉取 HTTP 仓库报 server gave HTTP response to HTTPS client
HTTP仓库的例外需由实际拉取daemon读取。检查context、完整镜像地址和生效配置,区分协议、证书与后续认证错误。
私有仓库只提供 HTTP,Docker 拉取镜像却访问 HTTPS,并报 http: server gave HTTP response to HTTPS client。如果已经配置了 insecure-registries,先确认配置被发起拉取的那个 Docker daemon 读取,以及条目是否匹配镜像引用的主机和端口。
这条错误表示 TLS 请求遇到了 HTTP 响应,但响应也可能来自接错的端口或代理。先确认目标本来应该提供什么协议,不能给所有出现此错误的仓库统一关闭 TLS 检查。
先核对目标协议和镜像地址
查看失败日志中的请求地址、完整镜像引用,以及仓库或反向代理的实际监听设置。registry.example.net:5000/team/app:release 是镜像引用示例,主机、端口、路径与标签各有作用。不能配置了一个 IP 的例外,却用另一域名访问后期待自动匹配。
若该端口本来应当提供 HTTPS,先修正代理转发、监听端口或 TLS 终止设置。若错误是证书不受信任,而服务确实能完成 TLS 握手,应采用仓库 CA 信任配置的处理,不要用 HTTP 仓库例外掩盖证书问题。
长期使用的仓库应提供合适的 TLS 和可信证书。下面的 HTTP 例外只适合已经批准的测试范围,它允许未加密或不受信任的通信,不能用真实敏感凭据随意试错。
客户端所在机器不一定是 daemon 所在机器
在失败命令使用的同一终端查看:
docker context show
docker version
docker info
对照实际连接的后端、服务端版本和 info 中的 Insecure Registries。远程 context 下,需要核对远端 daemon;本机 /etc/docker/daemon.json 不会自动成为另一台机器的配置。终端或用户不同,也可能连接了不同的后端。
对普通 rootful Linux Engine,默认配置文件为 /etc/docker/daemon.json,daemon 还可能通过 --config-file 指定其他位置。应查看现有服务启动方式确认真实文件。Rootless、Docker Desktop 等环境另有自己的配置入口,不能在桌面电脑上创建一份 Linux 默认路径就认为有效。
~/.docker/config.json 主要是客户端配置,不是向远端 Engine 声明 insecure-registries 的替代入口。也不要为这个错误删除整个 ~/.docker,其中可能保存 context 和认证相关设置。
把例外写进实际使用的 daemon 配置
确认测试仓库只提供 HTTP、实际地址为示例中的主机端口,并且获准使用这种传输时,相关配置为:
{
"insecure-registries": ["registry.example.net:5000"]
}
这里填写主机和端口,不加 http://,也不加 /team/app 镜像路径。这只是片段,应合并到原 JSON,保留其他已存在设置和例外条目,不能直接覆盖整份 daemon 配置。
将范围限制到确实需要的测试目标,不要因为一个仓库就把整个网络都列为 insecure。保存原文件,并核对同一选项是否又在 daemon 启动参数中声明;当前 Docker 会检查文件与 CLI 参数冲突,不能把重复声明当成双重保障。
systemd 环境不一定读取历史 /etc/default/docker 中的 DOCKER_OPTS。应依据当前服务定义,而不是只编辑一个曾经在其他系统有效的文件。
应用配置后,检查生效结果
当前 dockerd 支持通过配置重载更新 insecure-registries,无需把重启整个 daemon 作为每次修改的必经步骤。Linux 上重载涉及 SIGHUP;应由已有运维入口按实际服务与版本执行,并检查 daemon 日志是否接受变更,避免发给错误进程。
若配置与启动参数冲突或格式有误,重载失败不等于旧进程会停止,也不等于新设置已生效。重新读取同一后端的 docker info,核对预期条目,再对批准的测试镜像进行原先失败的拉取。
只有实际版本、部署入口要求重启时,才先评估运行容器的影响并安排窗口。修改一个仓库选项不应顺带清理镜像、删除数据卷或重建无关服务。
TLS 协议错误消失后,仍可能出现认证、权限或镜像标签不存在等错误,应按新阶段继续处理。成功标准是从预期仓库取得正确的镜像,而不是错误信息换了一条。
回退时恢复本次修改前的配置,并按相同入口应用、核对生效结果。测试例外撤销后还应确认仓库的正常 TLS 配置,不能把一次临时 HTTP 放行留成长期默认设置。


