直接在启用 HTTPS 的 server 块中写入 ssl_protocols TLSv1.2 TLSv1.3;，就能严格禁用 TLS 1.0 和 TLS 1.1；该指令必须置于每个 listen 443 ssl 的 server 块内，不可放在 http 或 location 块中，且需配合强加密套件与实测验证。
直接在启用 HTTPS 的 server 块中写入 ssl_protocols TLSv1.2 TLSv1.3;，就能严格禁用 TLS 1.0 和 TLS 1.1。这不是增强项，而是当前安全合规的硬性门槛——PCI DSS、等保2.0、NIST SP 800-52r2 等标准均已明确淘汰这两个版本。
配置必须落在 server 块内
该指令在 http 块中虽能通过语法检查，但实际不生效；在 location 块中则完全无效。每个带 listen 443 ssl 的 server 都要单独配置，不能依赖继承或全局设置。
- 正确示例：
server {
listen 443 ssl;
server_name example.com;
ssl_certificate /path/to/cert.pem;
ssl_certificate_key /path/to/key.pem;
ssl_protocols TLSv1.2 TLSv1.3;
} - 多个域名或虚拟主机？每个
server块都得加这一行，漏一个就可能暴露旧协议
写法必须精准，禁止任何宽松表达
不允许出现旧版本名称，也不支持通配符或模糊写法。哪怕多写一个 TLSv1.1 或误用 TLSv1，都可能导致降级协商成功。
- ✅ 推荐写法：
ssl_protocols TLSv1.2 TLSv1.3; - ❌ 错误写法：
ssl_protocols all -TLSv1.0 -TLSv1.1;（Nginx 不识别这种 Apache 风格） - ❌ 错误写法：
ssl_protocols TLSv1.2+;（Nginx 无此语法） - ❌ 错误写法：
ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;（显式包含即允许）
仅禁协议远远不够，必须同步收紧加密套件
即使协议被限制为 TLS 1.2/1.3，若仍允许 AES128-SHA、RC4、3DES 等弱套件，攻击者仍可通过协商获取可破解连接。
- 指定强套件列表，例如：
ssl_ciphers "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384"; - 强制服务端优先：
ssl_prefer_server_ciphers on;，防止客户端绕过策略选弱算法 - 禁用所有含
MD5、SHA1、RC4、DES、3DES的套件
验证是否真正禁用成功
配置重载后，不能只靠 nginx -t 判断。必须实测确认旧协议已被拒绝：
- 测试 TLS 1.1 是否被拒：
openssl s_client -connect your-domain.com:443 -tls1_1 -servername your-domain.com
应返回握手失败或 “no protocols available” - 测试 TLS 1.2 是否可用：
openssl s_client -connect your-domain.com:443 -tls1_2 -servername your-domain.com
应成功完成握手并显示证书信息 - 用
nmap --script ssl-enum-ciphers -p 443 your-domain.com查看输出，确认无TLSv1.0或TLSv1.1区块 - 访问 SSL Labs Test，检查 “Protocol Support” 是否仅显示 TLS 1.2 和 TLS 1.3
