遭受DDoS攻击后GCP ALB持续返回502，Internet NEG失效问题咨询

场景回顾 #

基础设施链路：Cloudflare -> GCP ALB -> Internet NEG -> 外部PaaS
DDoS攻击期间Cloudflare触发503并切断后端访问；攻击结束后ALB持续返回如下502错误，仅能通过手动移除并重新添加Internet NEG端点恢复：

Error: Server Error

The server encountered a temporary error and could not complete your request.

Please try again in 30 seconds.

可能的核心原因 #

• NEG健康检查状态僵死
  GCP Internet NEG依赖健康检查判定端点可用性。DDoS攻击期间，外部PaaS因流量过载返回错误/超时，导致NEG的健康检查连续失败，端点被标记为不健康。攻击结束后，NEG的健康检查机制可能因攻击期间的异常状态出现“缓存固化”——比如探测请求被残留连接阻塞、内部状态未自动刷新，无法检测到PaaS已恢复，持续将流量导向标记为不健康的端点，引发ALB返回502。

• ALB-NEG连接池残留无效连接
  攻击期间ALB与NEG之间建立了大量半开、超时未释放的异常连接。攻击结束后，这些残留连接未被自动清理，ALB尝试复用无效连接访问PaaS时失败，触发502。手动重置NEG端点相当于强制清空关联的连接池，重建有效链路，因此恢复正常。

• NEG路由缓存异常
  Internet NEG会缓存端点路由信息，攻击期间流量冲击可能导致缓存条目失效（比如端点IP的路由映射错误）。攻击结束后，NEG未自动触发缓存刷新，仍使用错误路由转发流量，请求无法到达PaaS引发502。重新添加端点会强制NEG重新获取并更新路由缓存，恢复正确转发路径。

• 外部PaaS的源IP封禁未自动解除
  攻击期间外部PaaS可能将ALB的出站IP判定为攻击源并临时封禁。攻击结束后，PaaS的封禁规则未自动过期，NEG仍使用原IP池转发流量，请求被拒绝导致ALB返回502。手动重置端点可能触发ALB切换出站IP（若使用动态IP池），或触发PaaS重新识别源IP解除封禁。

验证与修复建议 #

• 查看GCP控制台中NEG端点的健康状态历史，确认攻击后是否持续显示不健康，同时检查健康检查日志，确认探测请求是否正常到达PaaS。
• 监控ALB的backend_connection_errors等metrics，确认是否存在大量连接超时/重置情况。
• 调整NEG健康检查配置：缩短探测间隔、降低失败阈值，确保攻击后快速检测到端点恢复。
• 通过GCP API（如compute.networkEndpointGroups.update）编写自动化脚本，在攻击结束后自动触发NEG端点重置，替代手动操作。

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