请求排查：Google Cloud HTTP/HTTPS负载均衡器连接刷新致应用会话中断

这种无规律的连接断开导致用户会话丢失的问题确实挺闹心的，我结合GCP负载均衡和Ubuntu环境的经验，给你梳理几个核心排查方向：

• 检查空闲连接超时设置：GCP HTTP(S)负载均衡默认的空闲超时是5分钟，但如果有人手动修改过这个值（比如改成了几秒），就会导致连接频繁断开。你可以登录GCP控制台，找到对应的负载均衡器，进入后端服务详情页，查看“连接超时”和“会话亲和性”的配置——如果会话亲和性没开或者超时设置异常，很可能是问题根源。
• 核对健康检查参数：如果健康检查的间隔过短、超时时间设置得太苛刻，当虚拟机偶尔出现响应延迟时，LB会把实例从后端池踢出去，直接断开现有连接。看看健康检查的“检查间隔”、“不健康阈值”这些参数，是不是设置得太敏感了。

• 查看TCP keepalive内核参数：Ubuntu默认的TCP keepalive时间是2小时，要是LB的空闲超时比这个短，而且你的应用没主动发心跳，LB就会主动断连。你可以用sudo sysctl -a | grep tcp_keepalive命令查看当前的tcp_keepalive_time、tcp_keepalive_intvl、tcp_keepalive_probes值，必要时调整这些参数，让系统主动发心跳维持连接。
• 排查防火墙规则：虚拟机上的ufw或者iptables有没有设置连接跟踪超时？有些防火墙会自动断开长时间空闲的连接，你可以查看/var/log/ufw.log日志，或者用sudo iptables -t nat -L看看有没有相关规则。

• 确认会话存储方式：如果你的应用用的是本地内存会话，当LB把请求转发到另一台虚拟机时，用户的会话就找不到了，看起来像是连接断开导致的退出。建议把会话改成分布式存储，比如用Redis或者GCP的Cloud Memorystore，让所有后端实例共享会话数据。
• 检查HTTP keep-alive头：如果应用返回的响应头里没有Connection: keep-alive，LB不会维持长连接，每次请求后都会断开。你可以用curl -v https://你的应用域名查看响应头，确认这个字段是否存在。
• 查看应用日志：看看应用自身的日志（比如业务日志、Web服务器日志），有没有主动销毁会话或者关闭连接的记录——有些应用会在用户无操作一段时间后主动清掉会话，这也会导致用户退出。

• 开启并查看VPC流日志：如果你的GCP VPC开启了流日志，可以搜索有没有RST包的记录，定位是LB到虚拟机之间的连接被重置，还是外部到LB的连接出问题。
• 检查前端是否有CDN/代理：如果你的应用前面还加了CDN（比如Cloudflare），CDN的空闲超时设置也可能导致连接断开，得同步检查CDN的相关配置。

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