近期，众多Docker用户反馈一个令人困扰的问题：即便在系统或用户环境中正确配置了HTTP_PROXY、HTTPS_PROXY等代理变量，Docker守护进程或部分容器运行时依然无视这些设置，直接发起直连请求。这一问题在混合云环境、企业内网及跨境开发场景中尤为突出，导致镜像拉取失败、构建中断甚至安全策略失效。本文将深入分析这一现象的成因，并提供经过验证的修复方案。

问题重现：代理设置“失灵”的典型场景

一位在金融机构工作的DevOps工程师描述了他的遭遇：团队已在/etc/environment和用户~/.bashrc中分别添加了以下内容：

export HTTP_PROXY=http://proxy.internal:8080
export HTTPS_PROXY=http://proxy.internal:8080
export NO_PROXY=localhost,127.0.0.1,.local

然而，执行docker pull nginx:latest时，命令报告“Timeout exceeded”，抓包发现流量直接试图连接Docker Hub的IP，而非经过代理服务器。类似情况也发生在docker build过程中，当Dockerfile中包含apt-get update等需要外网访问的指令时，构建层卡死。

根源分析：Docker代理机制的“分层陷阱”

Docker的代理配置存在三层独立的机制，用户常因忽视层级关系而导致设置失效。

第一层：Client端代理
docker build、docker pull等命令在执行时，会读取当前shell环境中的HTTP_PROXY等变量。这是最常见的配置方式。但问题在于：如果执行docker pull的是普通用户，而dockerd守护进程以root身份运行，则client端代理仅作用于命令本身的HTTP请求，不覆盖守护进程发起的请求。

第二层：Daemon端代理
Docker守护进程负责管理镜像层、网络、存储等底层操作。当docker pull触发镜像层下载时，实际网络请求由dockerd发起。此时，守护进程并不会自动继承用户的环境变量，必须显式配置。许多用户遗漏了这一步，导致“伪装正常、实际失效”。

第三层：容器内部代理
进入容器后，apt-get、pip install等命令默认不继承宿主机的代理变量。需要在Dockerfile中用ENV指令或运行时传入--env参数来设置。这一机制常被混淆为“宿主机代理失效”，实际上只是容器环境隔离的正常行为。

官方推荐解决方案：逐层锁定

针对Daemon端代理忽略问题，Docker官方给出了明确的配置方法（基于Systemd环境）：

  1. 创建或编辑/etc/systemd/system/docker.service.d/http-proxy.conf文件： [Service] Environment="HTTP_PROXY=http://proxy.internal:8080" Environment="HTTPS_PROXY=http://proxy.internal:8080" Environment="NO_PROXY=localhost,127.0.0.1,.local"

  2. 重载systemd并重启Docker： bash systemctl daemon-reload systemctl restart docker

  3. 验证配置生效： bash systemctl show docker --property Environment

如果使用自己的init系统或直接执行dockerd命令，可在启动参数中加入--env HTTP_PROXY=...，或修改/etc/docker/daemon.json添加"http-proxy"字段（注意：此字段是实验性特性，建议优先使用systemd方法）。

对于Client端，确保每次执行docker命令前，代理变量已导出。可将配置写入~/.docker/config.json（适用于Docker Desktop）：

{
  "proxies": {
    "default": {
      "httpProxy": "http://proxy.internal:8080",
      "httpsProxy": "http://proxy.internal:8080",
      "noProxy": "localhost,127.0.0.1,.local"
    }
  }
}

对于容器内部，最佳实践是在Dockerfile中显式设置：

ENV HTTP_PROXY=http://proxy.internal:8080
ENV HTTPS_PROXY=http://proxy.internal:8080

或在运行容器时添加--env参数。

常见误解与踩坑点

  • 环境变量优先级混淆：daemon.json中配置的代理优先级高于systemd环境变量？实际上并不存在这种层级关系。Docker官方文档强调，systemd是推荐且稳定的方式，而daemon.json的代理字段仍处于实验阶段。
  • NO_PROXY格式错误：NO_PROXY中通配符星号（*）仅部分实现支持，建议使用CIDR格式或精确域名。例如"*.local"可能不会被识别，而.local（无星号）通常可豁免。
  • HTTP_PROXY与http_proxy大小写：多数Linux工具识别小写版本，但Docker官方示例使用大写。安全起见应同时设置两种大小写变体。

结语

“Docker服务忽略代理”的本质是用户未能理解多级代理作用域。通过分别配置Client端、Daemon端和容器内部的环境变量，并确保使用正确的配置文件路径，90%以上的直连问题均可解决。对于仍存疑的复杂场景（如多网卡、透明代理环境），建议使用tcpdump结合curl --proxy进行定向排查。代理配置无小事，尤其在安全敏感的企业环境中，正确的代理策略不仅关乎效率，更是网络隔离的基石。