nginx 安全代理 grpc 必须同时启用客户端侧 https+http/2 和上游侧 grpcs://tls 加密，缺一不可；需配置有效证书、ocsp stapling、会话复用、私钥权限管控，并严格验证上游 ca 证书。
要在 Nginx 中安全代理 gRPC 流量，必须同时满足两个条件：客户端到 Nginx 的 TLS 加密（即 HTTPS + HTTP/2 终端），以及 Nginx 到上游 gRPC 服务的 TLS 加密（即 grpcs://）。缺一不可，否则链路存在明文裸露风险，不满足等保、金融或 HIPAA 类合规要求。
启用 HTTPS + HTTP/2 监听（客户端侧加密）
gRPC 依赖 HTTP/2 多路复用特性，而 HTTP/2 在浏览器和多数客户端中强制要求 TLS。因此 Nginx 必须监听 443 端口并启用 HTTP/2：
- 确认编译时已启用
--with-http_ssl_module和--with-http_v2_module - 使用有效证书（非自签名，生产环境建议 Let’s Encrypt 或商业 CA）
- 配置示例：
server { listen 443 ssl http2; server_name api.example.com; <pre class="brush:php;toolbar:false;">ssl_certificate /etc/nginx/ssl/fullchain.pem; ssl_certificate_key /etc/nginx/ssl/privkey.pem; ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384; ssl_prefer_server_ciphers off;}
使用 grpcs:// 代理至上游（后端侧加密）
仅保护前端不足够。Nginx 必须以 TLS 客户端身份连接后端 gRPC 服务，并验证其证书真实性：
- 用
grpc_pass grpcs://upstream.example.com:443（注意是 grpcs，不是 grpc） - 显式启用上游 TLS 验证：
location / { grpc_pass grpcs://10.10.20.100:50051; <pre class="brush:php;toolbar:false;">proxy_ssl_verify on; proxy_ssl_trusted_certificate /etc/nginx/ssl/upstream-ca.crt; # 上游服务的 CA 根证书 proxy_ssl_protocols TLSv1.2 TLSv1.3; proxy_ssl_ciphers HIGH:!aNULL:!MD5;}
- 若上游使用私有 CA 或自签名证书，必须将对应根证书放入
proxy_ssl_trusted_certificate指定路径，并确保权限为 644
补充关键加固项（合规落地必需）
以下配置不是可选项，而是监管检查常见项：
-
OCSP Stapling：降低吊销验证延迟，避免隐私泄露
ssl_stapling on;<br>ssl_stapling_verify on;<br>resolver 8.8.8.8 1.1.1.1 valid=300s;<br>resolver_timeout 5s;
-
会话复用与前向安全：
ssl_session_tickets on;<br>ssl_session_timeout 1d;<br>ssl_ecdh_curve X25519:secp384r1;
-
私钥权限管控：证书私钥文件权限必须为
600，目录需 SELinux/AppArmor 放行读取
特别注意 gRPC 特有细节
gRPC 对协议栈更敏感，容易因配置疏漏失败：
- 避免在同一个
listen指令中混用http2和非 HTTP/2 协议；HTTP/2 明文（h2c）仅限开发测试，且需额外 header 支持，生产一律用 HTTPS - 如遇
upstream sent too large http2 frame，优先检查是否误用grpc://代理了本应加密的上游（应改用grpcs://） - DNS 解析 IPv6 失败导致连接超时？在 server 块加
resolver 8.8.8.8 ipv6=off;
