GitLab Runner显示绿色在线，只说明Runner能够向GitLab领取任务，不代表Job容器能访问代码仓库、包仓库或外部API。Shell、Docker和Kubernetes执行器的网络边界不同；即使使用同一个Runner名称，请求实际也可能从宿主机、容器或Pod发出。
一、先确认执行器类型
| 执行器 | Job执行位置 | 代理重点 |
|---|---|---|
| Shell | Runner宿主机 | 服务账号环境与工具配置 |
| Docker | Job容器 | 守护进程、辅助容器、Job环境 |
| Kubernetes | 临时Pod | Pod变量、集群DNS、镜像拉取与CA |
| SSH等 | 远程目标 | 远程用户与主机网络 |
二、Runner服务代理控制什么
Runner服务自身需要访问GitLab API、提交状态和日志。若它由systemd启动，应把代理放在服务实际读取的环境中，并执行配置重载和服务重启。管理员终端里的环境变量不会自动传给已经运行的服务。
服务配置方法可参考systemd服务代理与EnvironmentFile。
三、Shell执行器为什么也会环境不一致
Shell Job通常以Runner服务账号执行，不是管理员当前登录账号。它读取的Home目录、Git配置、CA与包管理器配置可能不同。排查时应在同一服务账号下运行最小命令，并确认环境变量由Runner传入，而不是依赖交互Shell初始化文件。
四、Docker执行器至少有三条链路
- Docker守护进程拉取Job镜像；
- Runner或辅助容器执行代码检出和制品操作；
- Job容器安装依赖并访问业务API。
给Job设置HTTPS_PROXY不一定能解决守护进程拉镜像失败；给守护进程配置代理，也不会自动注入Job容器。三层区别可参考Docker代理分层指南。
五、Kubernetes执行器要看Pod和节点
Job脚本在Pod中运行，镜像拉取由节点容器运行时完成。Pod内还使用集群DNS和网络策略。若Provider API、内部服务或Kubernetes Service应直连，需谨慎设计绕过列表。相关边界见Kubernetes代理与NO_PROXY排查。
六、代码检出和Job命令为什么可能表现不同
代码检出可由Runner辅助流程完成，而脚本中的Git命令、npm或curl由Job容器执行。前者成功只能证明仓库访问链路可用。应分别记录失败阶段：准备环境、拉取源码、下载缓存、执行脚本、上传制品还是任务清理。
七、NO_PROXY应该如何设计
自建GitLab、Runner内部地址、对象存储、制品库、容器注册表和集群服务可能需要直连，但不同程序对域名后缀、端口、CIDR与IPv6的匹配规则不一致。先列出具体目标，再在Runner服务、辅助容器和Job容器中分别测试。
八、证书信任为何常在容器里失败
宿主机已安装企业CA，不代表基础镜像包含同一证书。Job容器、辅助镜像和Java工具还可能使用不同信任库。不要通过关闭TLS验证让流水线暂时通过，应更新受控镜像或在启动时安全分发证书，并验证域名与证书链。
九、代理凭据怎样注入更合适
- 使用受保护、掩码的CI变量；
- 限制变量只对受信任分支和环境开放；
- 关闭会打印命令参数的非必要调试；
- 避免在Dockerfile中用ARG固化明文密码；
- 不要把完整环境变量作为作业产物上传。
十、缓存和制品失败不能只查Git
缓存与制品可能上传到GitLab本身或独立对象存储，目标域名和认证与代码仓库不同。若Job执行完成却在最后失败，应检查上传阶段的代理、分片、超时和证书，而不是继续修改源码检出设置。
十一、最小排查流程
- 记录Runner版本、执行器和失败阶段；
- 确认请求从宿主机、容器还是Pod发出；
- 检查实际进程的代理变量与CA；
- 分别验证GitLab、注册表、依赖仓库和缓存地址；
- 区分407、目标401、TLS和连接超时；
- 重建临时容器或Pod，排除旧环境；
- 清理测试变量并审查日志是否泄密。
十二、结论
GitLab Runner代理故障必须结合执行器分析。Runner在线、源码检出成功和Job联网正常是三件事；只有定位实际请求位置，并对服务、运行时和Job分别验证，配置才会稳定。
