GitLab Runner：定位失败作业阶段的代理设置
Runner 控制、镜像拉取、仓库获取以及作业内下载都可能来自不同的进程。
| 首个失败点 | 需要检查的输入 |
|---|---|
| Runner 连接 GitLab | Runner 服务环境 |
| 拉取作业镜像 | Docker 守护进程/拉取服务 |
| 获取仓库 | 实际的 Git 客户端/辅助程序环境 |
| 作业命令下载 | 容器及该工具自身的客户端设置 |
作业变量对于创建容器时已经需要的镜像拉取来说为时已晚。同样，成功的 Runner 控制连接也无法建立隔离作业的可达性。
对于 127.0.0.1:3128，要定位监听者：作业容器的 loopback 并不是 Runner 主机。只向预期的作业网络授予对主机辅助程序的访问权限，并有意识地管理其上游账户。
先应用已部署的 Runner/执行器所支持的接口，再应用实际下载器与版本相关的选项。将阶段、发起请求的进程和尝试过的端点保留在脱敏诊断信息中，而不是把针对账户的猜测写进共享包装脚本。