3、入口层故障排查（二）：反向代理与负载均衡——Nginx/Ingress Gateway 502/504错误、上游健康检查失败、会话保持失效

入口层是IDP自助门户流量的第一道关卡，Nginx与Ingress Gateway作为反向代理和负载均衡器，承担着TLS终止、路由分发、流量治理等核心职责。当用户访问出现502/504错误、上游服务间歇性不可用或会话丢失时，故障根因往往隐藏在代理配置、健康检查机制或会话保持策略中。本节从架构视角拆解三类高频故障的诊断路径与修复方案。

3.1 502/504错误：上游服务不可达或超时

502 Bad Gateway表示代理服务器从上游收到无效响应；504 Gateway Timeout表示上游在规定时间内未响应。两者均指向代理与上游之间的通信链路或服务处理能力问题。

3.1.1 故障根因矩阵

3.1.2 Nginx关键超时配置

# 与上游建立连接的超时时间（默认60s）
proxy_connect_timeout 5s;

# 从上游读取响应的超时时间（默认60s）
proxy_read_timeout 30s;

# 向上游发送请求的超时时间（默认60s）
proxy_send_timeout 30s;

# 缓冲设置——避免上游慢响应耗尽代理资源
proxy_buffer_size 4k;
proxy_buffers 8 4k;
proxy_busy_buffers_size 8k;

3.1.3 Ingress Gateway场景的特殊排查

在Kubernetes环境中，Ingress Gateway（如nginx-ingress、istio-ingressgateway）的502/504可能源于Service与Pod之间的端点不一致。典型场景：

• 端点缓存延迟：Pod滚动更新后，旧Pod已终止但EndpointSlice尚未更新，Gateway仍将流量转发至已关闭的Pod。
• iptables/ipvs规则残留：kube-proxy清理规则滞后，导致连接被发往不存在的Pod。
• Ingress资源冲突：多个Ingress规则匹配同一Host+Path组合，导致路由到错误的后端Service。

# 快速验证Ingress后端端点是否正常
kubectl get endpoints <service-name> -n <namespace>
kubectl get pod -l app=<app-label> -o wide

# 查看Ingress Gateway访问日志中的upstream字段
kubectl logs -n ingress-nginx -l app.kubernetes.io/component=controller --tail=100 | grep "502"

3.2 上游健康检查失败：流量黑洞与级联故障

健康检查是负载均衡器感知上游可用性的核心机制。当健康检查配置不当或上游状态波动时，会导致流量被路由到不健康的节点，或所有上游被标记为down引发服务完全不可用。

3.2.1 健康检查类型对比

3.2.2 Nginx upstream健康检查配置（商业版/OpenResty）

upstream backend {
    zone upstream_backend 64k;

    server 10.0.1.1:8080;
    server 10.0.1.2:8080;

    # 健康检查配置
    health_check interval=5s fails=3 passes=2 uri=/health;
    health_check_timeout 2s;

    # 慢启动——避免刚恢复的节点被流量冲垮
    server 10.0.1.3:8080 slow_start=30s;
}

3.2.3 健康检查失败的自愈策略

1. 主动摘除+慢启动：健康检查失败后立即将节点标记为down，恢复后通过slow_start逐步放量。
2. 半连接池保护：当上游健康节点数低于阈值时，触发熔断并返回固定错误页，避免请求堆积。
3. 级联健康检查：在Istio/Envoy场景中，启用主动健康检查（outlier detection）与被动健康检查（错误率阈值）双重机制。

3.3 会话保持失效：粘性会话丢失与状态漂移

IDP自助门户通常需要会话保持（Session Stickiness）来保证用户请求始终路由到同一后端实例，避免登录状态、临时数据丢失。会话保持失效会导致用户频繁登出、表单提交失败、验证码校验不通过等体验问题。

3.3.1 会话保持实现方式对比

3.3.2 Nginx sticky模块配置示例

upstream backend {
    # 使用Nginx sticky模块（nginx-sticky-module-ng）
    sticky name=route expires=1h domain=.idp.example.com path=/;

    server 10.0.1.1:8080;
    server 10.0.1.2:8080;
    server 10.0.1.3:8080;
}

# 或使用第三方cookie插入方式
upstream backend {
    server 10.0.1.1:8080;
    server 10.0.1.2:8080;

    # 通过map指令实现自定义会话保持
    map $cookie_session_id $backend {
        default 10.0.1.1:8080;
        ~^(?<id>\d+)$ 10.0.1.1:8080;
    }
}

3.3.3 会话保持失效的排查清单

1. 检查Cookie是否被正确设置和传递：使用浏览器开发者工具查看Set-Cookie响应头及后续请求中的Cookie值。
2. 验证上游节点扩容/缩容后的路由变化：一致性哈希在节点变更时只会影响少量会话，而ip_hash在节点数变化时可能重新分配所有会话。
3. 确认代理层是否启用了缓存：如果Nginx开启了proxy_cache，缓存命中时可能跳过会话保持逻辑，导致请求被发往非预期节点。
4. 检查跨域场景下的Cookie SameSite属性：IDP门户可能涉及多个子域名，SameSite=Lax/Strict会阻止跨站Cookie发送。

3.4 综合排查流程：从现象到根因

当入口层出现502/504、健康检查波动或会话保持问题时，建议按以下流程快速收敛：

1. 确认故障范围：是单用户还是全量用户？单路径还是所有路径？是否与最近变更（发布、配置修改、扩缩容）相关？
2. 检查代理层日志：Nginx error.log中的upstream timed out、no live upstreams、connection refused等关键词；Ingress Gateway access.log中的upstream_status字段。
3. 验证上游健康状态：直接curl/telnet上游端口，检查上游/metrics或/health端点，确认Pod/容器是否存活。
4. 分析超时与重试配置：确认proxy_next_upstream、retry_on、max_retries等参数是否合理，避免重试放大故障。
5. 检查会话保持一致性：对比多个请求的upstream_addr是否一致，检查Cookie或哈希key是否变化。
6. 观察监控指标：上游连接数、请求延迟P99、健康检查成功率、会话漂移率。

3.5 架构层面的防御性设计

从SRE视角看，入口层的故障不应仅靠事后排查，更需在架构设计阶段植入防御机制：

• 超时分层：代理层超时 < 上游超时 < 客户端超时，避免代理层成为瓶颈。
• 熔断与降级：当上游健康节点数低于50%时，自动返回降级页面而非等待超时。
• 会话外部化：使用Redis/KeyDB存储会话状态，代理层仅做路由，不依赖粘性会话。
• 灰度发布与流量镜像：新版本上线前先镜像流量到灰度环境，验证健康检查与会话保持行为。
• 全局超时治理：建立超时配置的版本化管理，每次变更经过评审和压测验证。