排查nginx https代理证书报错，核心是区分客户端→nginx（服务端）和nginx→后端（客户端）两个tls环节；绝大多数错误发生在后者，需通过error_log定位方向，针对性检查fullchain.pem、proxy_ssl_verify等四项指令及sni匹配。
排查客户端通过 Nginx 代理访问 HTTPS 网站时的证书报错，核心是分清两个 TLS 连接环节：一是客户端到 Nginx（服务端角色），二是 Nginx 到后端 HTTPS 服务（客户端角色）。绝大多数证书报错实际发生在第二个环节，但现象却体现在客户端（如浏览器红叉、502、NET::ERR_CERT_AUTHORITY_INVALID 等）。需逐层定位，不能只盯着 Nginx 自己的证书。
看日志明确错误发生方向
打开 Nginx 错误日志（error_log /var/log/nginx/error.log warn; 或更高级别），重点搜索以下关键词：
- 含 to upstream → 问题在 Nginx 主动连接后端 HTTPS 服务时失败（如 SSL_do_handshake() failed while SSL handshaking to upstream）
- 含 client: xxx.xxx.xxx.xxx 且无 upstream 字样 → 问题在客户端连 Nginx 时失败（如证书过期、链不全、域名不匹配）
- 出现 certificate verify failed、unable to get local issuer certificate → Nginx 校验后端证书失败，说明已启用
proxy_ssl_verify on - 出现 sslv3 alert handshake failure 或 wrong version number → 协议协商异常，常见于 SNI 缺失或后端实际不支持 HTTPS
检查客户端到 Nginx 的证书配置
这是浏览器直接看到的证书链。常见问题不是“没证书”，而是链不完整或不匹配：
- 确认
ssl_certificate指向的是 fullchain.pem（域名证书 + 中间证书），不是单独的cert.pem；Let’s Encrypt 默认提供该文件 - 用命令验证是否发送了完整链：
openssl s_client -connect your-domain.com:443 -showcerts 2>/dev/null | grep "subject\|issuer"
正常应显示至少两段：第一段是你的域名证书（Subject=CN=your-domain.com），第二段是中间证书（Issuer=Let's Encrypt R3） - 检查证书 SAN 是否覆盖访问域名（如访问
www.example.com，证书必须含该条目，*.example.com不匹配三级域名） - 确认私钥与证书匹配：
openssl x509 -noout -modulus -in fullchain.pem | openssl md5openssl rsa -noout -modulus -in your.key | openssl md5
两行输出必须完全一致
检查 Nginx 到后端 HTTPS 服务的验证配置
当报错指向 to upstream，说明 Nginx 作为客户端校验失败。必须显式配置四项指令（缺一不可）：
-
proxy_ssl_verify on;—— 必须在location或upstream块内启用，全局设置无效 -
proxy_ssl_trusted_certificate /etc/nginx/ssl/upstream-ca.crt;—— 指向仅含根证书和中间证书的 PEM 文件（如 Let’s Encrypt 的 ISRG Root X1 + R3），不能含私钥或终端证书 -
proxy_ssl_server_name on;—— 启用 SNI 扩展，否则后端可能返回默认证书 -
proxy_ssl_name "backend.example.com";—— 必须与后端证书的 SAN 完全一致（大小写、通配符、www 前缀都要核对）；若proxy_pass写的是 IP 或变量，此项不可省略
验证方式：在 Nginx 服务器上模拟其行为：openssl s_client -connect backend-ip:443 -servername backend.example.com -showcerts
观察返回的证书是否包含目标域名、是否能被本地系统信任（可加 -CAfile /etc/nginx/ssl/upstream-ca.crt 测试）。
临时绕过验证快速定位问题
仅限调试阶段使用，切勿上线：
- 在对应
location块中添加：proxy_ssl_verify off; - 如果此时客户端访问恢复正常 → 问题 100% 出在上游证书或信任配置（非网络或后端宕机）
- 如果仍报 502 或超时 → 问题不在证书层，应排查网络连通性、后端服务状态、防火墙或协议误配（如
proxy_pass https://却连了 HTTP 端口）
