ocsp stapling 卡顿源于 tls 握手初期同步阻塞事件循环，表现为 dns 解析、http 请求等未异步化；日志中出现“no resolver defined”“ocsp: timeout”等即为关键线索，需检查 resolver 配置、超时及 ocsp 响应有效性。
排查 OCSP Stapling 引起的 worker 进程卡顿，核心是识别它是否在 TLS 握手初期同步阻塞了事件循环——这不是线程“死锁”，而是单线程模型下 DNS 解析、HTTP 请求、证书验证等操作未异步化，导致整个 worker 暂停响应新请求。
看日志里有没有“stapling”相关的阻塞痕迹
OCSP Stapling 卡住时，error.log 会出现明确线索：
- 高频出现 no resolver defined 或 no resolver found：说明 Nginx 启动后首次请求触发 stapling，但没配 resolver，直接卡在系统默认 DNS 查询（可能长达 30 秒）
- 反复报 ssl_stapling: no OCSP responder URL：证书缺失 Authority Information Access 扩展，Nginx 尝试解析失败后重试，拖慢握手
- 大量 ocsp: timeout 或 ocsp: verify failed：resolver 虽有但不可达，或 ssl_trusted_certificate 不完整，导致校验失败后反复获取
用 OpenSSL 快速验证 stapling 是否真生效且不卡
运行命令模拟客户端首次握手并强制拉取 OCSP 响应：
观察输出：
- 若卡住数秒才返回，或最后没有 OCSP response: successful (0x0)，说明 stapling 正在同步阻塞
- 若返回 OCSP response: no response sent，说明配置未触发 stapling，但也不卡；真正危险的是“卡住几秒后才返回失败”
检查 resolver 配置是否合理且独立于网络抖动
resolver 不只是“要写”，关键在于它是否被正确加载、是否超时可控、是否避开不可靠 DNS：
- 必须显式写在 http 或 server 块中，Nginx 不读 /etc/resolv.conf
- 至少配两个公共 DNS（如 resolver 8.8.8.8 1.1.1.1 valid=30s;），避免单点故障
- 务必加 resolver_timeout 5s; —— 这是防卡顿最关键的参数，缺它时默认 socket 超时可达数分钟
- 如果用内网 DNS，确认它能解析 OCSP 域名（如 ocsp.int-x3.letsencrypt.org），可手动测试：dig @10.10.0.2 ocsp.int-x3.letsencrypt.org
临时关闭 stapling 看 CPU 和延迟是否回落
这是最直接的因果验证手段：
- 把 ssl_stapling off; 加入 server 块，reload 配置
- 用 top -H -p $(pgrep nginx | head -1) 观察各线程 CPU 占用：若之前某个线程持续 90%+，关闭后明显下降，说明 stapling 是瓶颈
- 同时测 TTFB：用 curl -w "%{time_starttransfer}\n" -o /dev/null -s https://example.com，对比开关前后的首字节时间变化
- 注意：关闭后浏览器会自行发起 OCSP 查询，延迟转移到客户端，所以仅用于服务端诊断，不可长期关闭
