ssl_stapling_verify on必须与ssl_stapling on、ssl_trusted_certificate（含正确顺序的中间+根证书）、resolver三者协同生效，任一缺失或错误均导致TLS握手失败并返回502或SSL_do_handshake() failed错误。
单独开启 ssl_stapling_verify on 不仅无效，还会让 HTTPS 握手直接失败——它必须和 ssl_stapling on、ssl_trusted_certificate、resolver 四者同时正确配置，缺一不可。
为什么 ssl_stapling_verify on 会直接拒绝握手
开启后，Nginx 在 TLS 握手前会强制校验 OCSP 响应的签名、有效期和签发者可信度。任一环节失败（比如证书链缺失、OCSP 地址不通、DNS 解析超时），就中断握手，返回 SSL_do_handshake() failed 或 502 错误，而不是降级处理。
- 它不读系统信任库，也不从
ssl_certificate自动提取根/中间证书，只认你明确指定的ssl_trusted_certificate文件 - 该文件必须包含：用于验证 OCSP 响应签名的**全部中间证书 + 根证书**，且顺序为中间在前、根在后
- 若只放了根证书，或误用
ssl_certificate（通常不含根证书），日志中会出现no issuer cert matches OCSP responder
如何生成并验证 ssl_trusted_certificate 文件
这个 PEM 文件是验证成败的关键，不能靠猜测或复用已有证书文件。
- 先确认你的证书由哪家 CA 签发（如 Let’s Encrypt R3），再获取其对应的中间证书（
intermediate.crt）和根证书（root.crt） - 合并命令：
cat intermediate.crt root.crt > full-chain-trusted.pem - 用 OpenSSL 提前验证是否可用：
openssl ocsp -issuer intermediate.crt -cert example.com.crt -url http://ocsp.int-x3.letsencrypt.org -CAfile full-chain-trusted.pem -text，输出含response is good才算通过 - 注意：不要把域名证书（
example.com.crt）也塞进去——ssl_trusted_certificate只用于 OCSP 验证，不参与服务器证书链发送
resolver 和 OCSP 响应器连通性是隐性瓶颈
Nginx 启动或 reload 后，会主动访问证书 AIA 扩展里的 OCSP URL 获取响应。这里卡住，ssl_stapling_verify on 就会立即失效。
- 必须显式配置
resolver，例如：resolver 8.8.8.8 1.1.1.1 valid=300s;；Nginx 不读/etc/resolv.conf - 加
resolver_timeout 5s;，避免 DNS 查询阻塞整个握手流程 - 用
curl -v https://ocsp.int-x3.letsencrypt.org或openssl s_client -connect ocsp.int-x3.letsencrypt.org:443 -servername ocsp.int-x3.letsencrypt.org提前测通，确认 TLS 版本、HTTP 头、防火墙策略都兼容 - 某些 CA 的 OCSP 服务要求 HTTP/1.1 或特定 SNI，Nginx 默认行为可能不满足，需代理或调整网络策略
快速定位验证是否真正生效
别只看配置有没有加，重点看 Nginx 日志和客户端反馈。
- 检查 error log：搜索
ocsp: response verification failed、verify error或SSL_do_handshake() failed，这些是验证失败的直接证据 - 用客户端模拟：
openssl s_client -connect example.com:443 -status，观察输出中是否有OCSP Response Status: successful (0x0)，且无Response Verify Failure - 抓包验证（Wireshark/tcpdump）：解密 TLS 握手流量，确认
certificate_status扩展里携带的是有效、可验的 OCSP 响应，而非空或伪造内容 - 注意：即使配置全对，系统时间偏差 > 5 分钟也会导致 OCSP 响应被拒，务必同步 NTP
最常被忽略的一点：这四项配置不是“开了就安全”，而是构成一个强依赖链——任何一环出问题，都会导致 HTTPS 连接被拒，而不是静默降级。调试时不要急于关掉 ssl_stapling_verify，先逐项确认 ssl_trusted_certificate 内容、resolver 可达性、OCSP URL 可访问性、证书链匹配性。
