必须同时配置proxy_ssl_verify on、proxy_ssl_trusted_certificate、proxy_ssl_name和proxy_ssl_server_name四项指令，缺一不可；否则校验失败并返回502错误。
要让 Nginx 真正校验上游 HTTPS 服务的证书合法性，proxy_ssl_trusted_certificate 是关键一环——它不是可选配置，而是刚性核验的“信任锚点”。只设 proxy_ssl_verify on 会直接失败返回 502，必须配齐可信 CA 证书路径，且内容必须精准匹配上游证书链。
明确 trusted_certificate 文件内容要求
该指令指向一个 PEM 格式文件，里面必须包含上游服务所用证书链中全部可信根证书和中间证书（按任意顺序拼接），但不能包含终端证书（即上游服务器自己的 .crt）或自签名中间证书。常见错误包括：
- 把上游服务的 server.crt 直接放进该文件 → 验证失败
- 只放了根 CA，漏掉中间 CA → 日志报 “unable to get local issuer certificate”
- 文件权限为 600 或 400 → Nginx worker 进程读取失败，静默跳过校验
- 使用系统默认 ca-certificates.crt 却未确认其中是否真含上游私有 CA → 实际不生效
正确指定路径与作用域
proxy_ssl_trusted_certificate 必须放在 location 块或 upstream 块内，不能仅写在 http 全局块（除非所有 upstream 都共用同一套 CA）。路径建议使用绝对路径，避免因工作目录变动导致加载失败：
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
- 推荐写法：
proxy_ssl_trusted_certificate /etc/nginx/ssl/internal-ca.pem; - 若上游分属不同 CA（如 auth-svc 用 A 公司 CA，payment-svc 用 B 公司 CA），应为每个 upstream 单独配置对应证书文件
- 文件内容可用
cat root.crt intermediate.crt > internal-ca.pem合并，确保每段以-----BEGIN CERTIFICATE-----开头、-----END CERTIFICATE-----结尾，无空行或乱码
配合 proxy_ssl_verify_depth 设置链深度
证书链越长，越需要显式声明验证深度。默认值为 1（仅校验终端证书是否由 trusted_certificate 中的 CA 直签），但多数生产环境是 “根 CA → 中间 CA → 服务器证书” 三层结构：
- 三层链：设
proxy_ssl_verify_depth 2; - 含多级中间 CA 的私有 PKI：设
proxy_ssl_verify_depth 3;或更高 - 深度不足会导致 “certificate chain too long” 或 “self-signed certificate in certificate chain” 错误
- 该指令需与
proxy_ssl_trusted_certificate同级配置，缺一不可
验证是否真正生效
配置后不能仅看 Nginx 启动是否成功，需主动触发校验行为并观察日志：
- 临时开启 debug 日志：
error_log /var/log/nginx/error.log debug;（生产环境慎用） - 故意将 upstream 指向一个证书已过期或 SAN 不匹配的服务，观察 error.log 是否出现
SSL_do_handshake() failed或certificate verification failed - 用
openssl s_client -connect upstream-host:port -CAfile /path/to/trusted.pem手动验证证书链是否完整可信 —— 若命令成功，Nginx 也应能通过 - 确认 Nginx 版本 ≥ 1.7.0（
proxy_ssl_*系列指令从此版本起稳定支持）
