QA环境GitLab Runner执行流水线时断开连接问题求助

问题概述 #

QA环境中GitLab Runner在流水线执行时出现离线，核心错误如下：

ERROR: Appending trace to coordinator... error couldn't execute PATCH against [GitLab Server API URL]: read tcp [Runner's IP]->[GitLab Server's IP]: wsarecv: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.

环境信息：

• GitLab Runner部署于Windows服务器
• GitLab实例托管在AWS

已完成的排查动作：

• 确认Runner与GitLab服务器网络连通（ping、PowerShell的Test-NetConnection测试通过）
• 已开放双方防火墙80/443端口
• 已重启GitLab Runner服务及虚拟机
• 已检查系统和Runner日志
• Dev环境Runner运行正常，仅网络差异：Dev处于域网络，QA无域网络

新增排查思路与解决方案 #

1. 非域Windows环境的网络适配优化 #

• 检查并配置代理：非域环境可能缺失自动代理配置，导致API请求路由异常。
  • 在Runner安装目录的config.toml中添加代理规则：

    [[runners]]
      environment = ["HTTP_PROXY=http://your-proxy:port", "HTTPS_PROXY=http://your-proxy:port", "NO_PROXY=gitlab-server-ip,gitlab-server-domain"]
    

  • 或在Windows系统环境变量中设置HTTP_PROXY/HTTPS_PROXY，重启Runner服务生效。
• 重置WinHTTP代理：执行以下命令检查并重置系统级代理：

  netsh winhttp show proxy
  netsh winhttp reset proxy
  

2. AWS端网络限制排查 #

• 安全组与NACL规则验证：确认GitLab实例所在安全组允许对QA Runner IP的443端口出站流量，同时检查NACL的双向规则是否放行该IP的数据包。
• WAF拦截检查：若GitLab实例启用了AWS WAF，查看WAF日志是否存在拦截Runner PATCH请求的记录，将Runner IP加入白名单。
• 负载均衡超时调整：如果GitLab实例使用了负载均衡，检查HTTP超时设置是否过短（默认可能不足以支撑大trace的PATCH请求），建议调整为300秒以上。

3. GitLab Runner配置优化 #

• 延长trace发送超时：在config.toml中添加超时配置：

  [[runners]]
    [runners.trace]
      timeout = 300
      idle_timeout = 300
  

• 重新注册Runner：删除旧Runner配置，用新token重新注册，避免旧配置的认证或路由残留问题：

  gitlab-runner unregister --name qa-runner
  gitlab-runner register --url https://your-gitlab-url/ --registration-token your-token --executor shell --description "QA Windows Runner"
  

• 切换执行器（可选）：若当前使用shell执行器，尝试切换为docker executor（Windows需支持Docker），排查shell环境的网络隔离问题。

4. 深层网络测试 #

• 模拟PATCH请求：在QA Runner服务器上用curl直接测试GitLab API的PATCH请求，定位具体错误：

  curl -X PATCH -H "Authorization: Bearer your-runner-token" "https://gitlab-server-api-url/v4/jobs/your-job-id/trace" -d "content=test-trace"
  

  需替换实际的Runner token、GitLab API URL和测试用job ID，根据返回结果判断是认证、网络还是服务器端问题。
• TCP连接状态检查：执行以下命令查看连接状态，排查是否存在大量异常连接：

  netstat -ano | findstr gitlab-server-ip
  

  若存在大量TIME_WAIT或CLOSE_WAIT状态的连接，可调整Windows的TCP参数（如TcpTimedWaitDelay）优化连接回收。

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