GitLab Runner验证正常但接收作业超时，求助排查方案

针对你遇到的Runner作为服务运行时连接超时，但手动以root执行或gitlab-runner用户curl正常的情况，可从以下几个方向排查：

• 检查服务环境变量差异
  服务运行时的环境变量与交互式shell下可能存在区别，尤其是代理、DNS相关配置：

  1. 查看GitLab Runner服务的环境变量配置文件：/etc/default/gitlab-runner 或 /etc/systemd/system/gitlab-runner.service
  2. 对比root与gitlab-runner用户的环境变量：

     # 查看gitlab-runner用户环境变量
     su - gitlab-runner -c "env"
     # 查看root用户环境变量
     env
     

  3. 如果发现代理、DNS变量不一致，在/etc/default/gitlab-runner中添加对应配置（示例）：

     HTTP_PROXY=http://your-proxy-address:port
     HTTPS_PROXY=http://your-proxy-address:port
     NO_PROXY=gitlab.enterprise-url.com,localhost,127.0.0.1
     

  4. 修改后重启服务：

     sudo systemctl daemon-reload && sudo systemctl restart gitlab-runner
     

• 验证非交互式shell下的网络访问
  服务运行在非交互式shell环境，可能加载的配置与交互式不同：

  1. 测试gitlab-runner用户非交互式下的GitLab API访问：

     su - gitlab-runner -c "curl -X POST -I https://gitlab.enterprise-url.com/api/v4/jobs/request"
     

  2. 验证域名解析是否正常：

     su - gitlab-runner -c "nslookup gitlab.enterprise-url.com"
     

     对比root用户的解析结果，确认DNS服务器是否一致

• 检查Runner配置文件权限与内容

  1. 确认/etc/gitlab-runner/config.toml的归属权限：

     ls -l /etc/gitlab-runner/config.toml
     

     若不属于gitlab-runner用户，执行：

     sudo chown gitlab-runner:gitlab-runner /etc/gitlab-runner/config.toml
     

  2. 核对配置文件中的新GitLab URL、注册token是否存在拼写错误

• 排查防火墙与安全策略限制

  1. 检查ufw防火墙规则，确认允许访问GitLab的HTTPS端口：

     sudo ufw status
     # 若需添加规则
     sudo ufw allow out to gitlab.enterprise-url.com port 443
     

  2. 若启用SELinux，临时设置为宽容模式测试：

     sudo setenforce 0
     

     重启Runner服务后观察是否恢复，若恢复则需添加SELinux规则允许网络访问

• 查看服务详细日志
  实时查看Runner服务日志，获取更详细的错误信息：

  sudo journalctl -u gitlab-runner -f
  

  对比手动运行gitlab-runner run时的日志，定位差异点

内容的提问来源于stack exchange，提问作者Grannas