必须在upstream或location作用域内配置proxy_ssl_protocols TLSv1.2 TLSv1.3，禁用TLSv1.0/TLSv1.1；同步启用proxy_ssl_verify on、强cipher白名单及proxy_ssl_server_name on，满足PCI DSS等合规要求。
要让 Nginx 在反向代理上游 HTTPS 服务时满足 PCI DSS、等保2.0、NIST SP 800-52r2 等合规要求，必须显式限制出站 TLS 协议版本，核心是正确使用 proxy_ssl_protocols 指令——它专用于控制 Nginx 作为客户端连接后端时的行为，和面向用户的 ssl_protocols 完全无关。
只在 upstream 或 location 中配置，作用域不能错
该指令不支持写在 http 或 server 块顶层，否则无效。必须紧邻 proxy_pass https://... 生效：
- 推荐方式：在
upstream块内直接定义，便于复用和统一管理 - 替代方式：在具体
location块中、proxy_pass指令附近配置 - 若
proxy_pass目标是 HTTP（如http://127.0.0.1:3000），此指令完全不触发
协议值必须严格限定为 TLSv1.2 和 TLSv1.3
现代合规基线明确禁用 TLSv1.0 和 TLSv1.1，配置中不得出现任何旧版本：
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
- ✅ 正确：
proxy_ssl_protocols TLSv1.2 TLSv1.3; - ✅ 若后端暂不支持 TLSv1.3（如部分 Spring Boot 2.3 以下 + Tomcat 9.0.x），可退一步：
proxy_ssl_protocols TLSv1.2; - ❌ 错误：
proxy_ssl_protocols TLSv1 TLSv1.1 TLSv1.2;（含已淘汰协议） - ⚠️ 注意：Nginx 1.19.4+ 默认已移除 TLSv1 支持，即使写入也不会生效；显式排除更利于审计追溯
必须同步收紧配套行为，防止协议限制形同虚设
仅设协议不够，还需配合证书校验、SNI 和加密套件控制：
- 开启证书验证：
proxy_ssl_verify on;，并指定可信根证书：proxy_ssl_trusted_certificate /etc/ssl/certs/ca-certificates.crt; - 启用 SNI 并明确域名：
proxy_ssl_server_name on;+proxy_ssl_name "api.example.com";（不可用$host替代） - 限定强加密套件，避开 SHA1、RC4、弱密钥交换：
proxy_ssl_ciphers "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384";
验证是否真正生效
配置重载后，不能只看语法是否通过，需实测出站连接行为：
- 用 OpenSSL 主动测试上游地址：
openssl s_client -connect api.example.com:443 -tls1_2 -servername api.example.com（应成功） - 同样命令换
-tls1_1应失败，返回protocol is down类错误 - 检查 Nginx error log，若出现
SSL_do_handshake() failed或certificate verify failed，说明某项配套配置未到位
