Nginx多级四层负载均衡需分层设计：L1接入层负责TLS终结与快速失败，L2路由层专注调度并禁用DNS；逐级收紧超时、启用主动健康检查与细粒度日志监控。
要在 Nginx 中构建稳定、可扩展的多级四层负载均衡链路，关键不是简单堆叠多个 stream 块，而是通过分层职责划分、连接生命周期控制与主动健康反馈，让每一级只承担明确角色。实际部署中，常见问题如连接堆积、故障传递、超时雪崩，都源于各级之间缺乏协同策略。
明确各级角色与协议边界
多级链路不是“Nginx→Nginx→后端”，而是按功能解耦：
-
接入层（L1）：面向公网或跨网段客户端，负责 TLS 终结（若用 TCP+SSL）、源 IP 透传（
proxy_protocol on;）、快速失败判定（短 connect timeout + 高 max_fails） -
路由层（L2）：位于内网，专注协议无关的流量调度，禁用 DNS 解析（避免 resolver 延迟），使用静态 IP 列表，启用
least_conn或hash $remote_addr consistent保证会话局部稳定性 - 不建议在 L2 后再接 L3：每增加一级 stream 代理，至少引入 2–3ms 固定延迟和额外连接状态开销；三层以上链路应改用单层 stream + 多 upstream 分组 + 动态 resolve（配合 Consul 或 Nacos）实现逻辑分级
连接管理必须逐级收紧
默认超时值在多级场景下极易引发级联 hang 住。需按层级倒金字塔配置：
- L1 的
proxy_connect_timeout设为 500ms，proxy_timeout不超过 30s（防止客户端慢读拖垮整条链） - L2 的
proxy_connect_timeout降至 200ms，proxy_timeout控制在 10s 内，强制后端快速响应或断连 - 所有 server 块必须显式配置
proxy_next_upstream error timeout;，但禁用proxy_next_upstream_tries（多级重试会放大故障面） - 在 L1 的 upstream 中启用
max_fails=2 fail_timeout=15s，L2 则设为max_fails=1 fail_timeout=5s，加速故障隔离
启用主动健康检查与状态同步
stream 模块原生不支持 HTTP 健康检查，但可通过外部机制补足：
- 对 L2 的每个 upstream server，部署轻量 TCP 探活脚本（如
nc -z -w1 ip port），结果写入本地文件，再由 Nginx 的health_check（需商业版）或 OpenResty 的 lua-resty-healthcheck 模块读取并动态更新 upstream 状态 - L1 与 L2 之间通过共享内存区（
shared memory zone）或 Redis 发布/订阅，同步后端节点的权重变更事件（例如某 MySQL 实例 CPU >90%，自动降权至 0.1） - 所有 server 块开启
proxy_buffering off;和tcp_nodelay on;，避免 Nagle 算法引入毫秒级抖动
日志与可观测性不可省略
没有细粒度日志，多级链路等于黑盒：
- 在 stream 块顶部定义专用日志格式：
log_format stream_log '$remote_addr:$remote_port → $upstream_addr [$time_local] $protocol $status $bytes_sent $bytes_received $session_time'; - L1 和 L2 分别写入不同 access_log 文件，并用
flush=1s参数确保日志实时落盘 - 配合 Prometheus + nginx-lua-prometheus，在每个 server 块中注入指标采集逻辑，重点关注
stream_upstream_server_active_connections和stream_upstream_server_response_time
