如何配置 ssl_ciphers 兼容 TLS 1.3

<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 和对应套件名