验证0-rtt需三要素：手机抓包确认type=11报文紧随clienthello、curl弱网测ttfb降30–60ms、chrome devtools与nginx日志交叉验证$ssl_early_data=1且响应200。
直接测移动端真实网络下的 0-RTT 加速效果，关键不在“能不能连上”，而在“首字节是否真提前发出、是否被客户端正确识别并复用”。必须结合设备实测、协议层验证和业务响应观察，三者缺一不可。
用手机抓包确认 0-RTT 是否真正触发
在安卓或 iOS 设备上，通过电脑共享热点，让手机走你可控的网络链路：
- 手机连接电脑热点，Wireshark 在电脑端捕获 Nginx 出口流量（不是手机本地抓包，避免 TLS 解密失败）
- 过滤表达式：
tls.handshake.type == 11 && ip.src == [你的Nginx服务器IP]（type 11 是 End of Early Data 握手消息） - 对比首次访问与第二次访问：第二次应出现 type=11 的报文，且紧随 ClientHello 之后（无 ServerHello → Certificate → 等完整握手流程），说明 0-RTT 已生效
- 同时检查首个 Application Data record 长度是否落在 1390–1410 字节区间——这验证了
ssl_buffer_size 1400+tcp_nodelay on协同工作，首 HTML 响应未被缓冲或分片
用 curl 模拟弱网环境测 TTFB 收益
单纯看本地延迟没意义，4G/5G 的高 RTT 和丢包才放大 0-RTT 价值：
- 在 Linux 服务器上用
tc netem模拟典型移动网络：tc qdisc add dev eth0 root netem delay 50ms loss 2.5% - 执行带时间统计的重复请求（需客户端支持 TLS 1.3 + 0-RTT）：
for i in {1..20}; do curl -w "TTFB: %{time_starttransfer}s\n" -k https://yoursite.com/ -o /dev/null -s; done | sort -nk2 | head -n10 - 重点比对中位数：开启 0-RTT 后，重复访问的 TTFB 应比首次访问低 30–60ms（跨地域公网下更明显）。若差距小于 10ms，说明 PSK 未复用或 early data 被后端拒绝（如返回了 425）
通过 Chrome DevTools 和 Nginx 日志交叉验证
浏览器行为和服务器日志要能对得上，才能排除配置静默失效：
- 在手机 Chrome 中打开目标页面 → 开发者工具 → Network → 点击任意 HTTPS 请求 → Headers 标签页：
查看请求头是否含 Early-Data: 1；响应头是否含 Warning: 199 - "0-RTT data received"（部分版本显示为
Early-Data: 1响应头） - 在 Nginx 配置中添加日志字段，确认变量解析正常：
log_format main '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" "$ssl_early_data"'; - 访问后查 access.log：若
$ssl_early_data字段值为 1，且对应请求是 GET /，响应状态为 200，则 0-RTT 数据已送达后端并被处理
注意移动端特有的干扰因素
不是所有“看起来连上了 TLS 1.3”的情况都代表 0-RTT 可用：
- iOS 15+/Android Chrome 72+ 才稳定支持，旧版 WebView 或微信内置浏览器可能降级到 TLS 1.2（即使 Nginx 配了 TLSv1.3）
- 运营商中间盒可能剥离或篡改 ALPN 协商，导致客户端无法协商 h2 或 http/1.1，进而影响 PSK 复用；可在 Nginx 的
ssl_ciphers中显式加入TLS_CHACHA20_POLY1305_SHA256并配ssl_conf_command Options -PrioritizeChaCha提升兼容性 - 若用户清空浏览器缓存或更换设备，PSK 失效，0-RTT 自动退化为 1-RTT —— 这属于正常行为，不必误判为配置失败
