必须在每个启用 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;，就能精准只允许这两个版本，其他所有协议（SSLv2/SSLv3/TLSv1.0/TLSv1.1）均被彻底禁用。
必须放在 server 块里，不能写在 http 或 location 中
这个指令只在 server { } 块内生效。哪怕你把它加到 http 块开头，语法检查能通过，实际连接时也完全不起作用。Nginx 不支持 SSL 协议设置的继承机制。
- 每个监听 443 端口并启用 SSL 的虚拟主机都得单独加这一行
- 多个域名、多个 conf 文件（如 sites-enabled/ 下）——漏改一个，那个站点就仍在使用不安全协议
- 别依赖“全局配置”，实测会发现漏洞依然存在
写法要严格，一个字符都不能错
大小写、空格、分号缺一不可。常见错误包括：
-
ssl_protocols TLSv1 TLSv1.2 TLSv1.3; ——
TLSv1是 TLSv1.0 的别名，等于主动打开高危漏洞 - ssl_protocols TLSv1.2+; —— Nginx 不支持通配符，该写法无效
- ssl_protocols TLSv1.2 TLSv1.3 —— 漏掉分号，重载时直接报错失败
- ✅ 正确写法：ssl_protocols TLSv1.2 TLSv1.3;
光设协议不够，还得锁死加密套件
TLSv1.2 允许大量弱 cipher，比如含 RC4、3DES、SHA1 的组合。仅限制协议，攻击者仍可能建立看似“TLSv1.2”但实际不安全的连接。
- 必须同步配置强套件，例如：
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'; - 启用服务端优先：ssl_prefer_server_ciphers on;，防止客户端绕过策略选弱算法
- TLSv1.3 还需额外配置：ssl_conf_command Ciphersuites TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256;（注意该行必须放在
ssl_certificate和ssl_certificate_key之后）
改完必须实测，nginx -t 不管用
配置重载后，用 openssl 手动验证是否真正生效：
- 测试 TLSv1.1 是否被拒：
openssl s_client -connect example.com:443 -tls1_1 -servername example.com
应返回handshake failure或连接重置 - 测试 TLSv1.2 是否可用：
openssl s_client -connect example.com:443 -tls1_2 -servername example.com
应成功握手，并在输出中看到Protocol : TLSv1.2 - 推荐配合 SSL Labs 的在线扫描工具做二次确认，覆盖更多客户端模拟场景
