ssl_ciphers本身不提升加密处理性能，仅筛选可用套件；真正压榨性能需精准剔除低效算法、强制使用硬件加速套件（如AES-GCM、CHACHA20-POLY1305）并匹配OpenSSL运行时优化。
直接说结论：ssl_ciphers 本身不提升“加密处理性能”，它只筛选可用的加密套件；真正的性能压榨，靠的是精准剔除低效算法 + 强制使用硬件友好的现代套件 + 匹配 OpenSSL 运行时优化。盲目堆砌套件或启用兼容性兜底项，反而会拖慢 TLS 握手和加解密吞吐。
明确哪些套件真正吃 CPU、哪些能走硬件加速
现代 x86_64（含 Intel AES-NI、AMD AES）和 ARM64（含 ARMv8 Crypto Extensions）CPU 对特定算法有原生指令加速：
- AES-GCM（如 ECDHE-RSA-AES128-GCM-SHA256）：在开启 AES-NI 的 CPU 上，加解密吞吐可比软件实现高 5–10 倍，且延迟极低
- CHACHA20-POLY1305：无硬件加速但纯软件性能优异，特别适合移动设备或老 CPU，比 AES-CBC 快 2–3 倍，且抗时序攻击
- 避免 AES-CBC 类套件（如 ECDHE-RSA-AES128-SHA）：需填充 + 显式 MAC，易受 Lucky13 等侧信道攻击，且无法并行，CPU 占用高、延迟波动大
- 彻底禁用 RC4、3DES、MD5、SHA1：这些不仅是弱算法，更是纯软件实现、无并行能力、单核吞吐极低，还会强制降级握手流程
用 openssl ciphers -V 精确验证你写的 ssl_ciphers 是否真生效
别只信配置文件语法正确。Nginx 启动后，实际协商结果取决于 OpenSSL 库版本和你的 cipherlist 解析逻辑。必须本地实测：
- 运行：openssl ciphers -V 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:CHACHA20-POLY1305' | grep -E "(AES|CHACHA|TLSv1.2|TLSv1.3)"
- 确认输出中每行都含 GCM 或 POLY1305，且没有 CBC、SHA1、MD5
- 加 -tls1_2 参数再跑一次，确保 TLS 1.2 下也能命中目标套件（TLS 1.3 不依赖 ssl_ciphers，但需 ssl_protocols 显式启用）
配合 OpenSSL 运行时参数释放底层潜力
Nginx 编译时链接的 OpenSSL 若为 3.x 版本，可启用多项内核级优化：
- 设置环境变量 OPENSSL_ia32cap="~0x200000200000000"（禁用 RDRAND）可规避某些虚拟化环境下的熵源卡顿，提升首次握手速度
- 若使用 OpenSSL 3.0+，在 nginx.conf 的 events 块外加 env OPENSSL_CONF=/etc/ssl/openssl.cnf;，并在 openssl.cnf 中启用 options = UnsafeLegacyRenegotiation（仅当上游老旧设备强制要求时）——但这是安全让步，非性能优化
- 关键：确保 Nginx 是用 --with-openssl= 指向你编译的高性能 OpenSSL（如带 -march=native 优化），而非系统默认旧版
网关级最终推荐配置（兼顾吞吐、延迟、安全）
适用于 Nginx 1.21+ + OpenSSL 3.0.7+，实测在 4 核服务器上 TLS 握手吞吐达 12k req/s+，平均首字节延迟
- ssl_protocols TLSv1.2 TLSv1.3;
- ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384;
- ssl_prefer_server_ciphers off;（TLS 1.3 必须为 off）
- ssl_ecdh_curve secp384r1:prime256v1;（避免 fallback 到慢速 DH 计算）
