必须在每个启用 https 的 server 块中配置 ssl_protocols tlsv1.2 tlsv1.3; 才能精准禁用 sslv2/sslv3/tlsv1.0/tlsv1.1，该指令在 http 或 location 块中无效，且须配合强加密套件、ssl_prefer_server_ciphers on 及实测验证。

只启用 TLSv1.2 和 TLSv1.3 是当前最稳妥的安全实践。Nginx 不会默认禁用老旧协议，必须显式配置，且位置、写法、配套设置缺一不可。

必须放在每个 server 块里

ssl_protocols 指令只在 server { } 块中生效，写在 http 或 location 里完全无效——即使 nginx -t 通过，实际连接仍可能协商出 TLSv1.0 或 TLSv1.1。

• 所有监听 443 端口并启用 SSL 的虚拟主机（包括不同域名、不同 conf 文件）都得单独加这一行
• 漏配一个站点，那个域名就仍在使用不安全协议
• 不能依赖“全局配置”，Nginx 不支持该指令的继承机制

正确写法与常见错误

语法极其严格，大小写、空格、分号一个都不能错。

linux-sysadmin

Linux系统管理专家，覆盖12大模块：用户权限、SSH、存储、网络、systemd、防火墙、日志监控、备份恢复、TLS证书、Ansible、容器、IaC。提供配置、验证、加固、监控、备份、自动化、故障排查、回滚闭环。关键词：useradd、sudo、sshd_config、chmod、SEL...

下载

• ✅ 正确：ssl_protocols TLSv1.2 TLSv1.3;
• ❌ 错误：ssl_protocols TLSv1.1 TLSv1.2 TLSv1.3;（含 TLSv1.1 就违反 RFC 8996）
• ❌ 错误：ssl_protocols TLSv1 TLSv1.2 TLSv1.3;（TLSv1 是 TLSv1.0 别名）
• ❌ 错误：ssl_protocols TLSv1.2+;（Nginx 不识别通配符语法）
• ❌ 错误：ssl_protocols TLSv1.2 TLSv1.3（漏掉分号，重载失败）

必须搭配强加密套件和协商控制

仅限制协议版本远远不够。TLSv1.2 允许大量弱 cipher（如含 RC4、3DES、SHA1），攻击者仍可建立看似“合规”实则不安全的连接。

• 推荐 ssl_ciphers（兼顾 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';
• 必须开启服务端优先：ssl_prefer_server_ciphers on;（对 TLSv1.3 可设为 off，但保持 on 更兼容）
• 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 只检查语法，不验证实际行为。改完必须手动测试是否真正生效。

• 测 TLSv1.3 是否可用：
  openssl s_client -connect example.com:443 -tls1_3 -servername example.com 2>/dev/null | grep "Protocol" → 应输出 Protocol : TLSv1.3
• 测 TLSv1.1 是否被拒：
  openssl s_client -connect example.com:443 -tls1_1 -servername example.com → 应返回 handshake failure
• 用在线工具如 SSL Labs 或 ssllabs.com 检查评级，目标应为 A+，且无 TLSv1.0/TLSv1.1 提示