必须在每个 HTTPS 的 server 块中显式配置 ssl_protocols TLSv1.2 TLSv1.3; 才能精准禁用 SSLv2/SSLv3/TLSv1.0/TLSv1.1；该指令在 http 或 location 块中无效，且须搭配强加密套件、ssl_prefer_server_ciphers on 及实测验证。
直接在每个 HTTPS 的 server 块中写明 ssl_protocols TLSv1.2 TLSv1.3;，这是启用现代 TLS 并提升安全性的核心动作。Nginx 不会默认禁用老旧协议，也不支持“全局继承”，漏配一个站点，那个域名就可能仍在使用 TLSv1.1 或更低版本。
必须逐个 server 块配置 ssl_protocols
Nginx 的 ssl_protocols 指令只在 server { } 块内生效，写在 http 或 location 里完全无效——即使 nginx -t 通过，实际连接仍可能协商出不安全的 TLSv1.0 或 TLSv1.1。
- 所有监听 443 端口、启用 SSL 的虚拟主机（包括不同域名、不同 conf 文件）都需单独添加这一行
- 不能依赖“父级配置”，Nginx 不提供该指令的继承机制
- 常见错误：写成
ssl_protocols TLSv1.1 TLSv1.2 TLSv1.3;（含 TLSv1.1 违反 RFC 8996）或ssl_protocols TLSv1;（等价于 TLSv1.0）
搭配强加密套件与协商控制
仅限制协议版本远远不够。TLSv1.2 允许大量弱 cipher（如 RC4、3DES、SHA1），攻击者仍可建立看似合规、实则不安全的连接。
- 推荐 cipher 配置（兼容 TLSv1.2 和 TLSv1.3）：
ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384'; - 对 TLSv1.2：保持
ssl_prefer_server_ciphers on;更稳妥；TLSv1.3 下该指令已失效，设为off更清晰 - TLSv1.3 需额外指定独立套件集：
ssl_conf_command Ciphersuites TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256;（必须放在ssl_certificate_key之后）
验证是否真正生效
配置后务必实测，不能仅靠 nginx -t 或 reload 成功就认为完成。
- 用
openssl s_client -connect example.com:443 -tls1_1测试是否拒绝 TLSv1.1 - 用浏览器开发者工具的“Security”标签页查看实际协商版本
- 借助 SSL Labs Test 获取完整评分与协议/套件明细
- 注意 Certbot 自动生成的配置通常只加了
ssl_protocols，但ssl_ciphers仍沿用旧值，必须手动替换
启用 TLSv1.2 与 TLSv1.3 共存是当前最平衡的做法：既保障 Android 4.4、IE 11 等老客户端可连，又让现代浏览器自动选用更安全、更快的 TLSv1.3。关键不在“能不能开”，而在协议、套件、协商三者协同到位。
