proxy_ssl_verify 是 Nginx 作为反向代理连接上游 HTTPS 服务时，校验该上游服务器返回的 TLS 证书合法性的开关；它不验证客户端证书，也不影响 Nginx 自身对外提供的证书，必须配合 proxy_ssl_trusted_certificate 等指令协同生效，否则静默降级。
nginx proxy_ssl_verify 是什么，它到底验证谁的证书
proxy_ssl_verify 控制的是 Nginx 作为反向代理时，**主动连接上游（upstream）HTTPS 服务时**，是否校验该上游服务器返回的 TLS 证书。它不验证客户端传来的证书，也不影响 Nginx 自己对外提供的 HTTPS 证书。
常见误解是以为它能用来做“客户端证书透传校验”，其实不是——那是 ssl_client_certificate + ssl_verify_client 的事。这里只管“Nginx 去连后端微服务”这一跳的安全性。
- 必须搭配
proxy_ssl_trusted_certificate使用，否则即使设为on也无效（Nginx 会静默降级） - 若后端用的是自签名证书或私有 CA 签发的证书，
proxy_ssl_trusted_certificate必须包含对应根证书（PEM 格式） - 默认值是
off，不显式开启就等于完全不校验，哪怕后端证书已过期、域名不匹配、链不完整，Nginx 都照转不误
启用验证的关键配置项和顺序不能错
这组指令必须出现在 location 或 upstream 块内，且依赖关系明确：先指定可信 CA，再开启校验，最后可选控制严格程度。
典型安全配置如下：
aperture: the L402 aware reverse proxy
下载
安装并运行 Aperture（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。
location /api/ {
proxy_pass https://backend-svc;
proxy_ssl_verify on;
proxy_ssl_trusted_certificate /etc/nginx/certs/internal-ca.pem;
proxy_ssl_verify_depth 2;
proxy_ssl_session_reuse off;
}
-
proxy_ssl_trusted_certificate路径必须可读，且内容是 PEM 格式根证书（支持多个拼在一起），不能是证书链中间件或终端实体证书 -
proxy_ssl_verify_depth指证书链最大验证深度，默认 1；若后端用的是二级中间 CA 签发的证书，就得设为 2，否则校验失败 -
proxy_ssl_session_reuse off建议关闭——开启时可能复用旧 session，绕过证书重校验，导致异常证书被缓存生效 - 所有
proxy_ssl_*指令在 HTTP 块中全局设置无效，必须在具体转发上下文中声明
验证失败时 Nginx 怎么报错？怎么快速定位问题
失败不会返回 502 Bad Gateway 这类通用错误，而是直接抛出 SSL_do_handshake() failed 类似日志，并伴随具体原因，比如：
-
SSL certificate verify error: unable to get local issuer certificate→proxy_ssl_trusted_certificate缺少对应根证书 -
SSL certificate verify error: certificate has expired→ 后端证书过期，或系统时间不同步（注意：Nginx 不自动同步时间，宿主机时间不准会导致误判） -
SSL certificate verify error: certificate is not yet valid→ 后端证书未生效，或 Nginx 所在机器时间快于实际时间 -
SSL certificate verify error: hostname mismatch→ 后端证书里的Subject Alternative Name不含 proxy_pass 中写的域名/IP（例如你写https://10.1.2.3，但证书只签了svc.cluster.local）
调试时务必打开 error_log /var/log/nginx/error.log debug;，否则这些细节全被吞掉。
微服务场景下容易被忽略的三个硬伤
在 Kubernetes 或 Service Mesh 环境中，直接套用文档默认配置大概率踩坑：
- 后端是 Pod IP 直连（如
https://10.244.1.5:8443），但证书通常只签了 service name 或 pod FQDN，IP 不在 SAN 里 → 解决方法：要么重签含 IP 的证书，要么改用 DNS 名（如https://my-svc.namespace.svc.cluster.local）并确保 resolver 可用 - 使用 cert-manager 自动生成证书，但没把 CA Bundle 注入到 Nginx 容器的
/etc/nginx/certs/下，或者挂载路径权限不对（Nginx worker 是非 root 用户，需确保文件 world-readable） - 启用了
proxy_ssl_server_name on却没配 SNI，导致某些 gRPC 或 Istio sidecar 拒绝握手 → 实际上多数内部微服务不需要 SNI，除非你明确知道后端依赖它，否则别开
最麻烦的一点是：验证失败日志只打在 error log，access log 里完全看不出异样，请求看起来只是“慢”或“超时”，容易误判成网络或后端性能问题。
