Nginx默认不校验后端证书，证书失效本身不会触发upstream故障转移；所谓连通性故障多为误判，真正原因通常是Nginx自身对外SSL证书过期或后端服务主动拒连，需先直连验证、查日志、确认proxy_ssl_verify是否启用，再针对性处理。
证书失效本身不会直接触发 Nginx 的 upstream 故障转移，因为 Nginx 默认不校验后端 HTTPS 证书。所谓“因证书失效导致后端连通性故障”，绝大多数情况是误判——真正出问题的，其实是 Nginx 自身对外提供的 SSL 证书过期（用户访问报 526/NET::ERR_CERT_DATE_INVALID），或是后端服务自身因证书异常主动拒连。处理重点不是让 Nginx “转移”出去，而是厘清责任边界、快速恢复连通。
先确认是不是真由后端证书引起
别急着改配置。Nginx 默认对后端 HTTPS 完全信任，哪怕证书过期、自签名、域名不匹配，只要 TCP 连得上，TLS 握手就能完成。只有显式开启 proxy_ssl_verify on，后端证书问题才会导致 502 错误并影响 upstream 状态。
- 查 Nginx 配置：搜索 proxy_ssl_verify，若未启用，那 upstream 异常大概率和后端证书无关，应排查后端服务是否崩溃、防火墙策略、网络路由或后端应用层 TLS 配置（如 Java 的 trust-store 强制校验）
- 直连验证：用 curl -v https://backend-host:port 绕过 Nginx，看是否返回 Certificate expired 或直接断连。若直连就失败，问题在后端；若直连正常，问题在 Nginx 配置或中间链路
- 看 error.log：搜 SSL_do_handshake() failed 或 certificate verify failed，这类日志只在 proxy_ssl_verify on 且校验失败时出现
如果确需校验后端证书，必须配全且容错
启用 proxy_ssl_verify 是安全增强手段，但会把后端证书生命周期变成单点风险。配置不完整，upstream 节点就会持续被标记为 down。
- 必须同时设置：proxy_ssl_verify on;、proxy_ssl_verify_depth 2;、proxy_ssl_trusted_certificate /path/to/ca-bundle.pem（该文件需含后端证书链全部 CA，PEM 格式，权限 644）
- 务必搭配重试机制：proxy_next_upstream error timeout http_502;，避免单个后端证书异常导致整个 upstream 不可用
- 若后端有多个实例且证书更新不同步，建议暂时关闭校验，优先推动后端统一更新，再择机开启
更推荐的做法：跳过校验 + 主动监控
生产环境普遍不校验后端证书，而是用轻量、可靠的方式提前发现风险。
- 保持默认：proxy_ssl_verify off;（Nginx 2.x 默认值），确保连通性不被证书拖累
- 加定时检查脚本：echo | openssl s_client -connect backend.example.com:443 2>/dev/null | openssl x509 -noout -dates，将剩余有效期推送到 Prometheus，剩余 ≤30 天即告警
- 用健康检查接口替代 TLS 依赖：后端提供 /healthz，Nginx 配置 health_check 指令主动探测 HTTP 状态，比依赖证书握手更稳定
顺便检查前端证书，避免混淆主因
99% 的“全线不可用”其实源于 Nginx 自身对外证书过期。用户浏览器打不开，不是后端挂了，是 Nginx 没法建立可信 HTTPS 连接。
- 运行 openssl x509 -in /etc/nginx/ssl/fullchain.pem -noout -dates，确认 Not After 时间晚于当前（2026年10月1日）
- 检查配置中 ssl_certificate 是否指向 fullchain.pem（非 cert.pem），ssl_certificate_key 权限是否为 600
- 执行 nginx -t && nginx -s reload，不要 restart，确保平滑切换
