proxy_ssl_verify_depth 默认为1，仅接受终端证书直连根CA的结构；实际多为三级链（终端→中间CA→根CA），需设为2或3以避免502错误，过高则削弱安全性，过低则误拒合规证书，必须配合proxy_ssl_verify on、proxy_ssl_trusted_certificate、proxy_ssl_name和proxy_ssl_server_name协同生效。
要通过 proxy_ssl_verify_depth 控制后端 HTTPS 服务证书链的校验深度，核心是让 Nginx 在验证上游证书时，只接受指定层数以内的完整可信链，避免过长或不可信的中间环节被误判为合法。
为什么需要设置 proxy_ssl_verify_depth
默认值为 1，意味着 Nginx 只允许“终端证书 → 根 CA”这种直连结构。但现实中多数公有云、CDN 或私有 PKI 环境使用的是“终端证书 → 中间 CA → 根 CA”三级链。若不调高该值，即使证书本身有效、信任库完整，也会因链太长而校验失败，导致 502 错误。
设得过高（如 10）则可能无意中接纳嵌套过深、来源不明的中间签发者，削弱验证效力；设得太低（如 1）又容易把合规部署拒之门外。合理取值能兼顾兼容性与安全性。
推荐配置值与对应场景
一般按实际证书链长度 +1 设置：
-
2 层链（终端 → 中间 CA）：设为
2，适用于大多数商业证书（如 Let’s Encrypt 的 R3 → ISRG Root X1） -
3 层链（终端 → 中间 CA → 根 CA）：设为
3，常见于企业私有 CA 或部分金融类后端 -
自签名或单层证书：可保持默认
1，但需确保proxy_ssl_trusted_certificate中已包含该自签根证书
必须配套的关键配置项
单独改 proxy_ssl_verify_depth 不起作用，必须和以下指令协同生效：
-
proxy_ssl_verify on;—— 明确启用证书验证（默认是 off） -
proxy_ssl_trusted_certificate /path/to/ca-bundle.crt;—— 指向含完整链的 PEM 文件，里面必须同时包含中间 CA 和根 CA（缺一不可） -
proxy_ssl_name "backend.example.com";—— 显式声明期望的 SNI 域名，用于匹配证书中的 SAN 字段（尤其当proxy_pass使用 IP 或变量时必需） -
proxy_ssl_server_name on;—— 启用 TLS SNI 扩展，确保握手时发送正确域名，避免后端返回默认证书
验证是否生效的方法
修改配置后重载 Nginx，再观察日志和行为：
- 成功时：请求正常返回，
error.log中无 SSL handshake 或 verify 相关错误 - 失败时：常见报错包括
SSL_do_handshake() failed、certificate verify failed，此时重点检查证书链是否完整、proxy_ssl_name是否匹配、SNI 是否启用 - 手动测试链完整性：
openssl s_client -connect backend-ip:443 -servername backend.example.com -showcerts，确认返回的证书顺序和数量是否与配置深度一致
