要仅启用 TLSv1.2 和 TLSv1.3，须在每个 HTTPS server 块中显式配置 ssl_protocols TLSv1.2 TLSv1.3，确保 Nginx ≥ 1.13.0 且 OpenSSL ≥ 1.1.1，并搭配强加密套件与 HSTS、HTTP/2 等加固项。
要在 Nginx 中仅启用现代 TLS 协议版本（即只允许 TLSv1.2 和 TLSv1.3），关键不是“全局开关”，而是精准、逐个配置每个 HTTPS server 块，并配合加密套件与 OpenSSL 支持条件。漏掉任一环节，都可能让旧协议悄悄生效。
必须在每个 server 块中显式声明协议
ssl_protocols 指令只在 server { } 块内有效，写在 http 或 location 里完全无效。哪怕语法检查通过，实际连接时也不会起作用。
- ✅ 正确写法（放在 443 端口的 server 块里）：
ssl_protocols TLSv1.2 TLSv1.3; - ❌ 常见错误：
写成ssl_protocols TLSv1;（等价于 TLSv1.0）、ssl_protocols TLSv1.2+;（Nginx 不支持通配符）、或漏掉分号 - 多个域名、多个 conf 文件（如
sites-enabled/下）——每个启用 HTTPS 的虚拟主机都必须单独加这一行，缺一不可
确保底层支持 TLSv1.3
仅写 TLSv1.3 不代表它真能用。Nginx 必须满足两个硬性前提：
- Nginx 版本 ≥ 1.13.0（推荐 ≥ 1.18.0）
- 编译时链接的 OpenSSL 版本 ≥ 1.1.1（如 1.1.1w、3.0.x）
验证方式：nginx -V 2>&1 | grep -i openssl，输出中必须明确出现OpenSSL 1.1.1或更高 - Ubuntu/Debian 官方源的 nginx 包通常不带 OpenSSL 1.1.1，建议换用
nginx-full（22.04+）或自编译；RHEL/CentOS 8+ 一般默认支持，7 需启用 EPEL 并安装nginx-mod-http-ssl
同步配置强加密套件，防止降级或弱协商
只限制协议远远不够。TLSv1.2 允许大量已被淘汰的 cipher（如含 RC4、3DES、SHA1 的组合），攻击者仍可建立“看似合规但实际不安全”的连接。
- 推荐套件组合（兼顾 TLSv1.2 与 TLSv1.3）：
ssl_ciphers 'TLS13-AES-256-GCM-SHA384:TLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256'; - TLSv1.3 必须使用 RFC 8446 定义的三组专用套件（以
TLS13-开头），不能混入任何ECDHE-或AEAD-等 TLSv1.2 套件，否则协商可能失败 - TLSv1.3 场景下，
ssl_prefer_server_ciphers已失效，建议显式设为off；而 TLSv1.2 场景下建议设为on，但混合配置时统一设为on更稳妥（多数生产模板采用）
别忘了配套加固项
协议和套件是基础，还需几个关键配置共同构成现代 TLS 实践：
-
HTTP 强制跳转 HTTPS：在 80 端口 server 块中加
return 301 https://$host$request_uri; -
启用 HTTP/2：listen 行写成
listen 443 ssl http2;（需 OpenSSL 1.0.2+，现代环境基本满足） -
HSTS 头部：加
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always; - OCSP Stapling：提升证书状态验证效率，避免客户端直连 CA
