必须同时配置ssl_stapling on、ssl_stapling_verify on、ssl_trusted_certificate和resolver四项，缺一不可，否则OCSP Stapling静默失效；实测可减少150–300ms握手延迟。
直接在 Nginx 的 HTTPS server 块中配齐四条关键指令，就能让服务器主动拉取并缓存 OCSP 响应，在 TLS 握手时一并“装订”发出，客户端无需再单独查询 CA，首屏加载可缩短约 41%，实测减少 150–300ms 握手延迟。
必须同时配置的四个核心项
漏掉任意一条，stapling 都会静默关闭，Nginx 日志可能不报错，但客户端收不到 OCSP 响应：
- ssl_stapling on; —— 显式启用功能，默认是关闭的
- ssl_stapling_verify on; —— 强制校验 OCSP 响应签名、有效期和颁发者，防止伪造或过期数据
-
ssl_trusted_certificate /path/to/fullchain.pem; —— 指向包含中间证书 + 根证书的完整信任链（不是你的域名证书），用于验证 OCSP 响应本身是否可信；Let’s Encrypt 用户通常用
chain.pem或fullchain.pem -
resolver 8.8.8.8 1.1.1.1 223.5.5.5 valid=300s; —— 必须显式指定 DNS 解析器，Nginx 不读
/etc/resolv.conf；valid=300s表示 DNS 缓存 5 分钟，避免后续解析失败
配套建议与常见避坑点
这些设置不强制但强烈推荐，能提升稳定性与成功率：
- 加上 resolver_timeout 5s;，防止 DNS 查询卡住整个 TLS 握手
- 确保 系统时间误差 ≤ ±5 分钟，OCSP 响应含严格的时间窗口（
thisUpdate/nextUpdate），超差会被直接拒绝 -
证书链必须完整：`ssl_certificate` 应为域名证书 + 中间证书合并的 PEM 文件（如 Let’s Encrypt 的
fullchain.pem）；否则 `ssl_stapling_verify on` 会校验失败 - 确认证书含 Authority Information Access 扩展，可用命令检查：
openssl x509 -in your.crt -text -noout | grep -A1 "OCSP"，输出应有有效 URL
验证是否真正生效
不能只看配置重载成功，要确认客户端实际收到了 stapled 响应：
- 终端执行：
openssl s_client -connect example.com:443 -status -servername example.com 2>&1 | grep -A 2 "OCSP response"
成功时应看到OCSP response: successful (0x0)和CertStatus: good - 检查 Nginx 错误日志，搜索关键词：
ocsp、no resolver defined、verify failed、timeout - 用 SSL Labs 测试页，查看结果中 “OCSP stapling” 是否显示 Yes
为什么一定要在负载均衡层开启
若只在后端应用服务器（如 Tomcat）配置，而 Nginx 作为 SSL 终止点未启用 stapling，客户端连接的是 Nginx，证书验证由它完成——后端的配置完全无效。只有在 TLS 解密发生的那一层（即 Nginx 负载均衡器或反向代理）启用，才能真正把 OCSP 响应装订进 ServerHello 消息中。使用 TCP 层透传（SSL Passthrough）模式也无法启用，必须是 SSL 终止模式。
