ssl_stapling_verify on 是强校验触发器，非独立开关；必须与 ssl_stapling on、ssl_trusted_certificate（含正确顺序的中间+根证书）、resolver（带 valid 缓存）四项共存且正确，否则 TLS 握手失败，返回 502 或 handshake failed。
开启 ssl_stapling_verify on 本身不“确保证书状态检查的完整性”，它只验证 OCSP 响应是否由可信 CA 签发、签名未被篡改、时间戳有效——前提是其他三项配置全部到位且正确。
为什么单独开 ssl_stapling_verify on 反而会让 HTTPS 失败
这个指令不是开关式功能，而是强校验触发器。Nginx 一旦启用，会在每次 TLS 握手前执行完整验证链，任一环节失败即中断连接（客户端看到 502 或 handshake failed）。常见断连原因包括：
-
ssl_stapling on没开：OCSP 响应根本不会被获取，验证无从谈起 -
ssl_trusted_certificate路径错误、文件为空或顺序错乱（比如根证书在前、中间证书在后） -
resolver未配置，或只写了 IP 没加valid=300s，导致 DNS 解析卡住握手 - 证书 AIA 扩展里的 OCSP URL 不可达（
curl -v https://ocsp.int-x3.letsencrypt.org返回超时或 404）
ssl_trusted_certificate 必须是完整链，且不能复用 ssl_certificate
Nginx 不读系统信任库，也不从 ssl_certificate 自动提取中间或根证书。它只认你显式指定的 PEM 文件，且该文件必须满足：
- 内容为中间证书 + 根证书拼接（顺序不能反）
- 不含服务器证书本身（
example.com.crt） - 不含任何无关证书（比如混入 Let’s Encrypt 的根证书到私有 CA 环境）
验证方式：openssl ocsp -issuer intermediate.crt -cert example.com.crt -url http://ocsp.int-x3.letsencrypt.org -CAfile full-chain-trusted.pem -text，输出含 Response verify OK 才算通过。
resolver 配置不当会导致 OCSP 查询永远卡住
Nginx 不用系统 /etc/resolv.conf，必须手动配 resolver，且必须带缓存策略：
- 只写
resolver 8.8.8.8;是无效的——缺少valid参数，DNS 缓存行为不可控 - 推荐写法：
resolver 1.1.1.1 8.8.8.8 valid=300s; - 内网环境建议部署本地可信 DNS（如 CoreDNS），避免公共 DNS 被污染导致 OCSP 查询失败
若 resolver 不可用，Nginx 在 reload 后首次尝试 OCSP 请求就会阻塞，后续所有 HTTPS 请求均失败，错误日志中会出现 ocsp: resolver not configured 或 no resolver defined to resolve。
验证是否真正在工作，别只看配置有没有写上
配置写完不等于生效。最直接的验证方式是抓包 + 日志交叉比对：
- 用
openssl s_client -connect example.com:443 -status连接，观察输出里是否有OCSP Response Status: successful (0x0)且没有Response Verify Failure - 查 Nginx error log，搜索
ocsp: response verification failed或SSL_do_handshake() failed - Wireshark 抓 TLS 握手包，过滤
tls.handshake.type == 22，展开Certificate Status扩展，确认响应体是 DER 编码、长度非零、且签名字段存在
最容易被忽略的是：即使所有配置语法正确，只要 OCSP 响应器返回的 nextUpdate 时间早于当前系统时间（系统时钟不准也会触发），ssl_stapling_verify on 就会拒绝使用该响应——它不妥协，也不降级。
