必须开启ssl_prefer_server_ciphers on并配置严格套件顺序，优先TLS1.3 AEAD套件，再配TLS1.2 ECDHE+AEAD组合，禁用弱算法与旧协议，指定安全椭圆曲线，实测验证协商结果。
要在 Nginx 中真正启用国际标准的强加密套件，核心不是堆砌算法名称，而是控制 TLS 协商逻辑——让服务端按你设定的强度顺序主导选择，同时剔除所有已淘汰、不安全或缺乏前向保密的组合。
必须开启服务端套件优先权
Nginx 默认把加密套件选择权交给客户端，哪怕你配置了 AES-GCM，老旧客户端仍可能协商出 RSA-SHA 这类无前向保密、已被弃用的弱套件。因此第一步是强制收回控制权：
- 在 server 或 http 块中添加：
ssl_prefer_server_ciphers on; - 该指令默认为
off，不写等于未生效 - TLS 1.3 不受此影响（协议已固化套件），但必须保留，确保 TLS 1.2 安全
按国际标准排序 ssl_ciphers
套件列表从左到右即安全等级由高到低，Nginx 只取第一个客户端支持的。推荐顺序兼顾安全性与现代兼容性：
- 开头放 TLS 1.3 套件（Nginx 1.13+）：
TLS13-AES-256-GCM-SHA384:TLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-128-GCM-SHA256 - 接着是 TLS 1.2 的 ECDHE+AEAD 组合：
ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-CHACHA20-POLY1305 - 如需兼容 Android 4.4.2 或 Java 7u25，可在末尾用冒号追加：
:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-SHA，但绝不前置或混入 RSA 密钥交换套件 - 主动过滤已淘汰算法：
!RC4:!MD5:!SHA1:!DES:!3DES:!EXPORT:!aNULL:!eNULL
配套协议与密钥交换参数不可省略
再强的套件列表，若运行在不安全协议或弱密钥交换机制上，依然可能被降级攻击：
- 明确禁用 TLS 1.0 和 1.1：
ssl_protocols TLSv1.2 TLSv1.3; - 指定高效且抗侧信道的椭圆曲线：
ssl_ecdh_curve secp384r1:prime256v1;（优先 secp384r1，fallback prime256v1） - 启用会话缓存提升性能与一致性：
ssl_session_cache shared:SSL:10m; ssl_session_timeout 4h;
务必实测验证是否真正生效
语法检查通过（nginx -t）不代表安全达标，必须确认客户端实际协商结果：
- 使用 SSL Labs Server Test 查看 “Handshake Simulation”，观察 Chrome、Firefox、Safari 等主流客户端是否确实协商出
ECDHE-RSA-AES128-GCM-SHA256或类似 AEAD 套件 - 命令行快速验证（OpenSSL 1.1.1+）：
openssl s_client -connect yourdomain.com:443 -tls1_2 -cipher 'ALL:COMPLEMENTOFALL' 2>/dev/null | grep Cipher - 注意：部分客户端（如 Safari/iOS）在 TLS 1.3 下更依赖 OCSP Stapling，建议同步启用：
ssl_stapling on; ssl_stapling_verify on; ssl_trusted_certificate /path/to/fullchain.pem;
