零阻塞多协议upstream需http与stream模块物理隔离、连接复用双控、阻塞源前置拦截及可观测性嵌入：http类走http模块，tcp/udp类走stream模块；keepalive与idle_timeout协同保连接复用；通过重试限制、主动健康检查、请求限流拦截阻塞源头；日志包含upstream_addr、response_time等字段精准定位卡点。
构建零阻塞的多协议高性能 upstream，核心不是堆参数，而是让 Nginx 的 HTTP 和 Stream 模块各司其职、连接复用不中断、协议感知不降级，并通过上游行为前置约束避免阻塞源头。
协议分层：HTTP 与 Stream 必须物理隔离
HTTP/1.1、HTTP/2、gRPC、WebSocket 属于应用层协议，依赖 HTTP 模块的 full-proxy 能力；而 TLS 直通、MySQL、Redis、自定义二进制协议必须走 Stream 模块。混用会导致：
- HTTP 块内 proxy_pass 到非 HTTP 后端（如 tcp://db:3306）会触发 502，且无法设置 keepalive
- Stream 块中强行解析 HTTP 头，等于自己重写协议栈，失去零阻塞前提
正确做法是：在 http 块中定义 http_upstreams（仅含 HTTP 类后端），在 stream 块中单独定义 stream_upstreams（仅含 TCP/UDP 类后端），两者配置完全独立、互不引用。
连接生命周期：keepalive + idle_timeout 双控保复用
零阻塞的前提是连接不频繁新建销毁。仅 upstream 内配 keepalive 不够，必须两端协同：
- upstream 块中设 keepalive 256（连接池大小），并禁用
proxy_http_version 1.0 - location 中显式开启 HTTP/1.1：proxy_http_version 1.1; 和 proxy_set_header Connection '';
- 后端服务自身需支持长连接，且响应头带
Connection: keep-alive - 关键补充：proxy_socket_keepalive on; 启用 TCP 层保活，防中间设备断连
若后端是 gRPC，还需加 grpc_set_header Host $host; 和 grpc_read_timeout 60s;，避免流式响应被误判超时。
阻塞源前置拦截：重试、健康检查、限流三道闸门
真正造成“阻塞感”的，往往不是单次请求慢，而是失败后盲目重试、健康探测滞后、突发流量无节制涌入：
-
重试必须关闭或极简：非幂等请求设
proxy_next_upstream_tries 1；GET 类最多tries 2，且限定proxy_next_upstream_timeout 8s -
健康检查必须主动+快速：用
health_check interval=3 fails=2 passes=2，配合max_fails=2 fail_timeout=15s，故障节点 15 秒内退出调度 -
限流不能只靠后端：在 proxy_pass 前的 location 中启用
limit_req zone=api burst=20 nodelay;，防止雪崩传导
可观测性嵌入：每个日志字段都指向阻塞点
零阻塞不是“没报错”，而是“出问题立刻定位到哪一跳卡住”。log_format 至少包含：
- $upstream_addr：实际转发目标（含端口），区分是负载不均还是某节点假死
- $upstream_response_time：毫秒级耗时，识别长尾节点
- $upstream_status：后端真实返回码，区分是 502（连接失败）、504（超时）还是 503（后端拒绝）
- $request_length 与 $bytes_sent：判断是否因大 Body 导致缓冲区阻塞
搭配 log_subrequest on; 可捕获内部子请求（如 auth_request 模块调用），避免隐式阻塞被忽略。
