核心是复用连接而非多路复用本身，需配置grpc_pass、keepalive、禁用缓冲、精简头部及协同超时与系统参数。
在 Nginx 中通过反向代理提升后端 RPC 调用吞吐量，核心不是“多路复用”本身（HTTP/2 的 multiplexing 对传统 RPC 协议如 gRPC-HTTP/2 有效），而是让 Nginx 稳定、低开销地复用连接到后端，并减少握手、缓冲阻塞和上下文切换。关键在于适配 RPC 的长连接、流式响应与低延迟敏感特性。
启用 HTTP/2 并透传 gRPC 流量
若后端是 gRPC（基于 HTTP/2），Nginx 必须作为 HTTP/2 终结点或直通代理：
- 监听端口开启 http2：
listen 443 ssl http2;，并配置有效 TLS 证书（gRPC 强制要求加密） - location 块中必须设
grpc_pass grpc://backend_upstream;（非proxy_pass），启用原生 gRPC 代理支持 - 禁用缓冲：
proxy_buffering off;，避免 gRPC 流式消息被截断或延迟；同时关闭gzip和sub_filter等干扰二进制流的模块 - 确保
upstream使用server ... grpc://...地址，且后端服务监听 HTTP/2 清单（如h2协议）
连接池复用：keepalive 是吞吐基础
RPC 调用频繁、生命周期短，但建连成本高。Nginx 必须复用到后端的连接，而非每次新建：
- upstream 块中配置：
keepalive 64;（数值建议为后端最大连接池数的 60%～80%，如 Spring Cloud Gateway 默认 1024，则设 512） - 对应 location 中强制使用 HTTP/1.1 长连接：
proxy_http_version 1.1;+proxy_set_header Connection ''; - 后端需返回
Connection: keep-alive且自身 keepalive timeout > Nginx 的proxy_read_timeout（建议设为 90s） - 验证方式：
ss -tnp | grep :<backend_port></backend_port>观察 ESTABLISHED 连接数是否稳定在 30–60+，而非秒级波动
精简头部与超时协同
RPC 请求头通常精简，冗余字段会增加序列化/反序列化负担和传输延迟：
- 只透传必要头：
proxy_set_header Host $host;、X-Real-IP、X-Forwarded-For、X-Forwarded-Proto；移除User-Agent、Accept-Encoding等无关项 - 超时按 RPC 特征设：
proxy_connect_timeout 3s;（建连快）、proxy_send_timeout 15s;（发请求快）、proxy_read_timeout 90s;（容许慢查询或流式响应） - 禁用 access_log 或启用缓冲日志：
access_log /var/log/nginx/rpc.log main buffer=128k flush=3s;，避免 I/O 拖慢事件循环
系统与 worker 层面对齐
高并发 RPC 场景下，Nginx worker 和内核参数必须支撑万级活跃连接：
-
worker_processes auto;+worker_connections 16384;，并同步调大系统限制：ulimit -n 65536、worker_rlimit_nofile 65536; - 启用高效事件模型：
use epoll;+multi_accept on; - 内核调优（/etc/sysctl.conf）：
net.core.somaxconn = 65535、net.ipv4.tcp_max_syn_backlog = 65535、net.ipv4.ip_local_port_range = 1024 65535 - 禁用
tcp_tw_recycle（已废弃），启用tcp_tw_reuse = 1加速 TIME_WAIT 回收
