抓包分析是验证OCSP Stapling是否生效、定位卡顿的最直接方式，可确认客户端是否发送status_request扩展、服务器是否返回CertificateStatus消息、响应是否有效完整，并精确测量握手时延差异。
抓包分析是验证 OCSP Stapling 是否真正生效、定位卡顿环节最直接的方式。它能看清客户端是否发起 status_request 扩展、服务器是否在 ServerHello 后附带 CertificateStatus 消息、响应体是否完整有效——这些信息日志里不会记录，openssl 命令也看不到细节。
确认客户端是否发起 OCSP 查询请求
浏览器或客户端必须主动声明需要 OCSP 响应，Nginx 才会装订。抓包时过滤 TLS 握手初始阶段：
- Wireshark 过滤表达式：
tls.handshake.type == 1 && tls.handshake.extensions.length > 0 - 展开 ClientHello → Extensions → status_request（type=5），若存在该扩展，说明客户端支持且启用了 OCSP 查询
- 常见不出现的原因：IE/旧安卓 WebView 默认启用，Chrome/Firefox 现代版本默认启用但可能被策略禁用；Safari 在某些系统版本中默认不发
检查服务器是否返回 stapled OCSP 响应
关键看 ServerHello 后是否有 CertificateStatus 消息，这是 stapling 成功的铁证：
- Wireshark 过滤：
tls.handshake.type == 2 || tls.handshake.type == 22（ServerHello 或 CertificateStatus） - 找到 ServerHello 后紧邻的 handshake type = 22（CertificateStatus）消息
- 展开 CertificateStatus → response → OCSPResponse，能看到 ASN.1 编码的响应体，长度通常在 800–2000 字节之间
- 若只看到 ServerHello，没有后续 CertificateStatus，说明 Nginx 未装订（配置缺失、resolver 失败、证书链无效等）
测量 OCSP 装订对握手时延的实际影响
OCSP Stapling 的价值体现在时间节省上。抓包可精确比对两个关键时间点：
- ClientHello 发送时刻 → ServerHello 接收时刻：反映基础 TLS 握手耗时
- ClientHello 发送时刻 → CertificateStatus 接收时刻：反映含 OCSP 响应的完整握手耗时
- 对比开启/关闭 stapling 两次抓包：若后者比前者多出 200ms 以上，说明 OCSP 查询正在回源（resolver 超时或不可达）；若两者几乎一致，说明缓存命中或 stapling 已生效
- 特别注意：Android WebView 和部分旧客户端会在收到 ServerHello 后等待 ALPN 协商完成前就中断连接——此时抓包可见 FIN 包紧随 ServerHello，就是 OCSP 拖慢导致的降级信号
排查 stapling 静默失效的典型网络痕迹
很多问题不是“没配”，而是“配了但不起作用”，抓包能暴露静默失败的蛛丝马迹：
- ClientHello 带 status_request → ServerHello 返回 → 无 CertificateStatus → 客户端随后发起独立 HTTP 请求到 ocsp.xxx.com：说明 Nginx 侧 stapling 未触发，客户端被迫自行查询
- ClientHello 带 status_request → ServerHello 返回 → CertificateStatus 内容为空或 length=0：常见于 ssl_trusted_certificate 文件错误（混入站点证书、顺序颠倒、缺少中间证书）
- ClientHello 带 status_request → 长时间无 ServerHello（>5s）→ 最终 TCP RST：大概率是 resolver 不可达或 resolver_timeout 过长，DNS 查询阻塞整个握手
