TLS 1.3 握手延迟优化需四管齐下：启用TLS 1.3并限定原生套件与X25519优先曲线；全开启双路会话复用（共享缓存+轮换ticket）；安全启用0-RTT（early_data+后端识别+幂等校验）；稳启OCSP Stapling避免隐性阻塞。
把 TLS 1.3 握手延迟压到极致，核心是让 1-RTT 成为常态、0-RTT 成为可能，并消除所有隐性阻塞。这不是调几个参数就能成的事，得从协议启用、会话复用、客户端状态、后端协同四方面一起抓。
必须启用 TLS 1.3 并锁定高效协商路径
只写 ssl_protocols TLSv1.3 不够，必须搭配精准的密码套件和算法约束：
- 只用 TLS 1.3 原生套件：
ssl_ciphers 'TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256'，彻底剔除任何 TLS 1.2 套件（如含SHA256但不含TLS_前缀的） - 强制曲线优先级：
ssl_conf_command Curves X25519:secp256r1，避免客户端尝试不支持的曲线导致重协商 - 启用 ALPN 并绑定 HTTP/2：
listen 443 ssl http2;，让应用层协议在 TLS 握手阶段就确定，省去后续升级开销
双路会话复用必须全开启且长效有效
0-RTT 的前提是客户端有可用 PSK，而 PSK 来自上一次成功握手的缓存或票据。单靠一种机制容易失效：
- 服务端共享缓存要设在
http块顶层：ssl_session_cache shared:SSL:10m;，超时至少设为ssl_session_timeout 4h;（移动端活跃周期长，5 分钟太短） - Session Tickets 必须开启并轮换密钥：
ssl_session_tickets on;+ssl_session_ticket_key /etc/nginx/ticket.key;（建议每周轮换） - 若 Nginx 后端也走 HTTPS（如微服务），加上
proxy_ssl_session_reuse on;，避免二级握手拖慢整体链路
0-RTT 要能触发，更要安全落地
配置了 ssl_early_data on; 只是第一步，真正让 0-RTT 生效还依赖客户端行为和后端配合：
- 该指令必须放在具体
server块内，全局配置无效 - 浏览器需已访问过该域名、未清缓存、未启隐私模式；CDN 或中间代理也必须透传
early_data扩展，否则退化为 1-RTT - 后端必须识别
Early-Data: 1请求头：proxy_set_header Early-Data $ssl_early_data; - 应用层对非幂等请求（如 POST 登录、DELETE）应返回
425 Too Early，强制降级为 1-RTT；GET 等幂等请求可直接响应
绕过证书验证阻塞：OCSP Stapling 必须稳启
即使用了 TLS 1.3，如果 OCSP 查询超时或失败，客户端仍会卡住等待——这会让 1-RTT 变成“1-RTT+OCSP-RTT”：
- 开启 stapling：
ssl_stapling on;+ssl_stapling_verify on; - 指定可信 CA 包：
ssl_trusted_certificate /etc/nginx/fullchain.pem;（不能只用站点证书） - 确保系统时间准确、DNS 解析稳定（stapling 依赖上游 OCSP 响应器可达）
