nginx启用proxy_cache时，proxy_ssl_verify_depth必须与proxy_ssl_verify on、proxy_ssl_trusted_certificate、proxy_ssl_name、proxy_ssl_server_name协同配置，且建议设为3并关闭tls会话复用以确保每次连接都严格校验证书链。
要让 Nginx 在启用 proxy_cache 的回源链路中真正安全地校验后端 HTTPS 证书，proxy_ssl_verify_depth 不是“加个数字就完事”的独立参数，而是整个 TLS 验证上下文里承上启下的关键一环——它必须和证书链完整性、SNI 声明、会话复用控制协同工作，否则缓存可能掩盖证书异常，导致长期信任失效。
为什么缓存场景下 depth 设置更关键
启用 proxy_cache 后，Nginx 可能复用连接或 TLS session。若 proxy_ssl_verify_depth 过低（如默认 1），而实际后端返回的是“终端 → 中间 CA → 根 CA”三级链，Nginx 会在首次连接时因校验失败而中断；但若配置错误导致校验被跳过（比如漏配 proxy_ssl_verify on），后续缓存响应可能持续转发来自不可信或已过期证书的服务流量，风险被放大。
正确设置 depth 能确保每次新连接都按预期层级完整追溯，不因缓存存在而放松验证标准。
必须同步满足的四项基础条件
仅调大 proxy_ssl_verify_depth 无效，以下四者需在同一个 location 或 upstream 块中明确声明：
-
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 扩展，确保握手时发送正确域名，避免后端返回默认或泛域名证书
depth 的合理取值与实操建议
该值表示允许向上追溯的中间 CA 数量上限（不计终端证书本身），推荐按后端实际证书链长度设定：
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
- 设为 2：适配 Let’s Encrypt R3、DigiCert TLS EA 等主流两级链（终端 → 中间 CA → 根 CA）
- 设为 3：覆盖企业私有 PKI 中常见三级结构（终端 → 部门 CA → 企业根 CA），生产环境起步建议值
- 避免设为 10 或更高：可能接纳来源不明、嵌套过深的签发者，削弱验证效力
注意：proxy_ssl_verify_depth 3 并不要求后端一定返回三层证书链，而是“最多允许三层”，兼容性与安全性兼顾。
缓存链路中需额外加固的两点
防止缓存行为干扰证书校验逻辑：
-
proxy_ssl_session_reuse off;—— 关闭 TLS session 复用，避免复用旧连接状态绕过证书重校验 -
proxy_ssl_protocols TLSv1.2 TLSv1.3;—— 明确禁用 TLSv1.0/1.1，防止协议降级干扰链验证过程
这两项虽不直接改变 depth 行为，但能确保 depth 控制的验证逻辑每次连接都真实执行，不被缓存机制稀释。
不复杂但容易忽略。
