直接写 ssl_protocols TLSv1.2 TLSv1.3; 并置于每个启用 HTTPS 的 server 块内，即可真正启用现代协议、禁用 SSLv2/3、TLSv1.0/1.1 等已废弃且存在 POODLE、BEAST 等漏洞的不安全版本；该配置是当前生产环境的安全底线，需配合强加密套件与实测验证。
直接写 ssl_protocols TLSv1.2 TLSv1.3;，放在每个启用 HTTPS 的 server 块内，就能真正启用现代协议、禁用所有已知不安全版本。这不是可选优化，而是当前生产环境的安全底线。
必须禁用的协议版本
SSLv2、SSLv3、TLSv1.0 和 TLSv1.1 已被 IETF 正式废弃（RFC 8996），存在可利用漏洞：
- SSLv3：POODLE 攻击可解密 HTTPS 流量
- TLSv1.0/1.1：BEAST、CRIME、Lucky13 等攻击成熟，且不支持前向保密（PFS）
- 主流浏览器（Chrome 70+、Firefox 63+、Safari 12.1+、Edge 79+）默认禁用这些协议，保留它们只增加攻击面，不带来实际兼容收益
推荐启用的协议组合
当前唯一合理配置是同时启用 TLSv1.2 和 TLSv1.3：
- TLSv1.2：覆盖 Windows 7 IE11、Android 4.4+、iOS 9+ 等仍需支持的旧设备，配强加密套件（如 ECDHE+AES-GCM）即满足安全要求
- TLSv1.3：握手更快（1-RTT）、移除 RSA 密钥交换和 CBC 模式等高危组件、强制前向保密、抗降级攻击；需 OpenSSL 1.1.1+ 和 Nginx 1.13.0+
- 不要写成
TLsv1、TLSv1.2+或混入TLSv1.1——Nginx 会静默忽略错误写法或拉低整体安全评级
配置位置与生效逻辑
ssl_protocols 只在 http 或 server 块中有效，location 块中设置无效：
- 放在
http块：统一约束所有 HTTPS server，适合多域名共用策略，子server会继承 - 放在
server块：精细化控制（例如对外网站保留 TLSv1.2，内网 API 仅开 TLSv1.3） - 注意：Nginx 不会自动补全你没写的协议——即使底层支持 TLSv1.3，若配置里没显式写出，它就不会启用
验证是否真正生效
重启 Nginx 后，不能只看语法是否通过，必须实测：
- 测试 TLSv1.1 是否被拒：
openssl s_client -connect example.com:443 -tls1_1 -servername example.com→ 应返回握手失败 - 测试 TLSv1.2/TLSv1.3 是否可用：
openssl s_client -connect example.com:443 -tls1_2和-tls1_3→ 应成功并显示对应协议版本 - 用 SSL Labs Server Test 扫描域名，确认 “Protocol Support” 栏仅显示 TLS 1.2 和 TLS 1.3，且评级为 A 或 A+
