nginx 无 ssl_stapling_timeout 参数，ocsp stapling 超时控制依赖 resolver、resolver_timeout 和 ocsp 响应自身的 nextupdate 时间戳；需配置多个 dns、短 resolver_timeout（如 3s）、ssl_stapling_verify on 及 shared ssl_stapling_cache。
Nginx 没有 ssl_stapling_timeout 这个配置参数。
这是常见的误解。官方 Nginx 文档（截至 2026 年）中从未定义过 ssl_stapling_timeout 指令，所有稳定版本（包括 1.20.x、1.22.x、1.24.x、1.25.x）均不支持该配置项。若在配置中写入 ssl_stapling_timeout 5s;，Nginx 启动时会报错：
unknown directive "ssl_stapling_timeout"
那么，OCSP Stapling 的“超时控制”靠什么实现？
真正影响 OCSP 响应获取是否超时、是否降级、是否拖慢握手的，是以下三个关键参数的组合效果：
-
resolver+resolver_timeout：控制 DNS 解析阶段的超时 -
OCSP 响应自身的
nextUpdate时间戳：决定缓存有效期（Nginx 默认严格遵循） -
ssl_stapling_cache缓存机制：避免每次握手都触发新请求
✅ 正确控制“超时行为”的做法：
-
显式配置多个可靠 DNS，并设短超时
http { resolver 1.1.1.1 8.8.8.8 223.5.5.5 valid=300s; resolver_timeout 3s; # ⚠️ 关键！防止 DNS 卡住 TLS 握手 } -
启用并严格校验 stapling 响应（防静默失效）
ssl_stapling on; ssl_stapling_verify on; ssl_trusted_certificate /path/to/chain.pem; # 仅含中间+根证书，顺序正确
-
配置共享缓存，确保多 worker 进程共用响应
ssl_stapling_cache shared:OCSP:10m; # 必须在 http 块中声明
不依赖
ssl_stapling_file或自定义缓存时间ssl_stapling_file是静态文件路径，仅用于手动预加载（调试用），不参与超时控制；Nginx 不会按你指定的“秒数”刷新或丢弃它。
补充说明：为什么有人误以为有 ssl_stapling_timeout？
- 混淆了其他模块（如
proxy_timeout、fastcgi_read_timeout）的命名习惯 - 误读第三方博客或过时文档（部分旧帖把
resolver_timeout错标为ssl_stapling_timeout） - 期待“强制重试间隔”或“最大等待时长”，但 Nginx 的 stapling 逻辑是：
- 缓存有效 → 直接返回
- 缓存过期或为空 → 后台异步刷新（不阻塞握手）
- 仅当后台刷新失败且无可用响应时，才静默关闭 stapling（此时客户端回退 OCSP 查询，产生毛刺）
如何验证 stapling 是否稳定不超时？
用 OpenSSL 手动模拟高并发场景下的首次握手（触发 OCSP 获取）：
openssl s_client -connect example.com:443 -status -servername example.com 2>/dev/null | grep -i "OCSP response"
配合 tcpdump 或 chrony 日志，观察 DNS 查询是否在 3s 内完成、OCSP 响应是否带 nextUpdate 且时间合理（通常 4–7 天）、系统时间偏移是否
不复杂但容易忽略。
