nginx 不在 access_log 或 error_log 中直接记录 ocsp stapling 命中或验证状态，因该信息属 tls 握手层；可用 $ssl_stapling_responder 和 $ssl_stapling_verify 变量（1.11.0+）记录响应器 url 和验证结果（0/1/-1），结合 $ssl_session_reused 与调试日志间接判断缓存命中。
Nginx 本身不直接在 access_log 或 error_log 中记录 OCSP Stapling 的命中（cache hit）或验证状态（如 valid / revoked / expired / no response），这是因为它在 TLS 握手层面处理 OCSP Stapling，而日志模块默认不暴露这些 SSL/TLS 级别的内部状态。
使用 $ssl_stapling 变量记录 Stapling 是否启用
该变量仅表示当前连接是否启用了 OCSP Stapling（即配置中开启了 ssl_stapling on 且证书链支持），不是运行时状态。值为 on 或 off，无法区分“有响应但过期”或“无响应”。
可在 log_format 中使用：
log_format ssl_ocsp '$remote_addr - $remote_user [$time_local] '
'"$request" $status $body_bytes_sent '
'"$http_referer" "$http_user_agent" '
'stapling=$ssl_stapling';用 $ssl_stapling_responder 和 $ssl_stapling_verify 暴露关键状态
这两个变量从 Nginx 1.11.0+ 开始可用（需 OpenSSL 1.0.2+），能反映实际运行时行为：
-
$ssl_stapling_responder：返回 OCSP 响应器 URL（如
http://ocsp.int-x3.letsencrypt.org），若未获取到响应则为空字符串 -
$ssl_stapling_verify：表示 OCSP 响应的签名和有效性验证结果，值为
0（失败）、1（成功）或-1（未验证，例如 stapling 被禁用或无响应）
推荐组合记录：
log_format ocsp_debug '$remote_addr - $remote_user [$time_local] '
'"$request" $status $body_bytes_sent '
'ocsp_url="$ssl_stapling_responder" '
'ocsp_verify=$ssl_stapling_verify '
'stapling=$ssl_stapling';间接判断命中：结合 $ssl_session_reused 和响应时间观察
OCSP Stapling 响应默认缓存（由 ssl_stapling_cache 控制，默认 shared:SSL:10m），命中表现为：
- 同一 worker 进程内多次 TLS 握手复用相同 session（
$ssl_session_reused = "r"）且$ssl_stapling_verify = 1，大概率是缓存命中 - 若
$ssl_stapling_verify = 1但$ssl_stapling_responder为空，说明响应来自本地缓存（无网络请求），属于命中 - 可配合 error_log 的 debug 级别临时观察：开启
error_log /path/to/error.log debug;，搜索"ocsp"、"stapling"关键字，Nginx 会打印如ocsp staple cached、ocsp staple updated、ocsp staple verify failed等调试信息
生产环境实用建议
- 不要依赖 access_log 实时监控 OCSP 状态，应搭配 Prometheus + nginx-lua-prometheus 或自定义 Lua 脚本采集
$ssl_stapling_verify做指标聚合 - 定期用
openssl s_client -connect example.com:443 -status手动验证实际响应内容与状态 - 确保
ssl_stapling_cache配置合理（如ssl_stapling_cache shared:StaplingCache:128k;），避免频繁回源 OCSP server - 注意：$ssl_stapling_verify 是连接级变量，只在 TLS 握手完成且 stapling 发生后才有效；HTTP 请求日志中该变量始终存在，但值可能为
-1
