选对 ssl_ecdh_curve 能直接降低 tls 握手延迟 30%–50%，核心在于密钥交换环节的计算效率差异——它不改变加密强度，但显著减少服务端 cpu 密钥生成耗时，尤其在高并发场景下效果立竿见影。
选对 ssl_ecdh_curve 能直接降低 TLS 握手延迟 30%–50%，核心在于密钥交换环节的计算效率差异——它不改变加密强度，但显著减少服务端 CPU 密钥生成耗时，尤其在高并发场景下效果立竿见影。
为什么 X25519 是性能提升的关键支点
X25519 不是“可选项”，而是现代 TLS 握手的效率基线：
- 标量乘法比 prime256v1（secp256r1）快 2–3 倍，ARM 移动芯片和 x86 服务器上均实测显著提速
- 固定 32 字节密钥长度，无变长解析逻辑，指令路径更短、分支更少，抗时序侧信道攻击能力强
- OpenSSL、BoringSSL、LibreSSL 均采用同一高效汇编实现，执行稳定，不依赖运行时判断
- Nginx 1.11.0+ 原生支持，无需额外模块或 patch，配置即生效
曲线顺序决定真实协商结果
ssl_ecdh_curve 的值是**优先级列表**，不是集合。客户端按你写的顺序逐项匹配，匹配成功即停止：
- ✅ 正确写法：
ssl_ecdh_curve X25519:prime256v1;—— 现代客户端直选 X25519；旧设备（如 Android 4.x、IE 11 on Win7）回落 prime256v1 - ❌ 错误写法：
ssl_ecdh_curve prime256v1:X25519;—— 客户端看到第一个就协商成功，根本不会尝试后续曲线 - ⚠️ 过度扩展：
ssl_ecdh_curve X25519:secp384r1:secp521r1;—— ClientHello 携带更多曲线 ID，服务端遍历开销增加，TLS 1.2 下尤为明显
避开低效曲线，避免隐性性能损耗
某些曲线理论安全，但实际部署中会拖慢握手：
- secp384r1 计算开销比 X25519 高近 2 倍，高并发下易成 CPU 瓶颈
- secp521r1 在绝大多数业务中无必要，反而降低握手成功率（部分嵌入式设备、旧 Java 客户端不支持）
- sect163k1、brainpoolP256r1、secp192r1 等已被现代 OpenSSL 默认禁用，无需显式写入，也不建议启用
单点配置无法释放全部性能
ssl_ecdh_curve 只优化密钥交换环节，必须配合以下设置才能体现真实收益：
- 协议版本：至少启用
ssl_protocols TLSv1.2 TLSv1.3;，推荐直接启用 TLS 1.3 并关闭更低版本 - 会话复用：
ssl_session_cache shared:SSL:10m; ssl_session_timeout 10m;，让重复访问跳过完整握手 - OCSP Stapling：
ssl_stapling on; ssl_stapling_verify on;，避免客户端远程查吊销状态，节省 100ms+ 延迟 - 密码套件：搭配 ECDHE-GCM 套件，并设
ssl_prefer_server_ciphers off;，让客户端优先选含 X25519 的组合
