proxy_ssl_verify_depth 控制Nginx验证上游证书链时允许的最大中间CA层级数，必须设为实际链长度（如三级链设为3），配合proxy_ssl_verify on和proxy_ssl_trusted_certificate才能生效；设小则报“unable to get issuer certificate”，设大则掩盖证书链缺失风险。
proxy_ssl_verify_depth 控制 Nginx 验证上游 HTTPS 服务证书链时允许的最大签名层级数。它不单独起作用，而是配合 proxy_ssl_verify on 和 proxy_ssl_trusted_certificate 共同保障后端微服务 TLS 证书的完整信任链校验。
为什么 depth 值必须匹配实际证书链结构
若设得太小，Nginx 会在验证中途终止，报 SSL certificate error: unable to get issuer certificate；若设得过大（如远超实际层级），虽不报错，但可能掩盖中间 CA 配置缺失问题，带来误判风险。
- 自签名证书或根 CA 直签终端证书 → depth = 1（根直接签发）
- 私有 CA → 中间 CA → 微服务证书 → depth = 2（根→中间→终端）
- 三级链（根→一级中间→二级中间→终端）→ depth = 3
如何确认后端证书的真实链深度
在能访问后端服务的机器上执行：
openssl s_client -connect backend-svc:443 -showcerts 2>/dev/null | openssl crl2pkcs7 -nocrl -certfile /dev/stdin | openssl pkcs7 -print_certs -noout观察输出中证书数量及 issuer/subject 关系，从终端证书向上追溯到可信根，统计跳数即为所需 depth。
⚠️ 已弃用 — 该技能已拆分为两个独立技能，以提升模块化程度：**webchat-https-proxy**（HTTPS/WSS 反向代理）和 **webchat-voi...**
配置位置与生效范围
该指令必须出现在 location 或 upstream 块内，不能写在 http 全局块中。例如：
upstream api_cluster {
server svc-a.internal:8443;
server svc-b.internal:8443;
}
server {
location /v1/ {
proxy_pass https://api_cluster;
proxy_ssl_verify on;
proxy_ssl_trusted_certificate /etc/nginx/certs/ca-bundle.pem;
proxy_ssl_verify_depth 2;
}
}
注意：同一 upstream 组中不同后端若使用不同 CA 链，需统一归一化为最深链对应的 depth，并确保 trusted_certificate 文件包含所有必需根和中间证书（PEM 拼接）。
常见疏漏与加固建议
- 未关闭 session 复用：
proxy_ssl_session_reuse off必须启用，否则旧 session 可绕过新证书校验 - trusted_certificate 权限错误：Nginx worker 进程需有读取权限，且文件仅含 PEM 格式根/中间证书，不含私钥或终端证书
- depth 与证书链不一致时，错误日志通常只显示
SSL_do_handshake() failed，需开启error_log /var/log/nginx/error.log debug;定位具体失败点
