必须在每个启用 HTTPS 的 server 块内配置 ssl_protocols TLSv1.2 TLSv1.3;，才能强制禁用 TLS 1.0/1.1 及更早不安全协议；该指令在 http 或 location 块中无效，且需配合强加密套件与实测验证。
直接在每个启用 HTTPS 的 server 块内写入 ssl_protocols TLSv1.2 TLSv1.3;，就能强制淘汰 TLS 1.0、TLS 1.1 及更早所有不安全版本。这不是可选项，而是当前安全基线的硬性要求。
必须放在 server 块里才有效
Nginx 不支持在 http 或 location 块中配置 ssl_protocols。即使写进 http 块，语法检查不会报错，但实际完全不生效——客户端仍可能协商到 TLS 1.1 或更低版本。
- 正确位置：每个带
listen 443 ssl的server { }块内部 - 多个域名或虚拟主机？每个
server都要单独加这一行，不能依赖继承 - 示例写法：
ssl_protocols TLSv1.2 TLSv1.3;（注意大小写、空格、分号，不能写成TLSv1.2+或TLSv12）
只留两个版本，禁用全部旧协议
明确列出 TLSv1.2 和 TLSv1.3，等同于主动排除 SSLv2、SSLv3、TLSv1、TLSv1.1 —— 这些协议存在 POODLE、BEAST 等已知漏洞，且违反 PCI DSS、等保2.0 等合规要求。
- ❌ 错误写法：
ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;（多一个旧版本就可能降级） - ✅ 正确效果：不支持 TLS 1.1 的客户端（如 IE11、Android 7–9）将无法建立连接，这是预期行为
- 若需临时兼容老旧系统，应单独评估风险，而非放宽全站策略
配套必须同步收紧加密套件
光限制协议不够。客户端仍可能用弱算法建立 TLS 1.2 连接，导致前向保密缺失或易受降级攻击。
- 指定强密钥交换与认证方式：
ssl_ciphers "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384"; - 禁用含 RC4、MD5、SHA1、DES、3DES 的所有套件
- 启用服务端优先：
ssl_prefer_server_ciphers on;（防止客户端绕过服务器策略选弱算法）
验证是否真正生效
改完配置后，必须实测，不能只看 nginx -t 通过。
- 测试 TLS 1.1 是否被拒：
openssl s_client -connect example.com:443 -tls1_1 -servername example.com→ 应返回握手失败 - 测试 TLS 1.2 是否可用：
openssl s_client -connect example.com:443 -tls1_2 -servername example.com→ 应成功并显示Protocol : TLSv1.2 - 用
nmap --script ssl-enum-ciphers -p 443 example.com查看输出，确认无 TLSv1.0/TLSv1.1 区块 - 推荐辅助工具：SSL Labs 免费扫描，查看 “Protocol Support” 栏是否仅标 TLS 1.2 和 TLS 1.3，评级达 A 或 A+
