nginx 支撑 grpc 需配置 upstream keepalive（如 512）、keepalive_timeout（如 75s）、客户端 keepalive_timeout 对齐、禁用缓冲（grpc_buffering off）、流级超时（grpc_read/send_timeout）、http/2 全链路闭环（listen http2 + grpc:// 或 grpcs://）。
要让 Nginx 稳定支撑 gRPC 的长连接与流式传输，keepalive 不是“锦上添花”，而是多路复用能成立的底层前提。它决定 Nginx worker 是否能复用与后端的 HTTP/2 连接，从而避免每个 stream 都新建 TCP 连接——否则性能直接归零，出现大量 Stream removed before completed 或 502 Bad Gateway。
upstream 中的 keepalive：必须配，且数值要合理
这是最常被漏掉、也最关键的配置项：
-
必须显式写在 upstream 块末尾，例如：
keepalive 512;（不建议低于 256，生产环境推荐 512～2000） - 该值表示每个 Nginx worker 进程对每台后端服务器最多缓存的空闲 HTTP/2 连接数，不是总连接上限
- 数值过小（如 4 或 16）→ 高并发下频繁建连、TIME_WAIT 暴涨、连接复用率趋近于 0
- 数值过大需同步检查系统级限制：
ulimit -n是否足够，否则连接池无法真正建立 - 必须搭配
keepalive_timeout 75s;（写在同一 upstream 块内），否则默认沿用 proxy 超时（常为 60s），导致空闲但活跃的流被误断
客户端侧 keepalive_timeout：要与 upstream 对齐
Nginx 和后端之间的连接池再大，若客户端一端连接被提前关闭，整个链路就断了：
- 在
server或http块中设置：keepalive_timeout 75s; - 第二个参数可选，用于响应头：
keepalive_timeout 75s 75s;，向客户端明示建议保持时间 - 这个值必须 ≥ upstream 的 keepalive_timeout，理想情况完全一致（如都设为 75s）
- 若客户端（如 gRPC-Go）设置了更短的 idle timeout，应以客户端为准，并相应调低 Nginx 端值，避免“单方面维持”引发 RST
禁用缓冲 + 流级超时：防止帧级中断
HTTP/1.x 的缓冲逻辑会破坏 gRPC 的二进制 DATA 帧连续性：
- 强制关闭缓冲：
grpc_buffering off;（必须放在 location 块中） - 超时必须按“流生命周期”设置，而非传统请求：
grpc_read_timeout 3600;和grpc_send_timeout 3600; - 注意：
proxy_read_timeout和proxy_send_timeout对grpc_pass完全无效，写了也不起作用 -
reset_timedout_connection off;可防止超时后主动发送 RST，中断仍在传输的流
协议栈对齐：http2 + h2c/grpcs 必须闭环
keepalive 生效的前提是整条链路走真正的 HTTP/2：
- 前端监听必须带
http2：listen 443 ssl http2;（顺序不能错） - 后端通信协议由
grpc_pass的 URL 前缀决定：grpc://表示明文 H2C，grpcs://表示 TLS；不能混用或误写为http:// - 后端服务必须原生支持对应协议：Go 默认支持 h2c，Java/Python 需显式启用；若用
grpcs://，还需配grpc_ssl_certificate等证书指令 - 禁止将 HTTP/1.1 服务混入同一 upstream——协议不匹配会导致部分 stream 静默失败，排查极难
