nginx多层级负载均衡通过l1入口网关、l2业务路由层、l3服务接入层三级串联实现，各层职责分明：l1负责ssl终结与安全分流，l2按路径/请求头精细化路由，l3对接真实服务并执行健康检查与协议支持，需保障协议透传、超时递增、全链路追踪等协同机制。
在 Nginx 中实现多层级负载均衡转发，本质是将多个 Nginx 实例串联部署，每一层承担不同职责：最外层（L1）做全局流量分发与安全控制，中间层（L2）按业务域或地域做二次路由，内层（L3）对接真实服务节点并做最终负载均衡。关键不在“多层”本身，而在各层的定位清晰、协议透传一致、健康检查可靠。
第一层：入口网关（L1）——统一接入与基础分流
L1 通常部署在公网入口，负责 SSL 终结、限流、WAF 规则、IP 黑白名单及初步路径/域名路由。它不直接代理到后端应用，而是将请求转发给第二层的多个逻辑集群（如 api-cluster、web-cluster、file-cluster）。
- 使用 upstream 定义 L2 集群地址，建议用 DNS SRV 或 Consul 服务发现，避免硬编码 IP
- 开启 proxy_next_upstream 并配置失败重试策略（如 error、timeout、invalid_header），提升链路容错性
- 务必设置 proxy_set_header Host $host 和 X-Real-IP / X-Forwarded-For，确保下游能获取原始请求信息
第二层：业务路由层（L2）——按域/标签精细化分发
L2 接收来自 L1 的已剥离 SSL 的 HTTP 流量，依据 path 前缀、请求头（如 x-service-name）、或 cookie 值，将请求导向对应业务子集群（例如 /api/v1 → user-svc；/admin/ → ops-svc）。这一层可复用 Nginx 的 map 指令做动态 upstream 选择。
- 用 map 指令提取路由键（如 $http_x_service），映射为 upstream 名称，再结合 proxy_pass http://$upstream_name
- 每个业务子集群定义独立 upstream，启用 least_conn 或 hash $remote_addr consistent 等策略
- 开启 keepalive 32 并配合 proxy_http_version 1.1，减少 L2 到 L3 的连接开销
第三层：服务接入层（L3）——实例级负载与健康检查
L3 直接对接真实服务 Pod 或 VM 实例，是最贴近应用的一层。重点在于细粒度健康检查、平滑上线/下线、以及支持 gRPC/HTTP2 等协议升级。
- 使用 health_check 指令（Nginx Plus）或开源版搭配 nginx_upstream_check_module 插件，检查 /healthz 端点
- 配置 max_fails=2 fail_timeout=30s，避免单点抖动引发误摘除
- 若后端为 gRPC，需启用 http2 协议，并确保 proxy_http_version 2.0 和 proxy_set_header Connection ''
跨层协同要点：一致性与可观测性
多层结构容易因 header 丢失、超时设置冲突或日志割裂导致排障困难。必须统一关键行为：
- 所有层级启用 log_format 包含 $request_id（由 L1 注入），便于全链路追踪
- 各级 proxy_read_timeout / proxy_connect_timeout 应逐层递增（如 L1=60s、L2=45s、L3=30s），防止上游等待过久
- 禁用 proxy_buffering off 在非必要场景，避免小包堆积和内存泄漏
