最优写法是ssl_protocols TLSv1.2 TLSv1.3;，因单独配置TLSv1.3会拒绝Windows 7+IE11、Android 4.x等不支持客户端导致访问中断，而TLSv1.2仍具广泛兼容性与足够安全性，二者共存可自动协商最优协议；混用旧协议或错误cipher套件将降低安全等级或引发协商失败。
在 Nginx 中启用 TLS 1.3，ssl_protocols 的最优写法是：ssl_protocols TLSv1.2 TLSv1.3;
为什么不能只写 TLSv1.3
单独配置 ssl_protocols TLSv1.3; 会强制拒绝所有不支持 TLS 1.3 的客户端，包括：
- Windows 7 + IE 11（原生不支持）
- Android 4.4–6.0 系统的默认浏览器
- 部分嵌入式设备、IoT 终端、旧版 Java 客户端
- 某些企业防火墙或中间代理
这会导致真实用户访问失败，而非“降级”，且无兼容提示。Nginx 不会自动兜底，连接直接中断。
为什么必须同时保留 TLSv1.2
TLSv1.2 仍是当前最广泛兼容、安全性达标的协议基础：
- 所有主流现代浏览器（Chrome/Firefox/Safari/Edge）均完整支持
- 只要搭配 ECDHE+AEAD 套件（如 AES-GCM），即具备前向保密和抗 CBC 攻击能力
- 与 TLSv1.3 共存时，Nginx 能根据客户端能力自动协商最优协议，互不干扰
禁用 TLSv1.2 既无安全收益，反而大幅收缩可服务范围。
哪些写法是错误或危险的
以下配置看似合理，实则无效或降低安全性：
-
ssl_protocols TLSv1.3 TLSv1.2;—— 顺序无关，但建议按版本升序书写，更清晰 -
ssl_protocols TLSv1.2+;—— Nginx 不识别该语法，配置校验失败 -
ssl_protocols TLSv1.1 TLSv1.2 TLSv1.3;—— 启用 TLSv1.1 会使 SSL Labs 测评直接降为 B 级甚至更低，违反 RFC 8996 强制弃用要求 -
ssl_protocols SSLv3 TLSv1.2 TLSv1.3;—— 启用 SSLv3 极度危险，POODLE 攻击可被利用
配套 ssl_ciphers 必须严格匹配
仅设对 ssl_protocols 不足以让 TLS 1.3 生效。必须同步使用纯 TLS 1.3 原生套件：
- 正确示例：
ssl_ciphers TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256; - 错误做法：混入
ECDHE-RSA-AES256-GCM-SHA384等 TLS 1.2 套件——会导致协商失败或静默回退到 TLS 1.2 - 务必添加：
ssl_prefer_server_ciphers off;（TLS 1.3 下该指令逻辑已重构，设为 on 反而可能干扰）
