容器构建与运行阶段：代理IP 配置该如何分别验证

同一个镜像的构建和运行由不同进程发起外部请求，代理配置和网络路径需要分别验证。基础镜像拉取、构建步骤中的依赖下载，以及容器内应用请求可能经过不同出口；不能仅凭“容器能联网”推断它们都使用了预期代理。

构建阶段和运行阶段为什么要分别验证

• 构建期包含 builder/daemon 拉取基础镜像，以及构建步骤中的 RUN apt-get、pip install、npm ci 等网络请求；两者可能走不同配置和路径，需分开核对。
• 运行期请求由容器内的应用进程发起。容器重启后环境变量仍在，但连接会重新建立。

两条路径的共同点是都会受宿主网络、DNS 和出口影响；不同点在于配置来源和验证手段。构建期代理可通过 Docker 预定义代理参数或 builder/daemon 配置提供；运行期代理来自环境变量、编排文件或应用自身配置。把它们混在一起验证，最常见的结果是"构建能过、运行超时"，或者反过来。

构建镜像时如何把代理配置传进容器

不要把含凭据的代理 URL 写进 Dockerfile。Docker 的 HTTP_PROXY、HTTPS_PROXY 等是预定义代理构建参数，通常通过构建命令或 Docker 客户端配置传入，无需在 Dockerfile 声明或引用。官方文档说明这些预定义参数有专门的缓存与历史处理规则，避免自行复制到普通 ARG。

基础镜像拉取由 builder/daemon 路径处理，需和构建步骤中的下载分开核验。具体行为以实际 Docker/buildx 版本为准，参见 Docker proxy arguments。不要通过 env 原样输出代理变量，以免构建日志记录凭据。

如何确认镜像构建真的通过代理下载依赖

构建日志能证明命令执行了，不能单独证明依赖下载走了代理。记录 Docker/buildx 版本、builder 类型及缓存状态；缓存命中时构建步骤可能没有发出网络请求。用受控依赖请求和代理侧或目标服务日志核验实际到达。

• 记录 Docker/buildx 版本、builder 类型和相关缓存是否命中。缓存命中时该步骤可能没有发出网络请求。

• 观测点：脱敏配置检查 ｜ 构建期含义：变量是否存在及来源 ｜ 通过标准：仅显示存在性、脱敏主机/端口，不输出凭据
• 观测点：受控依赖请求 ｜ 构建期含义：包管理器是否实际发出请求 ｜ 通过标准：代理或目标侧日志能关联到请求
• 观测点：缓存状态 ｜ 构建期含义：是否真实执行下载 ｜ 通过标准：明确标记命中/未命中缓存
• 观测点：builder 信息 ｜ 构建期含义：结果适用范围 ｜ 通过标准：记录 Docker/buildx 版本与 builder 类型

缓存会影响是否发生网络请求。验证前确认相关构建层及包管理器缓存状态；必要时使用干净测试缓存或不同测试依赖，避免未实际下载却将构建成功当作代理生效证据。

构建参数行为见 Docker proxy arguments；运行期参数配置可对照代理设置帮助。

容器运行时如何确认代理配置来自哪里

运行期代理可来自命令行、编排文件、镜像环境或应用配置。变量进入容器不代表每个进程都会读取；逐个副本检查配置来源，并用目标日志、代理到达记录和应用实际出口互证。检查时仅输出变量存在性及脱敏后的主机、端口，绝不打印凭据。

变量存在不等于生效。语言和库的默认行为不同，必须按实际技术栈验证：

• Python 的 requests 常见版本默认 trust_env=True，会读环境变量，具体以版本为准。
• Axios 在 Node.js 的适用 HTTP adapter 中可读取代理环境变量；proxy: false 可禁用 Axios 的代理处理。Fetch、定制 adapter 或 agent 的行为应单独验证，记录 Axios 版本、adapter 和最终出口。参见 Axios request config。
• Go 的 http.ProxyFromEnvironment 从进程环境解析代理配置，需按所用 Go 版本和客户端行为验证实际请求。

如何区分容器网络和宿主机网络造成的问题

容器里的 127.0.0.1 指向容器自身，不是宿主机。代理跑在宿主机上时：

• bridge 网络：容器访问宿主机要用 host.docker.internal（Docker Desktop）或网桥网关 IP，不能写 127.0.0.1。
• --network host：容器与宿主机共享网络命名空间，此时 127.0.0.1 才指向宿主机。
• 代理在另一个容器里：用 Compose 服务名或自定义网络内的容器 IP。

这个区别解释了最常见的"构建时能通、运行时连不上"：构建阶段的基础镜像拉取发生在守护进程侧，RUN 内下载发生在构建容器里，网络路径和容器内应用完全不同。

容器网络连接问题可用智能检测助手辅助排查，但最终仍需用应用请求和代理/目标记录互证。

用什么证据验收构建期和运行期代理

• 阶段：构建期 ｜ 注入方式：Docker 预定义代理参数 / 客户端配置 ｜ 生效范围：builder 支持的构建步骤 ｜ 观测点：受控依赖请求及代理/目标到达记录 ｜ 判定：验证具体下载是否经过预期路径
• 阶段：运行期 ｜ 注入方式：docker run -e / 编排配置 ｜ 生效范围：变量可见于容器进程；是否使用取决于应用库 ｜ 观测点：脱敏配置、目标日志和实际请求出口 ｜ 判定：按应用及副本逐个验证
• 阶段：运行期 ｜ 注入方式：编排文件 environment ｜ 生效范围：服务内所有副本 ｜ 观测点：副本日志、出口 IP ｜ 判定：与预期一致
• 阶段：宿主机代理 ｜ 注入方式：网关 IP / host.docker.internal ｜ 生效范围：依赖网络模式 ｜ 观测点：连接测试、抓包 ｜ 判定：能连到代理端口

每个阶段分别保存注入来源、具体请求进程、缓存状态及实际请求到达证据。变量进入进程不代表应用读取；只有受控下载或业务请求与代理/目标记录能够关联，才支持“该请求经代理”的结论。

验收时按阶段分别判定：构建期核对具体依赖下载的代理/目标到达记录；运行期核对实际应用请求及具体副本的路径。任一阶段缺证据，就补测该阶段，不要用另一阶段的结果替代。

FAQ

Q：可以在 Dockerfile 里直接写 ENV HTTP_PROXY 吗？

A：不要把含凭据的代理 URL 写入 Dockerfile 或镜像。优先使用 Docker 支持的预定义代理参数或受控秘密注入，并检查日志、构建缓存和最终镜像；多阶段构建本身不能证明凭据已清理。

Q：构建成功但运行时报代理连接失败，先查什么？

A：先确认运行期实际使用的代理IP可达、地区与预期一致，再查网络路径。宿主机代理在 bridge 网络下无法通过 127.0.0.1 访问，换成网关 IP 或 host.docker.internal 再试。

Q：怎么确认运行期用的是我设置的代理，而不是镜像里自带的？

A：先只检查脱敏后的变量来源，再通过应用真实请求的目标日志或代理到达记录确认。变量存在不代表应用会读取；不要打印完整环境变量或代理凭据。