proxy_ssl_verify_depth需配合proxy_ssl_verify、proxy_ssl_trusted_certificate、proxy_ssl_name和proxy_ssl_server_name四指令协同生效，按内网CA层级设为1–3，同时关闭session复用并限定TLS协议版本以确保缓存下证书校验可靠。
要让 Nginx 在代理内网微服务时，既支持缓存又确保 TLS 证书链校验不被绕过、不误判，proxy_ssl_verify_depth 不是单独调大就能起效的参数，它必须嵌入一套完整、协同的验证上下文里。
为什么内网场景下 proxy_ssl_verify_depth 容易被设错
内网微服务常用私有 CA 签发证书，典型链结构是「终端证书 → 中间 CA → 根 CA」三层。Nginx 默认 proxy_ssl_verify_depth 1，只认“终端证书由根 CA 直签”，遇到中间层就会报 certificate verify failed，导致 502 或缓存穿透失败。但盲目设为 5 或 10 也不行——过深可能接纳非法嵌套中间签发者，削弱信任锚效力。
必须配套启用的四项基础指令
仅改 depth 值毫无意义。以下四条必须在同一个 location 块中同时存在：
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
- proxy_ssl_verify on; —— 明确开启上游证书校验（默认是 off）
- proxy_ssl_trusted_certificate /etc/nginx/ssl/internal-ca-bundle.pem; —— 指向含完整内网 CA 证书的 PEM 文件，必须同时包含根 CA 和所有中间 CA（顺序不限，但缺一不可）
-
proxy_ssl_name "svc.internal.company"; —— 显式声明期望的后端域名，用于匹配证书 SAN 字段（尤其当
proxy_pass使用变量或 IP 地址时必需） - proxy_ssl_server_name on; —— 启用 TLS SNI 扩展，确保握手时发送正确域名，避免后端返回默认证书
depth 的合理取值与内网实际对应关系
按你内网 PKI 的实际层级设定，不是拍脑袋：
- 自签名终端证书（无中间层）：设为 1，但需确保
trusted_certificate中已包含该自签根证书 - 一级中间 CA（终端 → 中间 → 根）：设为 2，覆盖大多数企业内部 CA 部署
- 两级中间 CA 或多分支链（如金融、政务类私有 PKI）：设为 3，生产环境推荐起步值
缓存链路中必须规避的校验失效风险
启用 proxy_cache 后，若不干预 TLS 层行为，可能复用旧 session 导致异常证书被缓存生效：
- proxy_ssl_session_reuse off; —— 关闭 TLS session 复用，强制每次连接都真实校验证书
- proxy_ssl_protocols TLSv1.2 TLSv1.3; —— 禁用老旧协议，防止降级干扰验证逻辑
- 不要在
http或server块中全局设置这些proxy_ssl_*指令——它们只在location或upstream上下文中生效
快速验证是否真正生效
修改后重载 Nginx，再做两件事：
- 检查 error.log：不应出现 SSL_do_handshake() failed 或 certificate verify failed
- 用 openssl 手动抓链：
openssl s_client -connect svc.internal.company:443 -servername svc.internal.company -showcerts 2>/dev/null | grep "BEGIN CERTIFICATE" | wc -l，确认返回证书数量与预期层级一致
