Nginx代理HTTPS上游报证书验证失败，可信链与域名处理方法

浏览器访问 Nginx 正常，但 Nginx 与 HTTPS 上游握手失败，日志出现上游证书校验错误。前端证书正常并不能证明反向代理到上游的证书链也正确。

先核对上游证书的签发链、验证域名和 SNI，再调整信任配置。 关闭验证虽然可能让请求暂时通过，却会失去上游身份校验。

先区分两段TLS连接

浏览器到 Nginx 的 ssl_certificate 与 Nginx 到 proxy_pass https://... 的上游 TLS 是两段独立连接。查看错误日志和完整配置：

sudo nginx -T
sudo tail -n 100 /var/log/nginx/error.log

关注 upstream SSL certificate verify error、证书域名不匹配和握手失败等具体信息。不要仅凭客户端浏览器的小锁图标判断上游可信。

核对上游证书与名称

在能够直连上游的主机上检查握手，示例域名应换成实际证书名称：

openssl s_client -connect upstream.example.net:443 -servername upstream.example.net -showcerts </dev/null

核对 SAN、有效期及完整中间证书链。若连接地址是内网 IP，而证书只包含域名，验证名称应使用证书中的域名；不要为了匹配而把证书名称随意改成 IP。

启用明确的上游验证配置

在对应的 location 内按实际 CA 文件和域名配置：

location /api/ {
    proxy_pass https://10.0.0.10:443;
    proxy_ssl_server_name on;
    proxy_ssl_name upstream.example.net;
    proxy_ssl_trusted_certificate /etc/nginx/ca/upstream-ca.pem;
    proxy_ssl_verify on;
    proxy_ssl_verify_depth 2;
}

proxy_ssl_name 指定验证上游证书时使用的名称，并用于 SNI。proxy_ssl_trusted_certificate 指向验证上游证书的可信 CA 文件；其内容应按证书链实际情况准备。proxy_ssl_verify 默认是关闭的，显式开启前必须准备可信链。

根据报错选择修复点

若提示无法建立签发链，检查 CA 文件是否包含正确的根和所需中间证书、上游是否提供完整链；若提示名称不匹配，检查 proxy_ssl_name 与证书 SAN；若握手协议失败，进一步检查上游 TLS 版本、SNI 和网络路径。

证书过期或错误签发应由上游更换。不要把 proxy_ssl_verify off 当作长期修复，也不要把来源不明的证书加入系统信任库。

先测试配置再平滑加载

sudo nginx -t
sudo systemctl reload nginx
sudo tail -n 100 /var/log/nginx/error.log

如果 nginx -t 失败，不执行 reload。生产变更前备份配置及 CA 文件；需要复现内网代理时，可在 萤光云 或 LightNode 的隔离实例用测试证书验证，避免复制生产私钥。

验收实际代理请求

从客户端请求受影响的路径，并同时观察 Nginx 错误日志和上游日志。验收条件是代理返回预期业务结果，证书验证保持开启，日志不再出现上游校验错误。

若仍返回 502，要根据新的日志区分连接拒绝、超时与证书问题，不能把不同故障都归因于 TLS。

FAQ

为什么浏览器证书没问题，代理仍然失败？ 浏览器校验的是前端 Nginx 证书，上游证书由 Nginx 单独校验。

自签证书能用吗？ 可以在受控环境中把正确 CA 配置为可信来源，并核对名称；不应关闭验证。

温馨提示

私有 CA 文件和上游证书轮换应纳入变更记录。验证域名、SNI 和可信链必须指向同一个预期上游身份。