CentOS环境下GitLab Runner注册失败（连接被拒绝）问题排查求助

问题分析 #

从你描述的情况来看，GitLab Runner本身是正常工作的——毕竟连接gitlab.com时能正确返回「令牌错误」的提示，说明runner的网络请求能力、程序逻辑都没问题。问题大概率出在你自己的GitLab实例或者两台服务器之间的网络/配置限制上，以下是几个最可能的原因及排查方向：

• GitLab实例的HTTPS服务未正常运行
  能ping通IP只能说明网络可达，但443端口（HTTPS默认端口）可能没有被GitLab的web服务监听。你可以在GitLab服务器上执行以下命令检查443端口的监听状态：

  ss -tulpn | grep :443
  

  如果没有任何输出，说明GitLab的内置nginx（或web服务）没启动。尝试重启GitLab服务：

  sudo gitlab-ctl restart
  

  重启后再重新检查端口监听情况，同时可以查看GitLab的nginx日志排查启动失败原因：

  sudo gitlab-ctl tail nginx
  

• 防火墙/安全组拦截了443端口
  无论是CentOS Runner服务器的出站规则，还是GitLab服务器的入站规则，都可能阻止了443端口的连接：

  1. 在Runner服务器上用curl测试GitLab API的可达性：

     curl -v https://%myGitlab%/api/v4/runners
     

     如果curl也返回connection refused，基本可以确定是网络层面的拦截。
  2. 检查GitLab服务器的防火墙（以firewalld为例）：

     sudo firewall-cmd --list-services
     

     如果没有https服务，添加并重启防火墙：

     sudo firewall-cmd --add-service=https --permanent
     sudo firewall-cmd --reload
     

  3. 如果你用的是云服务器，还要检查云服务商的安全组配置，确保443端口对Runner服务器的IP地址开放。

• GitLab的HTTPS配置异常
  如果GitLab的SSL证书配置错误（比如证书文件不存在、权限不正确、域名不匹配），会导致web服务无法绑定443端口。查看GitLab的nginx日志可以找到相关错误：

  sudo gitlab-ctl tail nginx
  

  常见的问题包括自签证书未配置、证书文件路径错误等，根据日志提示修复即可。如果是测试环境，也可以临时改用HTTP（修改GitLab配置后重启），或者在注册runner时添加--tls-skip-verify参数跳过证书验证（仅测试用）。

• SELinux限制了Runner的网络请求
  CentOS默认启用的SELinux可能会阻止GitLab Runner进程发起HTTPS连接。可以临时关闭SELinux测试：

  sudo setenforce 0
  

  然后重新执行注册命令，如果能成功，说明是SELinux的问题。你可以选择将SELinux设置为permissive模式（永久生效），或者添加专门的SELinux规则允许Runner的网络请求。

• 域名解析或IP访问限制
  如果你在注册命令中使用的是域名%myGitlab%，虽然ping能解析到IP，但可以尝试直接用IP替换域名测试：

  sudo /usr/local/bin/gitlab-runner register --non-interactive --url "https://%myGitlabIp%/" --registration-token "%myToken%" --executor "shell" --description "TestServerRunner" --tag-list "TestRunner, CIOnTest" --tls-skip-verify
  

  注意添加--tls-skip-verify，因为GitLab的证书通常是绑定域名的，用IP访问会触发证书验证失败。如果GitLab实例本身限制了IP访问（比如只允许特定域名访问），则需要调整GitLab的配置。

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