Nginx回源TLS套件合规配置的关键是精准控制proxy_ssl_ciphers与proxy_ssl_protocols、proxy_ssl_verify的协同生效逻辑，必须在location/server块中显式配置、仅对HTTPS upstream生效，且需匹配协议版本与后端能力，并配合证书校验、SNI设置及手动验证确保整链可控。

要让 Nginx 回源时使用的 TLS 加密套件满足内网特定合规要求（比如等保三级、金融行业加密规范或内部安全基线），关键不是“启用”proxy_ssl_ciphers，而是**精准控制它与 proxy_ssl_protocols、proxy_ssl_verify 协同生效的上下文和取值逻辑**。

明确作用域与生效前提

proxy_ssl_ciphers 只在以下条件下起作用：

• 必须写在 location 或 server 块中，且与 proxy_pass https://... 在同一作用域
• 仅对 HTTPS 类型的 upstream 生效；若 proxy_pass http://，该指令被完全忽略
• 不继承自 http 块，必须显式配置，不能靠全局默认
• 需配合 proxy_ssl_protocols（如 TLSv1.2 TLSv1.3）才能协商出指定套件，否则协议不匹配直接失败

按合规要求定制加密套件列表

不同合规场景对算法有硬性限制。例如：

FastAPI Flask Proxy

FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。

下载

• 等保三级推荐禁用 RC4、3DES、MD5、SHA1，优先使用 ECDHE-ECDSA-AES256-GCM-SHA384 或 ECDHE-RSA-AES256-GCM-SHA384
• 国密合规场景需搭配支持 SM2/SM3/SM4 的 OpenSSL 补丁版，并启用类似 ECDHE-SM2-SM4-SM3（需后端也支持）
• 某些老旧内网系统只支持 TLS_RSA_WITH_AES_256_CBC_SHA，此时需显式列出并置于靠前位置，同时关闭 proxy_ssl_verify 或补全信任链

写法示例（强加密优先）：

proxy_ssl_ciphers "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:!aNULL:!MD5:!RC4:!3DES";

配套验证与调试要点

仅设套件不够，必须确保整条 TLS 握手链可控：

• 开启 proxy_ssl_verify on 并指定 proxy_ssl_trusted_certificate，防止回源连到伪造服务
• 若后端证书 SAN 是 api.internal.local，但 proxy_pass 写的是 IP（如 https://10.1.2.3），必须加 proxy_ssl_name "api.internal.local"，否则校验失败
• 通过 openssl s_client -connect backend:443 -cipher 'ECDHE-ECDSA-AES256-GCM-SHA384' -tls1_2 手动验证后端是否真能响应该套件
• Nginx 错误日志中出现 SSL_do_handshake() failed，大概率是协议/套件不匹配或证书链缺失，不是配置没生效

常见内网适配组合参考

根据典型内网环境快速选配：

• 现代私有云（K8s Ingress + 自签证书）：
  proxy_ssl_protocols TLSv1.2 TLSv1.3;
proxy_ssl_ciphers "TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256";
• 老旧 Windows Server IIS（仅支持 TLS 1.2 + SHA256）：
  proxy_ssl_protocols TLSv1.2;
proxy_ssl_ciphers "ECDHE-RSA-AES256-SHA384:AES256-SHA256";
• 金融核心系统（禁用 RSA 密钥交换，强制 ECDSA）：
  proxy_ssl_ciphers "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305";
  并确保后端证书为 ECDSA 签发