如何在 CI Runner 中验证代理不会影响构建步骤

判断代理是否影响 CI，不能只看最终构建是否成功。应按实际流程检查代码拉取、依赖安装、单元测试、构建和产物上传。代理配置可能来自环境变量、包管理器或容器后台服务；配置不一致时，本地命令与流水线可能表现不同。

如何判断代理没有影响 CI 构建

按顺序检查代码是否拉取到相同 commit、依赖校验是否通过、单元测试结果是否与基线一致。构建可复现时比较产物哈希；否则比较关键文件和依赖清单。上传环节要确认远端文件实际存在，并在支持时核对摘要或完整性校验。各阶段记录退出码和耗时；确需记录出口 IP 时，应使用受控日志并隐藏代理凭据。

检查 CI 环境变量、包管理器和容器的代理配置

先检查构建进程是否读取 HTTP_PROXY 和 HTTPS_PROXY，再确认 NO_PROXY 中哪些地址会绕过代理。npm、pip 和 Maven 也可能分别读取 .npmrc、pip.conf 或 settings.xml；容器拉取镜像则由容器后台服务的配置决定。不要只凭宿主机环境变量判断代理已经生效。

配置入口和协议参数可对照代理设置帮助逐项核实。

对比启用代理和不启用代理时的构建结果

在相同 commit、Runner 镜像、依赖来源和资源规格下，分别运行启用代理与不启用代理的任务。冷缓存和暖缓存应分开比较，并使用隔离的缓存目录；每组可重复运行并保留原始结果。除代理开关外，其他条件尽量保持一致，便于判断差异来源。

区分正常的耗时变化与构建产物差异

代理会让下载耗时发生变化，但不能预设“代理一定更慢”。判断是否影响构建，用各阶段耗时分布和事前设定的预算，不用单次耗时下结论；产物对照的前提是构建可复现、非确定性元数据已规范化；做不到时改比依赖清单、测试结果、关键文件和构建日志，不能仅凭整体哈希变化判定代理造成回归。

两类误判最常见：NO_PROXY 漏配，内部制品库被送进代理，出现 407 或超时；缓存掩盖失败，上一次的缓存让本次跳过了真实下载，清缓存复跑才暴露问题。

记录 CI 代理测试结果并设定验收条件

记录 Runner 镜像、commit、实际生效的代理配置和各阶段结果，并注明缓存命中情况。被缓存跳过的步骤应标为未覆盖，必要时单独补跑。所有相关阶段通过后，再依据构建是否可复现判断产物差异。若影响其他流水线、日志出现凭据或耗时超过预算，应停止并回滚配置。

CI 中出现连接失败时，可从全球代理帮助中心查找官方接入说明。

相关机制说明：

• npm ci 的安装与校验行为
• GitHub Actions 依赖缓存

常见问题

CI 里设了 HTTP_PROXY 为什么还是不走代理？

可能被 NO_PROXY 覆盖，或包管理器有独立配置，以实际生效的配置为准。

构建成功就说明代理没影响吗？

不一定。缓存可能掩盖下载失败，需要清缓存复跑并比对产物。