必须在每个启用 HTTPS 的 server 块中配置 ssl_protocols TLSv1.2 TLSv1.3; 才能强制禁用 SSLv2、SSLv3、TLSv1.0 和 TLSv1.1；该指令仅在 server 块生效，需配合强加密套件及实测验证。
直接在每个启用 HTTPS 的 server 块中写入 ssl_protocols TLSv1.2 TLSv1.3;，就能让 Nginx 拒绝所有使用 TLS 1.0、TLS 1.1、SSLv2 和 SSLv3 的连接。这不是“建议”，而是当前安全基线的强制要求——Nginx 不会协商未列出的协议版本，不支持的客户端握手会直接失败。
必须放在 server 块内，且每个站点单独配
该指令只在启用 ssl 的 server 块中生效，写在 http 或 location 块里完全无效（即使 nginx -t 通过）。
- 每个监听
443 ssl的server都要显式添加这一行 - 不能依赖父级配置继承，多个域名或虚拟主机需分别配置
- 示例写法（精准、无空格错误、无分号遗漏）：
ssl_protocols TLSv1.2 TLSv1.3;
禁用后必须验证是否真正生效
光改配置不够，得实测确认旧协议已被切断：
- 用 OpenSSL 模拟 TLS 1.1 握手：
openssl s_client -connect example.com:443 -tls1_1 -servername example.com
应返回handshake failure，而非证书信息 - 测试 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 Test，检查 “Protocol Support” 栏仅显示 TLS 1.2 和 TLS 1.3
配套收紧加密套件，防止绕过
只限制协议还不够，弱加密套件可能让攻击者绕过前向保密或触发降级风险：
- 禁用含 RC4、MD5、SHA1、DES、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;
若需兼容旧设备，不要全局妥协
Android 4.x、iOS 9 等老系统无法直连 TLS 1.2+，但不应因此在主站放开 TLS 1.0/1.1：
- 为旧设备单独设子域名（如
legacy.example.com），配独立server块 - 该块中可放宽为：
ssl_protocols TLSv1.1 TLSv1.2;（iOS 9 最低要求 TLS 1.2，但部分早期补丁不全，保留 TLSv1.1 更稳妥） - 同时调整后端代理配置（如 Java 微服务），避免 Nginx 与上游握手失败：
proxy_ssl_protocols TLSv1.1;+proxy_ssl_ciphers "AES128-SHA";+proxy_ssl_server_name on;
