OCSP Stapling 是需服务端主动获取、签名验证、缓存分发的协同机制，非简单开关；缺任一条件（Nginx≥1.3.7、证书含authorityInfoAccess、时间误差≤±5分钟、证书链完整）则静默失效，首次HTTPS握手延迟增加150–300ms。
OCSP Stapling 不是“加一行 ssl_stapling on 就能提速”的开关，而是一套需要服务端主动获取、签名验证、缓存分发的协同机制。配置缺一环，客户端仍得自己连 CA 查吊销状态，延迟照旧——典型表现就是首次 HTTPS 握手多出 150–300ms，尤其在移动端或高延迟网络中非常明显。
确认基础条件是否全部满足
四项硬性前提必须同时成立，否则功能静默失效，Nginx 日志里可能只报一句 no resolver defined 或直接不输出 OCSP 相关日志：
- Nginx 版本 ≥ 1.3.7（生产环境强烈建议 ≥ 1.11.0），旧版本对 OCSP 错误响应处理不稳定，容易静默失败；
- 证书必须含 authorityInfoAccess 扩展，提供有效 OCSP 响应器地址，可用命令验证：
openssl x509 -in your.crt -text -noout | grep -A1 "OCSP"； - 服务器时间误差不能超过 ±5 分钟，否则 Nginx 会因 OCSP 响应有效期校验失败而拒绝使用；
- 证书链必须完整：ssl_certificate 应为域名证书 + 中间证书合并的 PEM 文件（如 Let’s Encrypt 的
fullchain.pem）。
核心配置项一个都不能少
以下四条指令需同处于 server 块（HTTPS 监听下）或全局 http 块中，路径和逻辑顺序不可颠倒：
-
ssl_stapling on;—— 显式启用功能，默认为 off； -
ssl_stapling_verify on;—— 强制校验 OCSP 响应签名、颁发者及有效期，防止缓存污染或中间人伪造； -
ssl_trusted_certificate /path/to/full-chain-trusted.pem;—— 这不是 ssl_certificate 所用文件，而是专用于验证 OCSP 响应签名的可信链（中间 CA 在前、根 CA 在后），常见于chain.pem或ca-bundle.pem； -
resolver 8.8.8.8 1.1.1.1 223.5.5.5 valid=300s;—— 必须显式指定 DNS 解析器，Nginx 不读/etc/resolv.conf；多个 DNS 提升容错性，valid=300s避免频繁重查又不过时。
建议追加：resolver_timeout 5s;，防止 DNS 查询卡住 TLS 握手。
DNS 配置是最大易忽略点
resolver 看似简单，实则决定 stapling 是否稳定启用：
- 未配置 resolver → Nginx 日志仅提示 “no resolver defined”，然后自动关闭 stapling，毫无预警；
- 只写一个 DNS（如仅
8.8.8.8）→ 若该 DNS 屏蔽 OCSP 域名或临时不可达，stapling 即刻失效； - 服务器仅支持 IPv6 → 必须加上
resolver ipv6=on;； - valid 时间过短（如 60s）→ 频繁 DNS 查询增加开销；过长（如 86400s）→ 无法及时响应 OCSP 域名变更。
验证是否真正生效
重启 Nginx 后，用 OpenSSL 实测最可靠：
openssl s_client -connect example.com:443 -status -servername example.com 2>&1 | grep -A17 "OCSP response"
成功时会看到 OCSP Response Status: successful (0x0) 及响应内容；若无此字段或显示 no response sent，说明配置未生效，需逐项回溯检查上述条件与配置路径。
