必须显式配置proxy_ssl_protocols tlsv1.3且不混用旧版本，同时通过proxy_ssl_trusted_certificate指定可信根证书，并确保openssl运行时版本≥1.1.1。
要通过 proxy_ssl_protocols 强制启用 TLS 1.3 提升反向代理到后端（即“缓存回源”）链路的安全性，关键不是简单加个版本号，而是切断旧协议协商路径、匹配 TLS 1.3 的运行约束，并确保证书验证不因协议升级而中断。
必须显式声明且仅保留 TLSv1.3
proxy_ssl_protocols 不继承 http 或 server 块中的 ssl_protocols，它完全独立。若想“强制”只走 TLS 1.3，配置必须是：
-
proxy_ssl_protocols TLSv1.3;—— 不能写成TLSv1.2 TLSv1.3，否则客户端或后端仍可能降级协商 - 该指令需放在
location或upstream块内，作用于代理发起的上游连接 - 搭配
proxy_ssl_verify on;才能真正发挥 TLS 1.3 的安全优势，否则加密链路形同虚设
配套可信证书根必须明确指定
当后端使用自签名证书、私有 CA 或内部 PKI 签发的证书时，Nginx 默认不信任它们。即使启用了 TLSv1.3，proxy_ssl_verify on 也会直接拒绝连接：
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
- 必须用
proxy_ssl_trusted_certificate /path/to/ca-bundle.crt;指向包含该后端证书签发者公钥的 PEM 文件 - 若未设置此指令，或路径错误/权限不足，Nginx 日志中会出现
SSL_do_handshake() failed或certificate verify failed - 建议将可信根与 Nginx 主配置分离管理，避免和前端 HTTPS 的
ssl_trusted_certificate混用
cipher 和密钥交换无需手动干预
TLS 1.3 的加密套件是协议内建固定的，共 5 种标准组合（如 TLS_AES_256_GCM_SHA384），Nginx 不会从 proxy_ssl_ciphers 中读取传统套件：
- 可以不配置
proxy_ssl_ciphers，Nginx 自动使用 TLS 1.3 允许的密钥交换+AEAD 组合 - 如果误配了含
ECDHE-RSA-AES256-GCM-SHA384这类 TLS 1.2 套件，不会报错，但可能导致协商失败或静默降级 - 如需显式控制（例如禁用 ChaCha20），可设
proxy_ssl_ciphers TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256;，仅列 TLS 1.3 套件名
依赖前提：OpenSSL 运行时版本 ≥1.1.1
Nginx 本身不实现 TLS，它调用编译时绑定的 OpenSSL 库。即使 nginx -v 显示 1.25.x，若实际链接的是 OpenSSL 1.0.2，TLS 1.3 就不可用：
- 执行
nginx -V 2>&1 | grep OpenSSL查看真实运行时版本（例如built with OpenSSL 1.1.1w） - 不要依赖系统
openssl version命令结果——那是 CLI 工具版本，和 Nginx 进程无关 - 若版本过低，需重新编译 Nginx 并指定新版 OpenSSL 路径，或切换为 Ubuntu 22.04+/AlmaLinux 9+ 等自带高版本 OpenSSL 的发行版官方包
