proxy_ssl_ciphers控制Nginx与后端HTTPS服务TLS握手时的加密套件顺序，仅作用于上游连接；需配合proxy_ssl_protocols、proxy_ssl_ecdh_curve和proxy_ssl_verify才能生效。

proxy_ssl_ciphers 控制 Nginx 作为反向代理时，与后端 HTTPS 服务建立 TLS 连接所允许使用的加密套件。它不作用于客户端到 Nginx 的连接，而是专门约束 Nginx 主动发起的上游请求——这点常被误读。配置不当会导致握手失败、降级到弱算法，甚至完全无法连通后端。

核心原则：顺序即优先级，不支持服务端优选

Nginx 的 proxy_ssl_ciphers 是严格按冒号分隔的顺序协商的，排在前面的套件优先尝试。它没有 proxy_ssl_prefer_server_ciphers 指令（该指令仅存在于 client-facing ssl_ciphers 中），所以你写的顺序就是最终协商顺序。这意味着：

• 把最安全且广泛兼容的套件放在最前，比如 ECDHE-RSA-AES128-GCM-SHA256
• 避免混入已淘汰算法（如 RC4、DES、MD5、EXPORT）——不是靠末尾加 !aNULL 来“过滤”，而是从源头只列可信套件
• 若后端只支持 TLS 1.2 且仅接受 CHACHA20，而你把 AES-GCM 套件全放前面，可能因不匹配直接失败

推荐配置与关键组合

兼顾现代安全性与主流后端兼容性（如 Spring Boot、Node.js、主流云服务后端）的典型配置如下：

proxy_ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:CHACHA20-POLY1305-SHA256;

说明：

aperture: the L402 aware reverse proxy

安装并运行 Aperture（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。

下载

• ECDHE-RSA-AES128-GCM-SHA256：当前最平衡的选择，前向保密强、性能好、几乎所有 TLS 1.2 后端都支持
• ECDHE-RSA-AES256-GCM-SHA384：提供更高密钥强度，适合对合规要求严格的场景
• CHACHA20-POLY1305-SHA256：对移动网络或老旧 OpenSSL 版本更友好，尤其在无硬件 AES 加速的环境中表现更稳

不建议盲目追加 !aNULL:!eNULL:!EXPORT 等禁用项——Nginx 解析时会跳过非法套件名，但冗余写法易引发维护误解，也掩盖真实兼容问题。

必须配套的三项基础配置

仅设 proxy_ssl_ciphers 不足以生效，以下三者缺一不可：

• 协议版本锁定：proxy_ssl_protocols TLSv1.2 TLSv1.3; —— 明确禁用 TLS 1.0/1.1，防止协商降级
• 椭圆曲线指定：proxy_ssl_ecdh_curve secp384r1:prime256v1; —— 提升 ECDHE 密钥交换成功率，避免因曲线不匹配导致握手中断
• 证书验证启用（强烈建议）：proxy_ssl_verify on; proxy_ssl_trusted_certificate /path/to/ca-bundle.pem; —— 防止中间人伪造后端身份，尤其在跨公网或混合云调用时

验证是否真正生效

不能只依赖配置语法检查（nginx -t）。实测才是关键：

• 开启 error_log debug 级别，在日志中搜索 “SSL_do_handshake” 或 “selected cipher”，确认实际协商结果
• 用 openssl 模拟 Nginx 行为：
  openssl s_client -connect backend.example.com:443 -tls1_2 -cipher 'ECDHE-RSA-AES128-GCM-SHA256' -servername backend.example.com
  观察输出中是否显示 “Cipher : ECDHE-RSA-AES128-GCM-SHA256” 且握手成功
• 若后端是自签名或私有 CA 签发，测试时需加 -CAfile 参数，否则会报 verify error