<p>配置 sslciphers 兼容 TLS 1.3 的核心是仅使用 RFC 8446 定义的五种原生套件，严格限定为 TLS13- 或 TLS 前缀（如 TLS13-AES-256-GCM-SHA384），禁用所有含 ECDHE、RSA 等 TLS 1.2 套件，并配合 ssl_protocols TLSv1.2 TLSv1.3 和 ssl_prefer_server_ciphers off 才能确保协商正确、避免降级或失败。</p>
配置 ssl_ciphers 兼容 TLS 1.3，核心是只用 TLS 1.3 原生套件，且必须与 ssl_protocols TLSv1.3（或 TLSv1.2 TLSv1.3）严格匹配。混入任何 TLS 1.2 套件会导致协商异常、静默降级甚至连接失败。
只用 RFC 8446 定义的五种标准套件
TLS 1.3 协议本身只定义了 5 种密钥交换+加密组合，Nginx 中只能使用带 TLS13- 或 TLS_ 前缀的套件名。常见有效写法如下：
-
TLS13-AES-256-GCM-SHA384（推荐优先级最高，兼顾安全与兼容性） -
TLS13-CHACHA20-POLY1305-SHA256（对移动弱网更友好） -
TLS13-AES-128-GCM-SHA256（性能开销更低，适合高并发场景）
注意：EECDH、ECDHE-RSA、AES256-GCM-SHA384 等全部属于 TLS 1.2，哪怕名字里有 GCM 或 SHA384，也绝不能出现在 TLS 1.3 专用配置中。
避免常见命名陷阱
很多配置误把 TLS 1.2 套件当 TLS 1.3 用，关键看前缀是否合规：
- ✅ 正确：以
TLS13-或TLS_开头（如TLS13-AES-128-GCM-SHA256、TLS_AES_256_GCM_SHA384） - ❌ 错误：含
ECDHE、EECDH、RSA、AES256-SHA、SHA256（无 TLS_ 前缀）等字样 - ⚠️ 警惕：Certbot 自动生成的配置常保留旧套件，需人工替换，不能直接复用
配合协议与服务端策略调整
ssl_ciphers 单独生效不了，必须同步设置以下指令：
-
ssl_protocols TLSv1.2 TLSv1.3;（双协议共存更稳妥）或ssl_protocols TLSv1.3;（纯 TLS 1.3 场景） -
ssl_prefer_server_ciphers off;（TLS 1.3 下该指令已失效，显式关闭更清晰） - 删掉
ssl_ecdh_curve行（TLS 1.3 自动协商 X25519/P-256，硬指定反而限制兼容性）
如果启用双协议（TLSv1.2 + TLSv1.3），ssl_ciphers 仍应只写 TLS 1.3 套件——Nginx 会自动忽略不匹配的部分，不会影响 TLS 1.2 握手（前提是另有独立 TLS 1.2 套件配置）。
验证是否真正生效
配置后务必实测，不能只看语法通过：
- 用
curl -I --tlsv1.3 https://your-domain.com检查是否成功建立连接 - 在浏览器开发者工具 → Security 标签页查看实际协商协议和套件
- 抓包分析 TLS handshake 的
supported_versions和selected_version字段 - Nginx 日志加
$ssl_protocol $ssl_cipher变量，确认日志中出现TLSv1.3和对应套件名
