proxy_ssl_verify_depth 应匹配真实证书链结构：depth=1仅支持终端直连根CA，depth=2适配主流商业证书（如Let’s Encrypt R3→ISRG Root X1），depth=3适用于两级中间CA的企业PKI；过低致502错误，过高削弱安全性，须与proxy_ssl_verify on、proxy_ssl_trusted_certificate、proxy_ssl_name及proxy_ssl_server_name协同生效。
设置 proxy_ssl_verify_depth 不是单纯“调高更安全”或“调低更严格”，而是要匹配真实证书链结构，在防止误拒合规服务和避免接受可疑中间签发者之间取得平衡。
理解 depth 的实际含义
该值表示 Nginx 在验证后端证书时，最多允许向上追溯多少级中间 CA。注意：它统计的是中间证书的数量，不包括终端证书本身，也不包括根证书（根证书必须出现在 proxy_ssl_trusted_certificate 中，但不计入 depth）。
- depth 1 → 只接受“终端证书 ← 根 CA”这种直连结构（现实中极少）
- depth 2 → 支持“终端 ← 中间 CA ← 根 CA”，覆盖 Let’s Encrypt R3、Sectigo 等主流商业证书
- depth 3 → 适用于企业私有 PKI，含两级中间 CA 的场景（如 Root → SubCA1 → SubCA2 → 终端）
设得太低会直接导致 502 错误
即使后端证书完全合法、信任库完整，只要证书链层级超过设定 depth，Nginx 就会在 SSL 握手阶段终止连接，并在 error.log 中记录 certificate verify failed 或 SSL_do_handshake() failed。
Bailian Usage Proxy
下载
阿里百炼大模型平台多人共享账号用量统计代理服务。解决公司共用账号时无法区分个人用量的问题。适用场景：1)部署用量统计代理；2)统计多人Token用量和调用次数；3)管理大模型API调用配额。
- 常见诱因：后端只返回终端证书（未附带中间证书），而你又没在
proxy_ssl_trusted_certificate中补全对应中间 CA - 错误写法：
proxy_ssl_verify_depth 1;配合 Let’s Encrypt 的 R3 证书（需经 ISRG Root X1 验证），必然失败 - 验证方法：用
openssl s_client -connect backend.example.com:443 -showcerts查看实际返回的证书顺序和层级
设得过高反而削弱安全性
depth 过大（例如设为 10）会让 Nginx 接受嵌套过深、来源不明的中间签发链，可能绕过本应被拦截的非权威 CA。
- 攻击面扩大：恶意中间人若能控制某一级中间 CA，再签发多层子 CA，就可能利用高 depth 绕过校验
- 运维风险：容易掩盖证书链配置缺陷（比如本该由运维统一部署中间证书，却靠提高 depth 来“凑合”）
- 建议上限：生产环境一般不超过 3；自签名或单层链环境保持默认 1 即可
必须协同生效的关键配置
proxy_ssl_verify_depth 单独设置无效，它只是校验逻辑的一部分，以下四项必须同时存在且正确：
-
proxy_ssl_verify on;—— 明确启用校验（默认是 off） -
proxy_ssl_trusted_certificate /path/to/ca-bundle.pem;—— 文件中必须包含所有参与验证的根 CA 和中间 CA（PEM 格式，顺序无关） -
proxy_ssl_name "backend.example.com";—— 必须与后端证书中的 SAN 字段精确匹配（尤其当proxy_pass使用 IP 或变量时） -
proxy_ssl_server_name on;—— 启用 SNI，确保 TLS 握手时发送正确的域名，否则后端可能返回默认证书
