GCP内部负载均衡请求无限等待问题排查求助

开发者阿泽

2026-7-24

问题排查与解决方案

问题回顾

在GCP环境中使用内部负载均衡器（ILB）为内存敏感型VM路由流量，测试阶段仅启用1台VM。托管在Cloud Run的客户端通过axios发送POST请求至ILB，设置了100秒超时，但请求会无限等待直至应用崩溃；直接调用后端VM则正常。补充信息：

ILB日志显示已在4.106秒内向Cloud Run返回响应，但axios未接收
ILB配置：Instance Group后端、HTTP协议、200秒超时，无Rate Limit；后端均衡模式为utilization，最大RPS设为2
服务器宕机时能正常收到错误响应

根因分析

axios超时配置异常：原代码中catch块未正确捕获错误变量，且单一timeout配置在Serverless环境（Cloud Run）中可能存在生效问题，无法触发超时中断。
Cloud Run网络层的响应传递问题：若使用VPC连接器访问ILB，可能存在网络策略或防火墙规则拦截了ILB返回的响应，导致Cloud Run未将响应转发给axios客户端。
ILB后端RPS限制的隐性影响：后端最大RPS设为2，当请求频率接近或达到阈值时，ILB可能对请求进行排队，即使日志显示已返回响应，也可能存在连接状态异常导致axios无法识别。
响应格式不规范：ILB返回的响应可能缺少必要的HTTP头部（如Content-Length），导致axios无法判断响应是否完成，持续等待。

解决方案

1. 修复axios超时与错误捕获

调整axios配置，拆分连接超时与响应超时，并确保正确捕获错误：

try {
   let response = await axios.post(LoadBalancerURL, data, {
     connectTimeout: 10000, // 连接超时10秒
     responseTimeout: 90000, // 响应超时90秒，总时长控制在100秒内
   });
   // 处理响应
   return;
} catch (err) {
   console.error("请求错误详情:", err.message, err.code);
}

拆分超时能更精准控制不同阶段的等待时间，避免单一配置在Serverless环境中失效。
打印错误详情可快速定位是超时、连接失败还是响应解析问题。

2. 排查Cloud Run与ILB的网络连通性

在Cloud Run服务中添加请求生命周期日志，记录请求发送时间、超时触发时间、是否收到响应的标识，确认响应是否真的到达Cloud Run环境。
检查VPC连接器的网络权限：确保连接器所属的VPC网络与ILB的后端网络互通，防火墙规则允许ILB的IP段向Cloud Run的VPC连接器返回流量。

3. 调整ILB后端配置

临时将后端的Maximum RPS调高至10，排除RPS限制导致的请求排队或连接异常，测试是否还会出现无限等待的情况。
将ILB的超时时间调整为90秒（短于客户端的100秒超时），避免ILB还在等待后端时，客户端已经触发超时，但这里日志显示ILB已返回响应，主要是验证是否存在超时时间不匹配的隐性问题。

4. 验证响应格式合规性

在Cloud Run的运行环境中执行curl请求ILB，查看响应头部：

curl -v [LoadBalancerURL] -X POST -d [data]

检查是否存在Content-Length或Transfer-Encoding: chunked头部，若缺少这些头部，axios无法判断响应是否结束，会持续等待。若存在异常，需检查后端VM的响应输出是否规范，或在ILB中配置响应头部修正规则。

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