手把手教你用Docker Proxy解决registry-1.docker.io超时问题（2024最新）

手把手构建企业级Docker镜像加速代理：告别registry-1.docker.io超时

你是否经历过这样的场景：在自动化流水线中，一个关键的Docker镜像拉取任务因为Error response from daemon: Get "https://registry-1.docker.io/v2/"而卡住，整个CI/CD流程随之停滞？或者，当你管理着数十上百台Docker主机时，发现它们对Docker Hub的访问时好时坏，稳定性完全依赖于外部网络环境？对于追求稳定性和可控性的企业级DevOps团队而言，仅仅更换公共镜像源往往只是权宜之计。今天，我们将深入探讨一种更底层、更可控的解决方案——自建Docker专用代理服务器。这不仅是为了解决超时问题，更是为了构建一个可观测、可优化、完全自主掌控的镜像分发基础设施。

本文将聚焦于使用Squid和Nginx这两种成熟稳定的开源软件，搭建一个高性能、支持TLS的HTTP/HTTPS代理，专门服务于Docker守护进程。我们将超越简单的配置修改，深入到TCP连接优化、TLS会话复用、连接池管理等实战细节，并提供可直接在生产环境中使用的配置模板。无论你是需要为整个数据中心的上百个Docker节点提供统一出口，还是仅为本地开发环境构建一个可靠的缓存层，这篇文章都将提供一套完整、可落地的技术方案。

1. 为什么镜像源替换之外，还需要自建代理？

当遇到registry-1.docker.io超时，很多人的第一反应是修改/etc/docker/daemon.json，添加国内的镜像加速器。这确实能解决大部分个人开发者的问题。但在企业级场景下，这种做法存在几个明显的局限性：

• 稳定性依赖第三方：公共镜像加速器的可用性和速度不受你控制，一旦其服务出现波动或中断，你的所有构建和部署都会受到影响。
• 缺乏缓存与带宽节省：同一个镜像，可能被集群内的多个节点反复从远程拉取，消耗大量出口带宽，并增加拉取延迟。
• 无审计与访问控制：你无法清晰地知道哪些镜像被拉取、由谁拉取，也无法对拉取行为设置任何策略。
• 复杂网络环境的穿透问题：在企业内网、隔离环境或具有严格出口策略的网络中，Docker守护进程可能无法直接访问任何外部Registry，需要一个内部代理作为统一的出口网关。

自建代理服务器的核心价值在于将不可控的外部依赖，转化为内部可管理、可优化的服务。它扮演着“智能网关”的角色，不仅能转发请求，更能实现连接复用、内容缓存、访问日志记录，甚至进行流量整形和安全策略实施。

注意：本文讨论的代理方案，是在Docker守护进程层面配置HTTP_PROXY/HTTPS_PROXY，让Docker Daemon通过代理服务器访问外部网络。这与配置registry-mirrors是两种不同维度、可以共存的解决方案。

2. 方案选型：Squid vs. Nginx

在构建HTTP代理时，Squid和Nginx是两个最主流的选择。它们各有侧重，适用于不同的场景。

Squid：专业的缓存代理 Squid诞生之初就是一个强大的Web缓存代理，其缓存逻辑非常成熟和高效。对于Docker镜像拉取这种场景——大量GET请求获取不变的层（Layer）数据——Squid的缓存能力可以发挥巨大作用。第一次拉取镜像后，其数据块会被缓存在Squid服务器上，后续同一集群内其他节点的拉取请求将直接从缓存命中，速度极快，并极大节省出口带宽。

Nginx：高性能的反向代理与负载均衡器 Nginx的核心优势在于其高并发、低内存占用的非阻塞I/O模型。虽然它也可以通过ngx_http_proxy_module模块作为代理服务器，但其缓存功能相比Squid稍显基础。Nginx更擅长做请求的转发、负载均衡和SSL终结。

为了更清晰地对比，我们通过下表来决策：