必须在每个启用 HTTPS 的 server 块中显式配置 ssl_protocols TLSv1.2 TLSv1.3;，不能仅放在 http 块；否则未声明的 server 会回退至不安全默认值，且空格、分号缺失或 OpenSSL 版本低于 1.1.1 均导致失效。
ssl_protocols 配置必须写在 server 块里，不能只放在 http 块
很多人把 ssl_protocols TLSv1.2 TLSv1.3; 放在 http 块顶层，以为全局生效——实际无效。Nginx 的 SSL 协议协商发生在连接建立阶段，而该指令仅对启用 HTTPS 的 server 块内有效。若多个 server 共享同一 IP:443，但其中某个没显式配置 ssl_protocols，它就会回退到编译默认值（可能包含 TLSv1.0），导致策略被绕过。
实操建议：
- 每个启用 HTTPS 的
server块都必须单独写一遍ssl_protocols TLSv1.2 TLSv1.3; - 不要用
ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;再加注释来“兼容旧设备”——注释不阻止解析，Nginx 会直接报错退出 - 空格和分号缺一不可：
ssl_protocols TLSv1.2 TLSv1.3 ;（末尾多空格）或ssl_protocols TLSv1.2 TLSv1.3（无分号）都会让nginx -t失败
验证 TLSv1.0/TLSv1.1 是否真被禁用，别信配置文件写了就算
改完配置 reload 后，nginx -t 成功 ≠ 协议已禁用。常见错误是：CDN 或反向代理层（如 Cloudflare、ALB）仍透传旧协议；或者 Nginx 实际监听的是另一个配置文件（比如 sites-enabled/ 下软链指向了未更新的副本）。
实操建议：
- 用
openssl s_client -connect example.com:443 -tls1测试：应返回SSL routines::wrong version number或直接断连 - 用
nmap --script ssl-enum-ciphers -p 443 example.com查看完整支持列表，确认输出中彻底没有TLSv1.0和TLSv1.1区块 - 检查是否用了 SNI：如果域名共用 IP 且有多个 HTTPS
server，确保测试时指定了正确-servername，否则可能命中默认 server 块
ssl_protocols 和 ssl_ciphers 必须配合使用，单禁协议不等于安全
只设 ssl_protocols TLSv1.2 TLSv1.3; 而不限制套件，客户端仍可能协商出弱算法，比如 ECDHE-RSA-AES128-SHA（SHA1）或 DHE-RSA-AES256-SHA（CBC 模式 + SHA1）。这些在 TLSv1.2 下依然合法，但已被标记为不安全。
实操建议：
- 必须同步配置强套件，例如：
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;不能省——关掉它，客户端可无视服务器套件顺序强行选弱项 - 避免出现
RC4、MD5、SHA1、DES、3DES字样，哪怕只是注释里写也不行（某些旧版 Nginx 会误解析）
OpenSSL 版本不匹配会导致 TLSv1.3 不可用，即使配置正确
Nginx 编译时链接的 OpenSSL 版本决定了它能否真正启用 TLSv1.3。OpenSSL 1.1.1 是最低要求，而很多系统（如 CentOS 7 默认 OpenSSL 1.0.2）即使你写了 TLSv1.3，Nginx 启动时也会静默忽略，降级到 TLSv1.2。
实操建议：
- 运行
nginx -V 2>&1 | grep -o 'OpenSSL [0-9.]\+'确认实际链接版本 - 若版本低于 1.1.1，要么升级系统 OpenSSL（高风险），要么重编译 Nginx 并指定
--with-openssl=指向新版源码路径 - 注意：Ubuntu 20.04+、CentOS 8+、Alpine 3.12+ 等较新发行版才默认带 OpenSSL 1.1.1+
