排查nginx代理grpc的tls版本不一致，核心是确认“nginx连后端”方向：error.log中出现“while ssl handshaking to upstream”即为代理出向失败；再用openssl s_client实测后端真实支持的tls版本与套件，最后在upstream中明确配置proxy_ssl_protocols、proxy_ssl_ciphers、proxy_ssl_server_name on及proxy_ssl_session_reuse off。
排查 Nginx 代理后端 gRPC 服务时的 TLS 版本不一致问题，核心是厘清“谁连谁”——Nginx 此时既是 HTTPS 服务端（面向客户端），又是 HTTPS 客户端（面向后端 gRPC 服务）。TLS 版本不一致通常发生在后者环节，即 Nginx 用 https:// 去连一个不支持对应 TLS 版本的后端，导致握手失败、连接中断或 502 错误。
确认问题方向：看 error.log 中的关键提示
打开 /var/log/nginx/error.log，搜索含 SSL_do_handshake() failed 的行，并重点看紧邻的上下文：
- 出现
while SSL handshaking to upstream→ 问题在 Nginx 连后端 gRPC 服务时，属于代理出向握手失败 - 出现
while SSL handshaking, client: xxx.xxx.xxx.xxx→ 问题在浏览器/App 连 Nginx 时，与后端无关
只有前者才需检查 Nginx 与后端 gRPC 的 TLS 协商。
验证后端 gRPC 实际支持的 TLS 版本和套件
别依赖文档或配置猜测，直接用 OpenSSL 测试后端真实能力：
- 测 TLSv1.2 支持：
echo | openssl s_client -connect grpc-backend:443 -tls1_2 -servername your-grpc-domain 2>/dev/null | grep "Protocol\|Cipher" - 测 TLSv1.3 支持：
echo | openssl s_client -connect grpc-backend:443 -tls1_3 -servername your-grpc-domain 2>/dev/null | grep "Protocol\|Cipher" - 若返回空或报
no protocols available，说明后端根本未启用对应版本
注意：gRPC 后端（如 Go 的 grpc-go 或 Java 的 netty-tcnative）必须显式启用 TLSv1.3，且依赖底层 OpenSSL/BoringSSL 版本 ≥ 1.1.1。
检查并收紧 Nginx 代理侧的 TLS 客户端配置
Nginx 默认使用较宽松的 TLS 客户端策略，可能与后端不兼容。需在 upstream 或 location 块中明确控制：
- 限定协议版本：
proxy_ssl_protocols TLSv1.2 TLSv1.3;（避免尝试 TLSv1.0/1.1 导致拒绝） - 指定兼容套件：
proxy_ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;（优先选 AEAD 类型，避开老旧算法） - 开启 SNI（关键！）：
proxy_ssl_server_name on;（否则后端多域名虚拟主机可能选错证书/配置） - 禁用 SSL 会话复用（防缓存错配）：
proxy_ssl_session_reuse off;（尤其在后端证书频繁轮换时）
排除 gRPC 协议层干扰
gRPC over TLS 要求严格匹配 HTTP/2 + TLS，常见陷阱包括：
- 后端监听的是
h2c（明文 HTTP/2），但 Nginx 用了grpcs://或https://→ 应改用grpc://或确保后端启用了 TLS - Nginx 与后端之间混用了 HTTP/1.1 和 HTTP/2 连接池 → 确保
upstream中只配置一种协议，且后端真正支持 - 后端 gRPC 服务未正确绑定 ALPN 协议（如
h2），导致 TLS 握手成功但后续 HTTP/2 协商失败 → 需检查后端启动参数或框架配置
可临时用 curl -v --http2 -k https://grpc-backend:443 验证后端是否能响应 HTTP/2 健康检查。
