Nginx 默认不校验后端证书，upstream 状态异常通常源于前端SSL证书过期或后端服务主动拒连；仅当配置 proxy_ssl_verify on 时，后端证书过期才导致502错误，此时应临时关闭校验并推动后端更新证书。
后端证书过期本身不会导致 Nginx 的 upstream 状态异常，Nginx 默认不校验后端 HTTPS 服务的证书有效性。所谓“Upstream 状态异常”，实际多为误判——真正出问题的是 Nginx 自身对外提供的 SSL 证书过期（用户访问时浏览器报错），或后端服务因证书错误主动拒绝连接（极少数严格配置场景）。下面分两类情况说明。
确认是否真由后端证书引发问题
Nginx 默认信任所有后端 HTTPS 证书（包括过期、自签名、域名不匹配）。只有显式启用证书校验，才可能因后端证书失效触发连接失败：
- 检查 Nginx 配置中是否含有
proxy_ssl_verify on;—— 若开启，还需配套配置proxy_ssl_trusted_certificate和proxy_ssl_verify_depth - 若未启用校验，但出现
502 Bad Gateway或日志中含SSL_do_handshake() failed，大概率是后端服务自身拒绝了 TLS 握手（例如用 Java 启动的 Spring Boot 服务启用了ssl.trust-store强制校验） - 用
curl -v https://backend-host:port直连后端，观察是否返回证书过期警告或直接断连，可快速定位责任方
如确需校验后端证书：安全但需谨慎配置
启用校验能提升安全性，但会引入单点风险。配置必须完整，否则 upstream 会持续标记为 down：
- 在
location或upstream块中添加：proxy_ssl_verify on;<br>proxy_ssl_verify_depth 2;<br>proxy_ssl_trusted_certificate /etc/nginx/ssl/backend-ca-bundle.pem;
-
proxy_ssl_trusted_certificate必须包含后端证书链中的全部 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 + Alertmanager，在证书剩余有效期
- 对关键后端，可在应用层做健康检查接口（如
/healthz），Nginx 用health_check指令主动探测，比依赖 TLS 更可靠
附：快速恢复上游可用性的操作
若已发生 upstream 被标记为 down，且确认后端服务已修复证书，需手动恢复：
- 执行
nginx -s reload—— 仅重载配置，不重建连接池，对已缓存的失效状态无效 - 执行
nginx -s reopen或重启 worker 进程（如kill -USR1 $(cat /var/run/nginx.pid)），强制刷新 upstream 连接状态 - 更稳妥做法：临时在 upstream 中添加
max_fails=0 fail_timeout=0，reload 后再改回原值
