要让ssl_stapling_verify on真正起作用，必须同时配置ssl_stapling on、ssl_trusted_certificate（含顺序正确的中间+根证书）、resolver（带valid缓存时间）及可达合规的OCSP响应源，缺一不可，否则TLS握手将失败。
要让 ssl_stapling_verify on 真正起作用，不能只加这一行。它不是独立开关，而是整个 OCSP Stapling 验证链中的一环——必须和另外三项配置协同生效，否则 Nginx 会直接拒绝 TLS 握手，返回 502 或 handshake failed 错误。
必须提供完整且顺序正确的信任链
Nginx 不读系统证书库，也不从 ssl_certificate 自动提取中间或根证书。它只认你明确指定的 ssl_trusted_certificate 文件，且该文件必须包含：
- 签发你域名证书的中间 CA 证书（必须）
- 该中间 CA 对应的根证书（必须）
- 顺序不能错：中间证书在前，根证书在后
常见错误是直接复用 ssl_certificate 文件（通常不含根证书），或只放了根证书而漏掉中间 CA。推荐合并方式：
cat intermediate.crt root.crt > full-chain-trusted.pem
验证是否有效，可用命令测试：
openssl ocsp -issuer intermediate.crt -cert example.com.crt -url http://ocsp.example-ca.com -CAfile full-chain-trusted.pem -text
若输出 response is good，说明链可用。
resolver 必须显式配置并带缓存策略
OCSP 响应器地址是域名，Nginx 需 DNS 解析才能访问。它不读 /etc/resolv.conf，也无默认解析器。仅写 resolver 8.8.8.8 不够，必须加上 valid=300s 显式设定缓存时间，否则可能因 DNS TTL 导致频繁失败：
resolver 1.1.1.1 8.8.8.8 valid=300s;
- 建议配置至少两个公共 DNS，提升容错性
- 若服务器仅支持 IPv6，需额外加
resolver ipv6=on; - 更稳妥的做法是部署本地可信 DNS（如 CoreDNS），避免公共 DNS 被劫持影响 OCSP 查询
OCSP 响应源必须可达且响应合规
Nginx 在 reload 或首次握手时，会主动访问证书 AIA 扩展中声明的 OCSP URL。若该地址不通、超时、返回非 200 响应、或响应格式非法，ssl_stapling_verify on 就会中断验证，导致连接被拒。
- 提前确认连通性：curl -v https://ocsp.example-ca.com
- 某些 CA 的 OCSP 服务对 HTTP/1.1、TLS 版本或 Host 头有隐式要求，Nginx 默认行为可能不满足；必要时可加
-header "Host" "ocsp.example-ca.com"测试 - 确保服务器时间准确（偏差超过 5 分钟常被 OCSP 响应拒绝）
四项指令必须同时启用且位置正确
ssl_stapling_verify on 本身不触发任何 OCSP 行为。以下四条必须共存于同一 server 块（HTTPS 监听下）或全局 http 块中：
-
ssl_stapling on;—— 启用 stapling 机制 -
ssl_stapling_verify on;—— 开启签名与有效期校验 -
ssl_trusted_certificate /path/to/full-chain-trusted.pem;—— 提供验证所需完整 CA 链 -
resolver x.x.x.x y.y.y.y valid=300s;—— 保障 OCSP 查询路径畅通
缺一不可。单独开启 ssl_stapling_verify 不但无效，反而会让 HTTPS 服务变得脆弱。
