proxy_ssl_ciphers控制nginx与后端https服务tls握手时的加密套件顺序，仅作用于proxy_pass https://的上游连接，需配合proxy_ssl_protocols、proxy_ssl_ecdh_curve和proxy_ssl_verify才能生效；顺序即优先级，推荐ecdhe-rsa-aes128-gcm-sha256:ecdhe-rsa-aes256-gcm-sha384:chacha20-poly1305-sha256。

proxy_ssl_ciphers 不是用来加速客户端访问的，而是控制 Nginx 主动连接后端 HTTPS 服务时用什么加密套件——它影响的是反向代理“回源”这一步的 TLS 握手效率和安全性。真正能提速的关键，在于选对低延迟、硬件友好、支持前向保密（PFS）且被后端广泛支持的现代套件，并按优先级精准排序。

只对 proxy_pass https:// 生效，位置必须正确

该指令仅在 location 或 server 块中、与 proxy_pass https://... 处于同一作用域时才起作用。写在 http 块顶层或用于 http:// 回源时，完全无效。

• ✅ 正确示例：
  

  location /api/ {<br>
    proxy_pass https://upstream;<br>
    proxy_ssl_protocols TLSv1.2 TLSv1.3;<br>
    proxy_ssl_ciphers "ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-CHACHA20-POLY1305";<br>
  }

• ❌ 常见错误：把 proxy_ssl_ciphers 放在 upstream 块里，或全局写在 http 中

高性能套件排序原则：ECDHE + AEAD + 硬件加速优先

Nginx 按你写的顺序从左到右尝试协商，不支持服务端优选。所以要把最安全、最快、最兼容的组合放在最前面：

CPA Update - Secure CLI Proxy API Maintenance

安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。

下载

• AES-GCM 类套件（如 ECDHE-RSA-AES128-GCM-SHA256）：现代 CPU 普遍有 AES-NI 指令集加速，加解密延迟极低，且是 AEAD 模式，更安全
• ChaCha20-Poly1305（如 ECDHE-RSA-CHACHA20-POLY1305）：在无 AES-NI 的设备（如部分 ARM 移动终端或老旧服务器）上性能优于 AES-GCM，适合混合后端环境
• 避免 CBC 模式（如 AES256-SHA）、禁用 RC4/3DES/MD5/SHA1 —— 它们不仅慢，还存在已知漏洞

必须配合 proxy_ssl_protocols 和 proxy_ssl_ecdh_curve

光设套件不够，协议和密钥交换也得匹配，否则直接握手失败：

• proxy_ssl_protocols TLSv1.2 TLSv1.3;：TLS 1.3 自动跳过 proxy_ssl_ciphers，但必须显式启用；TLS 1.2 才真正依赖你配的套件列表
• proxy_ssl_ecdh_curve secp384r1:prime256v1;：指定 ECDH 曲线，secp384r1 运算更快，prime256v1 兼容性更广；两者都支持 PFS，比传统 RSA 密钥交换更高效

验证是否真正生效，别只信配置

改完配置后，务必确认 Nginx 实际协商出的套件确实是你要的：

• 开启调试日志：error_log /var/log/nginx/error.log debug;，查找 SSL accepted cipher: 行
• 手动测试后端支持：openssl s_client -connect backend.example.com:443 -cipher 'ECDHE-RSA-AES128-GCM-SHA256' -tls1_2，看是否成功握手
• 若后端是自建服务，检查其 TLS 日志中记录的 cipher_name 和 protocol_version