每个人都可以，
拥有SSL证书

碰到这个报错，是在一次 docker pull 的时候突然弹出来的： error response from daemon: get "https://registry-1.docker.io/v2/": read tcp 意思很直白，docker daemon 往 registry-1.docker.io 发请求的时候 tcp 读失败了，根本连不上。

这种问题不用急着改配置，先确认到底哪一环节不通。我习惯直接用 curl 测一下： curl -v https://registry-1.docker.io/v2/ 如果返回 200 OK 或者 401 Unauthorized，说明从当前机器到 Docker Hub 的链路是通的，401 只是因为没带认证而已，很正常。但要是返回 Connection refused 或者直接超时，那宿主机网络层面肯定有问题。

网络不通的话，下一个怀疑对象就是 DNS。

试一下 nslookup registry-1.docker.io 或者 dig registry-1.docker.io，如果解析不出来，去看看 /etc/resolv.conf 里是不是配了有效的 DNS，没有就加上，比如 8.8.8.8 或 114.114.114.114。有时候容器宿主用的是内部 DNS，结果解析不了外部域名，这个也容易被忽略。

如果 DNS 没问题，但 curl 还是不通，那就要看是不是走了代理。公司内网环境经常需要代理出站，但 Docker daemon 的代理是不会自动读取系统环境变量的，得显式配。在 /etc/systemd/system/docker.service.d/ 下建一个 http-proxy.conf，内容像这样： [Service] Environment="HTTP_PROXY=http://proxy.example.com:8080" Environment="HTTPS_PROXY=http://proxy.example.com:8080" 写完后记得 daemon-reload 再 restart docker。这里其实容易踩坑，很多人配了代理但没 reload，或者只在当前 shell 里 export 了一下，daemon 完全感知不到。

防火墙也可能出来坏事。

测试阶段可以先临时关一下看看，CentOS 用 systemctl stop firewalld，Ubuntu 用 ufw disable。如果关了就通，那就是防火墙规则的问题，需要在策略里放行相关流量。如果只是连 registry，大部分场景走 443，但要是在 Docker Swarm 环境下，还有一些端口比如 UDP 4789、TCP 2377 等等也不能拦，不然集群通信会受影响。

还有一种情况我遇到过几次，/etc/docker/daemon.json 里的 JSON 写错了，导致 daemon 行为异常，甚至可能影响网络初始化。

cat 一下看看内容是不是合法 JSON，如果不是就赶紧修正，然后重启 docker。

如果上面的步骤都走完了网络依然是通的，但感觉官方源拉镜像太慢或者偶尔超时，可以换国内镜像加速。还是在 /etc/docker/daemon.json 里加一段： { "registry-mirrors": ["https://.mirror.aliyuncs.com"] } 替换成你自己的阿里云加速地址，重启 docker 之后 pull 的时候就会优先走镜像源了。

事情到了这一步如果还是没解决，就需要上点调试手段了。可以把 docker daemon 拉到前台直接看日志：sudo dockerd --debug，或者改 /etc/docker/daemon.json 加 "debug": true 然后重启，日志里会打出很多连接细节。

另外 tcpdump 抓包也很有用，执行 sudo tcpdump -i any host registry-1.docker.io -nnvv，能清楚看到请求到底发出去没有，有没有收到 SYN/ACK，是不是某个中间设备把 RST 甩回来了。定位到是本地没发出还是远端无响应，排查方向就完全不一样了。

这个报错一路排查下来，起因无非就是网络不通、DNS 解析失败、代理没配好或者防火墙拦了。出问题的时候按这个顺序摸一遍，基本都能找到原因。

平时运维最好还是把基础监控和日志配好，别等业务报错了才发现 daemon 连不上注册表。