ocsp stapling 是否生效须用 openssl s_client 实测：执行 openssl s_client -connect example.com:443 -servername example.com -status -tlsextdebug，输出含 ocsp response status: successful (0x0) 即成功；若为 no response sent 或无 ocsp 字段，则配置失败或静默失效。
直接测 TLS 握手时间本身不反映 OCSP Stapling 是否生效，因为 Nginx 不会把 OCSP 响应时间单独拆出来上报。真正有效、可复现、能对比的方式，是用 openssl s_client 模拟真实客户端行为，观察是否跳过了 OCSP 查询环节，并结合网络耗时指标交叉验证。
用 openssl s_client 观察 OCSP 响应状态
这是最核心的验证手段，能明确判断 stapling 是否成功装订：
- 运行命令：openssl s_client -connect example.com:443 -servername example.com -status -tlsextdebug
- 重点看输出中是否有 OCSP Response Status: successful (0x0) —— 出现即表示服务器已成功返回 stapled 响应
- 若显示 OCSP response: no response sent 或根本没出现 OCSP 相关字段，说明 stapling 未启用或配置失败（静默失效）
- 注意：必须加 -status 参数，否则不会触发 OCSP 状态请求；-tlsextdebug 可辅助确认 TLS 扩展交互
用 curl + time 测首字节延迟（TTFB）作为间接指标
TLS 握手是 TTFB 的关键组成部分，开启 stapling 后，弱网或跨区域访问下 TTFB 通常下降明显：
- 执行：curl -o /dev/null -s -w "time_connect: %{time_connect}\ntime_appconnect: %{time_appconnect}\n" https://example.com
- 关注 time_appconnect 字段：它包含 DNS 解析、TCP 连接和 TLS 握手全过程，其中 TLS 握手占比最大
- 在相同网络条件下（建议用固定出口 IP，如本地终端或云服务器），分别测试开启/关闭 stapling 后的值，差异集中在 150–300ms 区间即属正常效果
- 注意排除 CDN、后端服务响应等干扰，最好搭配 -H "Cache-Control: no-cache" 和 --resolve 绕过 DNS 缓存
用 Wireshark 抓包看实际网络行为
适合定位“为什么没生效”，尤其当 openssl 显示 no response 但配置看似正确时：
- 在客户端机器抓包，过滤 tls.handshake.type == 1（ClientHello）和 tls.handshake.type == 2（ServerHello）
- 展开 ServerHello → Extensions → status_request → CertificateStatus → response → OCSPResponse，能看到 stapled 数据体
- 若抓不到 OCSPResponse，但客户端发了 status_request 扩展，说明 Nginx 侧未装订；若客户端根本没发该扩展，可能是浏览器未启用或证书不支持
- 同时检查是否有额外的 OCSP 查询流量（目标端口 80/443，域名含 ocsp.），有则说明 stapling 未起作用，客户端仍在自行查询
配合日志与系统状态快速排障
避免盲目调参，先确认基础条件是否满足：
- 查 Nginx 错误日志：grep -i stapling /var/log/nginx/error.log —— 正常情况无报错，但若缺 resolver 或时间偏差大，会有 warning
- 验证系统时间：ntpq -p 或 timedatectl status，确保 offset ≤ ±5 分钟
- 确认证书含 OCSP URI：openssl x509 -in your.crt -text -noout | grep -A1 "Authority Information Access"，输出中应有 OCSP - URI:
- 检查 resolver 是否生效：nginx -t 必须通过；且不能依赖 /etc/resolv.conf，必须显式写在 server 块里
