### [GitLab Runner怎么配置代理？Shell、Docker、Kubernetes执行器排查](https://www.jiyueip.com/article/7995)

**Published:** 2026-07-22T18:30:29

**Author:** 斑斓助理

**Excerpt:** GitLab Runner使用Shell、Docker或Kubernetes执行器时，服务进程、代码拉取、辅助镜像和Job容器的代理边界不同。本文说明环境变量、NO_PROXY、证书与凭据管理。

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](https://www.jiyueip.com/article/7931)。

## 三、Shell执行器为什么也会环境不一致

Shell Job通常以Runner服务账号执行，不是管理员当前登录账号。它读取的Home目录、Git配置、CA与包管理器配置可能不同。排查时应在同一服务账号下运行最小命令，并确认环境变量由Runner传入，而不是依赖交互Shell初始化文件。

## 四、Docker执行器至少有三条链路

-   Docker守护进程拉取Job镜像；
-   Runner或辅助容器执行代码检出和制品操作；
-   Job容器安装依赖并访问业务API。

给Job设置`HTTPS_PROXY`不一定能解决守护进程拉镜像失败；给守护进程配置代理，也不会自动注入Job容器。三层区别可参考[Docker代理分层指南](https://www.jiyueip.com/article/7951)。

## 五、Kubernetes执行器要看Pod和节点

Job脚本在Pod中运行，镜像拉取由节点容器运行时完成。Pod内还使用集群DNS和网络策略。若Provider API、内部服务或Kubernetes Service应直连，需谨慎设计绕过列表。相关边界见[Kubernetes代理与NO\_PROXY排查](https://www.jiyueip.com/article/7929)。

## 六、代码检出和Job命令为什么可能表现不同

代码检出可由Runner辅助流程完成，而脚本中的Git命令、npm或curl由Job容器执行。前者成功只能证明仓库访问链路可用。应分别记录失败阶段：准备环境、拉取源码、下载缓存、执行脚本、上传制品还是任务清理。

## 七、NO\_PROXY应该如何设计

自建GitLab、Runner内部地址、对象存储、制品库、容器注册表和集群服务可能需要直连，但不同程序对域名后缀、端口、CIDR与IPv6的匹配规则不一致。先列出具体目标，再在Runner服务、辅助容器和Job容器中分别测试。

## 八、证书信任为何常在容器里失败

宿主机已安装企业CA，不代表基础镜像包含同一证书。Job容器、辅助镜像和Java工具还可能使用不同信任库。不要通过关闭TLS验证让流水线暂时通过，应更新受控镜像或在启动时安全分发证书，并验证域名与证书链。

## 九、代理凭据怎样注入更合适

-   使用受保护、掩码的CI变量；
-   限制变量只对受信任分支和环境开放；
-   关闭会打印命令参数的非必要调试；
-   避免在Dockerfile中用ARG固化明文密码；
-   不要把完整环境变量作为作业产物上传。

## 十、缓存和制品失败不能只查Git

缓存与制品可能上传到GitLab本身或独立对象存储，目标域名和认证与代码仓库不同。若Job执行完成却在最后失败，应检查上传阶段的代理、分片、超时和证书，而不是继续修改源码检出设置。

## 十一、最小排查流程

1.  记录Runner版本、执行器和失败阶段；
2.  确认请求从宿主机、容器还是Pod发出；
3.  检查实际进程的代理变量与CA；
4.  分别验证GitLab、注册表、依赖仓库和缓存地址；
5.  区分407、目标401、TLS和连接超时；
6.  重建临时容器或Pod，排除旧环境；
7.  清理测试变量并审查日志是否泄密。

## 十二、结论

GitLab Runner代理故障必须结合执行器分析。Runner在线、源码检出成功和Job联网正常是三件事；只有定位实际请求位置，并对服务、运行时和Job分别验证，配置才会稳定。

**Tags:** HTTP代理, 服务器运维, 终端代理, 网络故障排查

**Categories:** 行业洞察

---