工程上不存在完全零阻塞的多协议反向代理，实际目标是极低延迟、无连接级阻塞、全链路异步处理；需按协议特征划分处理平面、禁用缓冲、非对称超时、协议感知路由及细粒度可观测性。
完全零阻塞的多协议反向代理在工程上并不存在——“零阻塞”是理想化表述，实际目标应是**极低延迟、无连接级阻塞、全链路异步处理**。关键不在于消灭所有等待，而在于让阻塞不传导、不堆积、不放大，尤其在 HTTP/1.1、HTTP/2、WebSocket、gRPC 等多协议共存场景下。
协议层必须解耦，不能共享同一事件循环瓶颈
混合协议代理若用单一线程或单一 Reactor 模型统一调度，HTTP/1.1 的长轮询、WebSocket 的长连接、gRPC 的流式响应会相互干扰。正确做法是按协议特征划分处理平面：
- HTTP/1.1 和静态资源走轻量级连接复用路径，启用
keepalive_timeout与连接池管理 - HTTP/2 和 gRPC 必须绑定独立的 TLS/ALPN 分流通道，禁用头部阻塞（如启用
http2_max_field_size和http2_max_header_size限流） - WebSocket 需独占 upgrade 处理分支，跳过常规 body 解析，直接透传帧（frame-level passthrough）
- 所有协议入口统一由 SO_REUSEPORT 绑定多个 worker 进程，避免 accept 队列争抢
后端转发必须无状态 + 异步非阻塞 I/O
代理本身不缓存请求体、不拼接响应体，所有读写操作都基于内核零拷贝接口（如 Linux 的 splice() 或 io_uring）。典型配置中要规避以下陷阱：
- 禁用
proxy_buffering on—— 启用即引入内存缓冲与阻塞等待 - 设
proxy_http_version 1.1并强制Connection: keep-alive，避免 HTTP/1.0 的频繁建连开销 - 对 gRPC 后端，必须开启
grpc_set_header补全TE: trailers，否则流式响应会被 nginx 缓存截断 - 超时全部设为非对称：connect 超时 ≤ 3s，read/write 超时 ≤ 15s，且启用
proxy_next_upstream error timeout http_502自动故障转移
动态路由与协议感知需下沉到 L4/L7 边界
多协议意味着请求特征差异极大：HTTP 有 Host 和 Path，gRPC 有 :path 和服务名，WebSocket 依赖 Upgrade: websocket。硬编码 location 匹配会失效。可行方案包括：
- 用 OpenResty + Lua 在
ssl_certificate_by_lua_block中解析 SNI，再结合set_by_lua_block提前提取 ALPN 协议名（h2 / http/1.1 / h2c） - 对 gRPC 请求，用
lua-resty-grpc-header解析二进制 header，提取/package.Service/Method实现服务级路由 - WebSocket 升级请求通过
map $http_upgrade $connection_upgrade提取，并单独命中location /ws/分支做透传 - 所有路由决策必须在 read phase 完成，禁止在 content phase 中发起外部调用（如 Redis 查询），否则必然引入阻塞
可观测性不是附加项，而是阻塞定位的唯一依据
没有细粒度指标，就无法判断阻塞发生在哪一层。必须默认开启：
- 每连接级的
upstream_connect_time、upstream_header_time、upstream_response_time，单位毫秒，直采不聚合 - 按协议维度统计 active connection 数、write wait time、read wait time（OpenResty 可用
ngx.var.connections_active+ 自定义计时器） - 对每个 upstream group 打标协议类型（
grpc_backend、ws_cluster），避免日志混杂 - 接入 OpenTelemetry，将 request_id、protocol、upstream_name、error_code 打入 trace，快速定位跨协议调用断点
