Docker Compose怎么配置代理？构建、容器与守护进程三层区别

Docker Compose里“代理不生效”，往往不是变量写错，而是写在了错误的层。Docker守护进程负责拉取镜像，构建器负责Dockerfile中的下载，运行中容器再由应用读取代理变量。三者不是同一个进程，也不会自动共享当前终端的环境。

先确定失败发生在 docker pull、docker compose build，还是容器启动后的业务请求，再决定改哪里。

一、三层代理分别负责什么

宿主机curl正常，不能证明守护进程能访问注册表；镜像构建成功，也不能证明运行中应用会走代理。

二、运行中容器如何配置

Compose结构示意：

services:
  app:
    image: example/app:stable
    environment:
      HTTP_PROXY: ${HTTP_PROXY}
      HTTPS_PROXY: ${HTTPS_PROXY}
      NO_PROXY: "localhost,127.0.0.1,db,redis,.internal.example"

这里只展示结构。应用是否读取大小写变量、NO_PROXY是否支持CIDR，要看语言和HTTP库。内部服务名如 db、redis 通常应直连。

三、不要把密码提交到compose.yaml

含凭据的代理URL不应进入Git仓库。可以从受控环境、密钥管理或部署平台注入，但要注意 docker compose config 等命令可能展开变量并显示结果。输出不能贴到公开日志。

.env 也不是天然安全存储，只是方便加载变量。应限制文件权限、排除版本控制并做好轮换。

四、构建阶段为什么更危险

使用Dockerfile ARG 或 ENV 传入密码，可能进入构建历史、缓存或镜像层。优先使用BuildKit的secret或受支持的临时挂载机制，让凭据只在单个构建步骤可用。

构建日志也要脱敏，不打印环境变量和完整下载URL。

五、构建代理和运行代理不要混用

构建只需要访问包仓库时，代理应限制在构建过程；运行应用没有外部访问需求，就不应把代理变量留在最终容器。这样既降低泄露面，也避免内部流量意外绕行。

Docker构建期和运行期的故障差异可参考Docker build能联网但容器不能走代理的原因。

六、Docker守护进程在哪里配置

Linux systemd环境通常需要为Docker服务设置经过批准的代理环境，并执行daemon-reload和重启；桌面版Docker则按产品设置处理。重启守护进程会影响当前容器，生产操作前必须评估。

systemd的drop-in与验证方法见systemd服务代理配置指南。

七、NO_PROXY应包含什么

• localhost和回环地址；
• Compose服务名和内部域名；
• 企业数据库、缓存和服务发现；
• 内部镜像仓库（若要求直连）；
• 必须直连的管理端点；
• IPv6和端口规则按应用能力确认。

错误的NO_PROXY会让容器通过外部代理访问内部数据库，出现502、DNS失败或安全边界变化。

八、修改后怎样让配置生效

容器环境通常在创建时确定。仅重启旧容器不一定应用新的Compose模板，应确认容器被重新创建、环境变量正确，并检查应用是否有内部配置覆盖。

新建连接池后再验证出口，避免旧长连接影响结果。

九、逐层验证顺序

1. 测试守护进程能否拉取批准的测试镜像；
2. 用最小Dockerfile验证构建下载；
3. 在容器内访问内部服务，确认直连；
4. 访问自有外部健康端点，确认代理出口；
5. 检查DNS、IPv4/IPv6和证书；
6. 停止代理后确认失败模式符合设计。

十、常见错误

十一、回滚与安全清理

保留变更前Compose配置哈希、Docker服务drop-in和验证结果。失败时恢复配置、重新创建容器并验证内部与外部路径。撤销测试凭据，清理构建缓存中可能暴露的历史。

配置回滚流程可参考代理配置快照、灰度与恢复演练。

十二、结论

Docker代理配置的正确思路是按守护进程、构建和运行三层分别验证。只在Compose里塞一组变量，既解决不了镜像拉取，也可能让不该代理的内部流量改变路径。