要让Nginx真正启用强加密套件，必须严格分段排序TLS1.3与TLS1.2套件、启用ssl_prefer_server_ciphers on、限定ssl_protocols TLSv1.2 TLSv1.3，并指定ssl_ecdh_curve，缺一不可。
要让 Nginx 真正启用强加密套件，不能只靠堆砌算法名称，关键在于协议协同、排序逻辑和配套指令的完整配合。光写一行 ssl_ciphers 是无效的。
明确安全套件的组成原则
现代强套件必须满足三个硬性条件：使用 ECDHE 实现前向保密（PFS）、采用 AEAD 加密模式（如 AES-GCM 或 ChaCha20-Poly1305）、彻底排除已淘汰项（RC4、3DES、MD5、SHA1、NULL、ANONYMOUS 等）。
- ECDHE-RSA-AES128-GCM-SHA256 —— RSA 证书下最通用、兼容性最好的选择
- ECDHE-ECDSA-AES128-GCM-SHA256 —— ECDSA 证书专用，性能更优
- ECDHE-RSA-AES256-GCM-SHA384 —— 密钥强度更高，无兼容性损失
- ECDHE-RSA-CHACHA20-POLY1305 —— 移动网络或高延迟场景下表现更好
写出可生效的 ssl_ciphers 配置
TLS 1.3 和 TLS 1.2 套件机制不同，必须严格分段、按优先级从左到右排列：TLS 1.3 套件前置，且仅用标准 TLS13- 前缀；TLS 1.2 套件紧随其后，全部限定为 ECDHE+AEAD 组合。
推荐配置如下（Nginx 1.13+）：
如需极低版本兼容（如 Android 4.4.2），可在末尾追加兼容项，但绝不前置：
:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA;必须同步启用的配套指令
ssl_ciphers 单独存在不会生效，以下三项必须同时配置：
- ssl_prefer_server_ciphers on; —— 强制服务端按你写的顺序协商套件；否则客户端可能跳过强项，选最弱可用项
- ssl_protocols TLSv1.2 TLSv1.3; —— 明确禁用 TLSv1.0 和 TLSv1.1（已被 RFC 8996 正式弃用）
-
ssl_ecdh_curve secp384r1:prime256v1; —— 指定高效椭圆曲线，提升 ECDHE 性能并增强抗侧信道能力；Windows 下旧版 Nginx 可简化为
prime256v1
验证是否真正落地
配置重载成功（nginx -s reload）不等于安全生效。必须实测握手结果：
- 用 SSL Labs Server Test 查看 “Handshake Simulation”，确认主流客户端（Chrome、Safari、Firefox、Android）实际协商出的是你指定的套件
- 检查日志是否记录真实协议与套件：
$ssl_protocol和$ssl_cipher变量需在 HTTPS server 块中通过自定义log_format输出 - 命令行快速验证：
openssl s_client -connect example.com:443 -tls1_3或-tls1_2可分别测试协议支持情况
