ocsp stapling 可减少150–300ms https 握手延迟，需同时满足证书含ocsp uri、nginx≥1.3.7、openssl≥1.0.1、系统时间偏差≤±5分钟、证书链完整，并在server块中配置ssl_stapling on、ssl_stapling_verify on、ssl_trusted_certificate、resolver及resolver_timeout，否则静默失效。
在 Nginx 中配置 OCSP Stapling 并不是简单打开一个开关，而是一套必须协同生效的机制。它能让服务器在 TLS 握手时主动把 CA 签发的证书吊销状态（OCSP 响应）一起发给客户端，省去浏览器自行查询 OCSP 服务器的那一次网络请求，通常可减少 150–300ms 的首次 HTTPS 握手延迟，对移动端和弱网用户效果尤其明显。
确认基础条件是否全部满足
缺任何一项，ssl_stapling 都会静默失效（Nginx 不报错、不警告，但实际不工作）：
- 证书含有效 OCSP 地址：用命令检查：
openssl x509 -in your.crt -text -noout | grep -A1 "OCSP"，输出中需有类似OCSP - URI:http://ocsp.int-x3.letsencrypt.org - Nginx ≥ 1.3.7（生产环境建议 ≥ 1.11.0），OpenSSL ≥ 1.0.1（推荐 1.1.1+ 或更新版）
- 系统时间偏差 ≤ ±5 分钟（OCSP 响应含严格时间戳，超时即被拒绝）
- 证书链完整：要么 ssl_certificate 指向包含站点证书 + 所有中间证书的文件（如 Let’s Encrypt 的
fullchain.pem），要么用 ssl_trusted_certificate 单独指定可信链
HTTPS server 块内必须添加的配置项
以下指令必须全部写入监听 443 的 server 块中（不能只放在 http 块顶层，也不能遗漏任意一条）：
- ssl_stapling on; —— 必须显式开启（默认为 off）
- ssl_stapling_verify on; —— 强烈建议启用，用于校验 OCSP 响应签名、有效期及颁发者，防止缓存伪造或过期数据
- ssl_trusted_certificate /path/to/fullchain.pem; —— 指向根证书 + 所有中间证书的 PEM 文件（顺序：中间证书在前、根证书在后；不能包含你的站点证书）
-
resolver 8.8.8.8 1.1.1.1 223.5.5.5 valid=300s; —— 必须显式配置 DNS 解析器（Nginx 不读
/etc/resolv.conf），多个 DNS 提升容错性；valid=300s表示 DNS 缓存 5 分钟 - resolver_timeout 5s; —— DNS 查询超时设为 5 秒，避免因解析卡住拖慢整个 TLS 握手
特别注意两个易错点
这两个配置出错，是 stapling 静默失效的最常见原因：
-
ssl_trusted_certificate 的内容必须是中间证书 + 根证书拼接而成（例如 Let’s Encrypt 的
chain.pem或fullchain.pem），且不能混入站点证书或无关 CA -
resolver 必须能连通 OCSP 域名（如
ocsp.int-x3.letsencrypt.org）。若使用私有 CA，resolver 应指向可解析其 OCSP 地址的内网 DNS（如 CoreDNS）
验证是否真正生效
部署完成后，可通过以下方式确认：
- 用 OpenSSL 测试：
openssl s_client -connect yourdomain.com:443 -status -servername yourdomain.com 2>&1 | grep -i "OCSP response"，看到OCSP Response Status: successful表示成功 - 用在线工具如 SSL Labs 扫描，查看 “OCSP Stapling” 一栏是否显示 “Yes”
- 抓包观察 TLS 握手过程中的
CertificateStatus消息是否存在
