核心是网络链路、DNS、代理或配置失配导致TLS握手卡顿，需依次验证连通性、配置镜像加速器、指定DNS、设置代理、切换私有仓库或调高超时参数。
内网拉取 HTTPS 镜像仓库时出现“TLS handshake timeout”，核心是 Docker 客户端无法在规定时间内完成与远端服务器的加密连接建立。这不是镜像本身的问题，而是网络链路、DNS、代理或配置协同失配导致的握手卡顿。解决重点不在重试，而在打通 TLS 握手前的每一段路径。
确认是否真卡在 TLS 握手阶段
先区分是连接失败，还是握手失败。运行以下命令观察响应行为：
-
curl -vI https://registry-1.docker.io/v2/ —— 若卡在
* TLS handshake, Client hello (1)或数秒后报SSL connect error，基本确定是 TLS 握手超时； - 若直接报
Could not resolve host，则是 DNS 解析失败； - 若提示
Connection refused或长时间无响应，说明网络层不通（如防火墙拦截 443 端口）。
检查并优化 DNS 解析
内网环境常复用上游 DNS（如 10.0.0.1），但该 DNS 可能响应慢、缓存过期或不支持 HTTPS 记录查询，导致域名解析耗时远超 TLS 超时阈值（默认约 30 秒）。
- 手动测试：运行 nslookup registry-1.docker.io，看是否返回 IPv4 地址且耗时 < 1 秒；
- 若延迟高或失败，在 /etc/docker/daemon.json 中显式指定公共 DNS：
保存后执行 sudo systemctl daemon-reload && sudo systemctl restart docker 生效。
配置可信镜像加速源或私有仓库
内网直连海外 HTTPS 仓库（如 registry-1.docker.io）极易因跨境链路抖动导致握手中断。优先切换为可控路径：
- 使用国内镜像加速器（如阿里云、腾讯云），获取专属地址（形如
https://xxxxx.mirror.aliyuncs.com），填入registry-mirrors； - 若已有私有 Harbor 或 Nexus 仓库，确保其 HTTPS 证书有效（非自签名或已加入系统信任链），并在
daemon.json中添加对应地址； - 避免混用多个不稳定镜像源，建议只保留 1–2 个经实测可用的地址。
验证代理与防火墙策略
内网通常需经 HTTP/HTTPS 代理访问外网，但 Docker 默认不继承 shell 的 http_proxy 环境变量，必须显式配置：
- 创建代理配置文件：sudo mkdir -p /etc/systemd/system/docker.service.d，新建
http-proxy.conf，内容为：
- 重启服务：sudo systemctl daemon-reload && sudo systemctl restart docker；
- 检查防火墙是否放行出站 443 端口：sudo ufw status（Ubuntu）或 sudo firewall-cmd --list-ports（CentOS）；
- 临时关闭防火墙测试是否恢复，再针对性开放规则。
