必须用 ssl_conf_command ciphersuites 指令单独配置 tls 1.3 原生套件（如 tls_aes_256_gcm_sha384），因 ssl_ciphers 对 tls 1.3 无效；需搭配 ssl_protocols tlsv1.2 tlsv1.3 和 ocsp stapling 等加固措施，确保安全生效。
直接在 Nginx 中为 TLS 1.3 单独配置原生加密套件，是提升前向保密性和连接速度的关键一步。TLS 1.3 已彻底移除静态 RSA、CBC 模式、SHA-1 等不安全机制，只保留 AEAD 类型套件（如 AES-GCM、ChaCha20-Poly1305），且强制启用前向保密。但要注意：它不复用 TLS 1.2 的套件列表，必须用专用指令显式指定。
必须用 ssl_conf_command 配置 TLS 1.3 套件
TLS 1.3 的加密套件无法通过 ssl_ciphers 控制——该指令仅影响 TLS 1.2 及更早版本。OpenSSL 1.1.1+ 引入了独立机制：
- 在 server 块中、ssl_certificate 和 ssl_certificate_key 之后添加：
ssl_conf_command Ciphersuites "TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256";- 顺序不影响协商结果，但建议把强度高、兼容性好的放在前面（如 AES-GCM 优先于 ChaCha20）
- 不能混入任何 TLS 1.2 套件（如 ECDHE-RSA-AES256-SHA），否则可能干扰握手或导致静默降级
配套启用 TLS 1.2+1.3 并禁用旧协议
单开 TLS 1.3 虽最安全，但会拒绝旧客户端；生产环境推荐双协议并行，同时确保旧协议不拖后腿：
- 显式声明：
ssl_protocols TLSv1.2 TLSv1.3;（不可省略 TLSv1.2，也不可写 TLSv1.1 或更低） - 搭配 TLS 1.2 安全套件（仅用于 TLS 1.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 off;—— TLS 1.3 协商逻辑已重构，关闭此选项更利于客户端选择最优组合
验证是否真正生效
不能只看浏览器地址栏锁图标，要确认 TLS 1.3 套件在真实连接中被选用：
- 在日志中加入
$ssl_protocol和$ssl_ciphers，访问后检查日志是否出现TLSv1.3及对应套件名（如TLS_AES_256_GCM_SHA384） - 用 OpenSSL 直连测试：
openssl s_client -connect your-domain.com:443 -tls1_3 -cipher TLS_AES_256_GCM_SHA384 -servername your-domain.com，观察输出中Protocol是否为TLSv1.3，Cipher是否匹配 - 抓包过滤
tls.handshake.type == 1 && tls.handshake.version == 0x0304，确认 ServerHello 中协议版本字段正确
别漏掉 OCSP Stapling 和 HSTS
TLS 1.3 下证书状态验证更频繁，未启用 stapling 可能引发 Safari/iOS 连接延迟或警告：
- 启用 stapling：
ssl_stapling on; ssl_stapling_verify on; - 指定可信 CA 链：
ssl_trusted_certificate /path/to/fullchain.pem; - 加 HSTS 头防降级：
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
