OCSP Stapling 可消除客户端证书状态查询延迟。需在 server 块中同时配置 ssl_stapling on、ssl_stapling_verify on、ssl_trusted_certificate 和 resolver，缺一不可；验证须用 openssl s_client 检查 OCSP Response Status: successful。
直接在 Nginx 的 HTTPS server 块中配置 ssl_stapling on 并配齐依赖项，就能让 OCSP 响应随 TLS 握手“预装订”发出，静态资源（如 JS/CSS/图片）的证书状态校验不再需要客户端额外发起网络请求，从而消除约 150–300ms 的阻塞延迟。
确认基础前提全部满足
缺任一条件，stapling 都会静默关闭，你完全无法察觉：
- Nginx ≥ 1.3.7（生产环境建议 ≥ 1.11.0，错误恢复更稳）
- OpenSSL ≥ 1.0.1（推荐 1.1.1+，支持 SHA-2 签名验证）
- 证书含 authorityInfoAccess 扩展：运行
openssl x509 -in your.crt -text -noout | grep -A1 "OCSP"，输出中必须有类似OCSP - URI:http://ocsp.int-x3.letsencrypt.org - 系统时间误差 ≤ ±5 分钟（否则 OCSP 响应中
thisUpdate/nextUpdate校验失败） - 证书链完整：要么
ssl_certificate是fullchain.pem（域名证书 + 中间证书），要么用ssl_trusted_certificate单独提供可信链
核心 Nginx 配置（四项必须共存）
全部写在 server { listen 443 ssl; ... } 块内，漏掉任意一条都会失效：
-
ssl_stapling on;—— 启用预装订机制 -
ssl_stapling_verify on;—— 强制校验 OCSP 响应签名、颁发者和有效期，防止缓存污染 -
ssl_trusted_certificate /path/to/full-chain-trusted.pem;—— 专用于验签的 PEM 文件，顺序为：中间证书在前、根证书在后（不能复用ssl_certificate路径） -
resolver 8.8.8.8 1.1.1.1 223.5.5.5 valid=300s;—— 必须显式指定 DNS，Nginx 不读/etc/resolv.conf；valid=300s避免 DNS 缓存过期导致 stapling 中断
推荐追加：resolver_timeout 5s;，防 DNS 查询卡住整个 TLS 握手。
针对静态站点的特别优化
静态资源无后端逻辑，更依赖首字节快速响应，可叠加以下配置提升稳定性：
- 启用会话复用：
ssl_session_cache shared:SSL:10m; ssl_session_timeout 4h;，避免重复触发 OCSP 查询 - 若使用 Let’s Encrypt，
ssl_trusted_certificate可直接指向chain.pem或fullchain.pem（确保不含私钥） - 禁用旧协议：
ssl_protocols TLSv1.2 TLSv1.3;，因 OCSP Stapling 仅在 TLS 1.2+ 生效 - 不建议在静态站点启用
ssl_stapling_file（需手动更新），除非明确处于断网环境
验证是否真正生效
别只看配置 reload 成功，要实测响应内容：
- 命令行检查：
openssl s_client -connect your-domain.com:443 -servername your-domain.com -status -tlsextdebug 2>&1 | grep -i "OCSP response"，出现OCSP Response Status: successful表示已装订 - 浏览器开发者工具 → Security 标签页 → 查看 “Certificate” → 点开 “Details” → 检查是否有 “OCSP Response” 字段及有效时间
- 对比开启前后 TLS 握手耗时（Chrome DevTools → Network → 点击 HTTPS 请求 → Timing → SSL），典型下降 150–300ms
