HTTPS 连不上为什么慢
很多站点从 HTTP 切到 HTTPS 后，总感觉首次访问变慢。原因往往不在带宽（指单位时间内可传输的数据量）或磁盘，而在握手：TLS（Transport Layer Security，安全传输层协议）在真正传输数据前，需要先完成多轮密钥协商。旧版 TLS 一次握手要来回两轮半，在跨国网络上，每次往返都要吃掉几十到上百毫秒。这篇指南教你理解并配置 TLS 1.3 的 0-RTT（Zero Round Trip Time，零往返时间）机制，从协议层面把重复访问的握手成本压到接近零。
值得说明的是，TLS 1.3 于 2018 年由 IETF（国际互联网工程任务组）正式发布，如今主流浏览器、Nginx、Caddy 以及各大云厂商均已原生支持。它把握手从两轮往返精简到一轮，默认握手延迟显著下降，是成本最低也最稳妥的 HTTPS 提速手段之一。
在动手之前，一个前提很重要：0-RTT 在”首次访问”时并不生效，它服务的是一次握手之后的重连场景。对于以重复访客为主的站点，收益才会明显；而对几乎全是新访客的站点，重点应放在常规的一轮握手优化上。下文会同时覆盖这两种情况。
TLS 1.3 握手为何更快
要理解 0-RTT，先要看清 TLS 1.3 的握手流程。旧版 TLS 1.2 握手需要 2 轮往返；TLS 1.3 把密钥协商移到握手首轮，客户端发送第一条消息时就能携带自己支持的参数，服务端返回时即完成交换，整体压到 1 轮往返（1-RTT）。
以全球范围的平均网络环境衡量，一次跨洋往返约 150～250 毫秒（示例典型区间），两轮 vs 一轮的差距通常在 150～300 毫秒之间。对依赖搜索引擎排名和用户体验的站点，这个数字足以拉开加载感知的差距。TLS 1.3 的第二个优势是移除了若干过时且不安全的算法套件，默认配置即更安全，无需额外调优即可满足多数合规要求。
如果你正在排查站点整体速度而不仅是握手，可参考我们整理的 Nginx 限流与防护配置——限流、缓存与 TLS 优化常常需要综合设计，才能把首屏时间真正压下来。对需要把握手优化真正落地到生产环境的场景，Hostease 的服务器方案提供了完整的 root 权限与可控的 Nginx/Caddy 配置空间。
确认服务器是否已启用 TLS 1.3
在配置 0-RTT 之前，先确认 Web 服务器确实跑在 TLS 1.3 上。以命令行方式快速探测：
openssl s_client -connect yourdomain.com:443 -tls1_3 -servername yourdomain.com < /dev/null 2>&1 | head -20 openssl s_client -connect yourdomain.com:443 -brief < /dev/null 2>&1 | grep -i protocol
第二条命令输出里出现 TLSv1.3，说明服务器已支持并协商到 TLS 1.3。若显示的是 TLSv1.2，需要升级 OpenSSL 并确认 Web 服务器开启了 TLS 1.3。以 Nginx 为例，其 ssl_protocols 指令需要包含 TLSv1.3：
ssl_protocols TLSv1.2 TLSv1.3; ssl_conf_command Ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384;
改完执行语法检查并重载配置：
nginx -t systemctl reload nginx
证书配置若存在问题，HTTPS 握手会在更早阶段失败，此类问题可参考 Certbot SSL（Secure Sockets Layer，安全套接层）证书排障 定位，先保证证书合法、链完整，再谈提速。
启用 0-RTT 会话恢复
TLS 1.3 提供会话恢复机制，让已经完成一次握手的客户端，在之后的重连中携带一段加密的会话票据（session ticket），由服务端验证后直接进入数据阶段。0-RTT 进一步允许客户端在第一条加密消息里就附带应用数据，从而做到”零往返”建立连接。
在 Nginx 中，开启会话恢复相关的指令如下：
ssl_session_cache shared:SSL:10m; ssl_session_timeout 1d; ssl_early_data on;
ssl_early_data on 是开启 0-RTT（即 early data）的关键开关；它要求客户端在握手时也启用 TLS 1.3 Early Data，浏览器端无需用户干预，多数现代浏览器默认支持。ssl_session_cache 负责在服务端缓存会话状态，ssl_session_timeout 控制会话有效时长，示例取值 10MB 缓存、1 天有效，可按业务规模调整。
在 Caddy 中，0-RTT 默认即通过 HTTP/3 与会话恢复能力可用，通常无需显式配置即可享受重连加速。
启用后可用 curl 验证 early data 是否命中：
curl -s -o /dev/null -w "%{time_connect} %{time_starttransfer}\n" https://yourdomain.com/
curl -s -o /dev/null -w "%{time_connect} %{time_starttransfer}\n" -H "Early-Data: 1" https://yourdomain.com/
对比两条命令的 time_starttransfer，第二次通常比首次更快，差值接近一个往返时延，说明 0-RTT 会话恢复已生效。
0-RTT 的安全边界与取舍
0-RTT 把速度提升到极致，但需要理解一个安全代价：early data 在拿到服务端完整确认前，可能遭遇重放攻击。也就是说，攻击者可以截获一段带 early data 的请求并原样重放，服务端在验证票据时无法立即分辨这是否是同一请求。
针对这个特性，业界普遍建议：0-RTT 适合幂等的读请求，例如拉取页面、静态资源、接口查询；不适合直接执行支付、下单、改密等非幂等写操作。如果你的业务包含大量写请求，可以在应用层对 early data 请求做二次校验，或干脆关闭 0-RTT，仅保留会话复用来换取 1-RTT 的安全。
若你的站点同时承载高并发写负载，数据库层面的稳定性同样关键，可参考 Redis 持久化与恢复机制。0-RTT 只优化 TLS 这一层，后端服务的抖动依然会体现在耗时上。
监控与整体提速建议
握手提速只是 HTTPS 性能的一个环节。启用 0-RTT 后，建议把”握手耗时”和”重连命中率”纳入监控，观察会话恢复是否真的被客户端利用。可以结合 Grafana 服务器监控部署 建立可视化大盘，把 TLS 耗时、首字节时间、证书到期时间放在同一视图，便于快速定位瓶颈。
此外，几项配套优化值得一并考虑：开启 HTTP/2、HTTP/3，减少往返；对静态资源设置合理缓存；将证书部署为 ECDSA 以降低握手计算开销。这些措施与 0-RTT 叠加，能把跨国访问的整体延迟压到较低水平。
如果发现站点同时存在后端查询慢、连接排队等问题，可结合 MySQL 慢查询定位 与 Kafka 消费延迟排查 的思路，从数据层到缓存层逐段确认耗时来源，避免在错误的环节反复优化。
总结与行动建议
TLS 1.3 与 0-RTT 是目前性价比很高的 HTTPS 提速组合：TLS 1.3 把默认握手从两轮压到一轮，0-RTT 又让重连几乎零往返。先确认服务器已跑在 TLS 1.3 上，再开启会话缓存与 ssl_early_data，就能在多数现代浏览器下获得可感知的加速。
建议你先在测试环境验证 openssl s_client 与 curl 的对比结果，确认 early data 生效后再上生产。同时务必评估业务是否为幂等读场景，只有读多写少才适合开启 0-RTT；写操作较多的站点应保守只保留会话复用。若你需要一台拥有完整 root 权限、可自由调优 TLS 与各类网络参数的 独立服务器，或希望以较低成本开始并逐步扩展，VPS（虚拟专用服务器，即在一台物理机上隔离出的独立运行环境）也是合理的选择。