proxy_ssl_verify_depth 是控制Nginx验证后端HTTPS证书链深度的关键参数，必须配合proxy_ssl_verify on、proxy_ssl_trusted_certificate、proxy_ssl_name和proxy_ssl_server_name四项指令共同生效；默认值1仅支持终端证书直连根CA，内网多级私有CA需按实际层级设为2或3，否则校验失败返回502。
要让 Nginx 在反向代理内网微服务时正确验证其 HTTPS 证书，proxy_ssl_verify_depth 不是单独起作用的参数，而是信任链校验深度控制的关键一环。它必须配合启用验证、指定可信根证书、声明目标域名和开启 SNI 才能真正生效。
理解 proxy_ssl_verify_depth 的实际作用
该指令定义 Nginx 在验证后端证书时，最多允许多少级证书签发路径。默认值为 1，只接受“终端证书 → 根 CA”这种直连结构。但内网微服务普遍使用私有 CA 签发的证书，常见结构是：
- 终端证书（微服务自身）
- 中间 CA 证书（企业内部二级签发机构）
- 根 CA 证书（内网 PKI 的信任锚）
此时需将 proxy_ssl_verify_depth 设为 3，否则即使证书合法、信任库完整，也会因链过长而报 certificate verify failed，返回 502 错误。
必须同步配置的四项核心指令
仅改 depth 值无效，以下四者缺一不可：
aperture: the L402 aware reverse proxy
下载
安装并运行 Aperture（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。
- proxy_ssl_verify on; —— 明确开启上游证书校验（默认是 off）
- proxy_ssl_trusted_certificate /etc/nginx/ssl/internal-ca.pem; —— 指向 PEM 文件，内容仅含根 CA 和中间 CA 证书（顺序：根 → 中间），不能含私钥或终端证书
-
proxy_ssl_name "svc.internal.company"; —— 显式声明期望的后端服务域名，用于匹配证书中的 SAN 字段；若
proxy_pass使用变量或 IP，此项必不可少 - proxy_ssl_server_name on; —— 启用 TLS SNI，确保握手时发送正确域名，避免后端返回默认或不匹配的证书
针对内网场景的推荐取值与验证方式
根据你内网 PKI 的实际层级设定 depth：
- 自签名证书（无中间层）→ 设为 1，且
trusted_certificate中必须包含该自签根证书 - 一级中间 CA（终端 → 中间 → 根）→ 设为 2 或 3，推荐 3 以留出扩展余量
- 二级中间 CA（终端 → 中间1 → 中间2 → 根）→ 设为 4，但应评估是否过度嵌套
验证是否生效：
- 重载 Nginx 后观察
error.log，无SSL_do_handshake或verify failed即初步成功 - 手动测试链完整性：
openssl s_client -connect svc.internal.company:443 -servername svc.internal.company，检查输出中Verify return code: 0 (ok)
增强内网通信安全的补充建议
在基础校验之上，可进一步加固：
- 禁用老旧协议：proxy_ssl_protocols TLSv1.2 TLSv1.3;，防止降级攻击
- 关闭会话复用：proxy_ssl_session_reuse off;，避免异常证书被缓存绕过校验
- 确保文件权限严格：
trusted_certificate文件仅对 nginx worker 进程可读（如644，属主 root） - 定期轮换内网 CA 证书，并同步更新 Nginx 的信任文件
