Nginx 降低 TLS 握手 CPU 开销需协同优化 ssl_ciphers 顺序、ssl_conf_command 曲线与签名算法限制、启用共享会话缓存并关闭 0-RTT；关键在优先 ECDHE-ECDSA 套件、强制 X25519/secp256r1 曲线、剔除低效签名组合，且须 Nginx ≥ 1.19.4 + OpenSSL ≥ 1.1.1。
要让 Nginx 的 ssl_ciphers 配置真正优先使用 ECC（椭圆曲线）算法来降低 TLS 握手阶段的 CPU 消耗，关键不是简单罗列几个含 ECDHE 的套件，而是从协商顺序、密钥交换路径、底层曲线控制三方面协同优化。ECC 运算比传统 RSA 或 DH 快数倍，但若客户端仍能协商到低效曲线或冗余签名组合，CPU 节省效果就会打折扣。
把 ECDHE 套件放在最前面并限定证书类型
确保所有以 ECDHE-ECDSA 开头的套件排在 ECDHE-RSA 之前，因为 ECDSA 证书验证开销更小；同时避免混入任何非 ECDHE 的密钥交换方式：
-
ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305—— 仅保留 ECDSA 证书可用的强套件，跳过 RSA 证书路径 - 若必须兼容 RSA 证书，再接上
ECDHE-RSA-AES128-GCM-SHA256等，但绝不把DHE或RSA密钥传输类套件放在 ECC 之后 - 务必设置
ssl_prefer_server_ciphers on;，否则客户端可忽略你的顺序偏好
配合 ssl\_conf\_command 锁定高效曲线与签名算法
仅靠 ssl_ciphers 无法阻止 OpenSSL 在握手初期遍历大量低效曲线（如 secp384r1）和签名组合。需用底层指令直接裁剪协商空间：
-
ssl_conf_command Curves X25519:secp256r1;—— 强制只接受这两条高性能曲线，X25519 运算最快，secp256r1 兼容性最广 -
ssl_conf_command SignatureAlgorithms ecdsa_secp256r1_sha256:rsa_pss_rsae_sha256;—— 剔除 SHA1、MD5、ecdsa_secp384r1_sha384 等高开销选项 - 该配置要求 Nginx ≥ 1.19.4 + OpenSSL ≥ 1.1.1，且必须写在
ssl_certificate指令之后
关闭不必要特性，减少握手分支判断
某些 TLS 特性虽增强安全性，但在纯 ECC 场景下会引入额外 CPU 判断逻辑：
-
ssl_early_data off;—— 关闭 0-RTT 可省去一次 PSK 密钥派生，对 ECC 握手收益明显 -
ssl_session_cache shared:SSL:10m;—— 启用共享会话缓存，复用 ECDHE 主密钥，避免重复曲线运算 - 不启用
ssl_dhparam—— ECC 不依赖 DH 参数，留空可跳过 PEM 解析与模幂校验
验证是否真正生效
部署后用 openssl s_client -connect example.com:443 -tls1_2 -cipher "ALL" 手动测试，观察返回的 Server certificate 类型和 Shared ciphers 列表开头是否为 ECDHE-ECDSA 套件；再用 curl -I --http1.1 https://example.com 查看响应头中 Alt-Svc 或 Strict-Transport-Security 是否存在，间接确认 TLS 1.2 握手已稳定走通 ECC 路径。
