Nginx 代理 HTTPS 后端时证书报错，本质是其作为客户端未通过后端证书校验；需显式启用 proxy_ssl_verify on 并配置 proxy_ssl_trusted_certificate，确保后端返回完整证书链、正确 SNI 传递及信任文件合规。
排查 Nginx 代理 HTTPS 后端时的证书报错，核心是明确 Nginx 此时扮演的是“HTTPS 客户端”角色——它要主动验证后端服务返回的证书是否可信。错误日志里常见的 SSL_do_handshake() failed、certificate verify failed 或直接 502，基本都源于这一环节校验失败，而非浏览器端问题。
检查 Nginx 是否真正开启证书验证
默认情况下 proxy_ssl_verify 是关闭的，即使配置了 proxy_pass https://，Nginx 也不会校验后端证书。必须显式启用：
- 在
location或upstream块内写proxy_ssl_verify on;（写在http或server块中无效） - 同时必须配
proxy_ssl_trusted_certificate，否则会因找不到信任锚而直接失败 - 临时关闭验证（
proxy_ssl_verify off;）可快速判断是否为证书问题：若关闭后正常，则问题一定出在信任链配置上
确认后端是否返回完整且顺序正确的证书链
Nginx（以及 curl、安卓等）要求后端在 TLS 握手时一次性发送“域名证书 + 所有中间证书”，不能只发终端证书，也不能含根证书或顺序颠倒：
- 用命令模拟 Nginx 视角：
openssl s_client -connect 后端IP:443 -servername backend.example.com -showcerts - 观察输出中
BEGIN CERTIFICATE块：第一块必须是你的域名证书；第二块起应为中间证书，且上一块的Subject要与下一块的Issuer匹配；最后一块绝不能是根证书（如 ISRG Root X1） - 若只看到一块证书，说明后端未配置完整链，需将中间证书拼入
fullchain.pem并重新加载
验证 SNI 是否正确传递并匹配证书 SAN
当 proxy_pass 指向 IP 地址或变量时，Nginx 默认不发 SNI，后端可能返回默认证书，导致域名不匹配：
- 必须启用 SNI：
proxy_ssl_server_name on; - 必须指定目标域名：
proxy_ssl_name "api.internal.com";（值须与后端证书的Subject Alternative Name完全一致，包括大小写、www.前缀、通配符格式） - 若
proxy_pass使用变量（如https://$backend_host），proxy_ssl_name更不可省略
核对本地信任证书文件是否合规可用
proxy_ssl_trusted_certificate 指向的不是你的站点证书，而是 Nginx 用来验证后端证书的“可信根 CA + 中间 CA”集合：
- 文件必须为 PEM 格式，仅含 CA 证书（每段以
-----BEGIN CERTIFICATE-----开头），不能含私钥、终端证书或重复根证书 - 可用命令验证：
openssl x509 -in /etc/nginx/ssl/upstream-ca.crt -text -noout | grep "Subject:"，确认输出含预期 CA 信息 - 文件权限设为
644，确保 Nginx 工作进程（如www-data）可读；路径需绝对且真实存在（常见报错BIO_new_file() failed往往因路径错误或权限不足）
