开启 ssl_stapling_verify on 是强校验机制，必须与 ssl_stapling on、ssl_trusted_certificate（中间证书在前、根证书在后）、resolver（含 valid=300s）共存于同一 server 块，缺一则 tls 握手失败。
开启 ssl_stapling_verify on 不是为了让 OCSP Stapling “看起来更安全”，而是把它变成一项强校验能力——只要任一环节不可信，TLS 握手就立即中止。它不妥协、不降级，因此配置必须精准、协同、可验证。
ssl_trusted_certificate 文件必须严格按序包含中间+根证书
这个 PEM 文件是整个验证链的起点，Nginx 完全不读系统信任库，也不从 ssl_certificate 自动提取证书。常见错误包括：只放根证书、混入域名证书、顺序颠倒（根在前、中间在后）、或直接复用 fullchain.pem（常缺根证书）。
- 正确做法：用
cat intermediate.crt root.crt > /etc/nginx/ssl/trusted-ocsp-ca.pem合并，确保中间证书在前、根证书紧随其后 - 验证命令：
openssl ocsp -issuer intermediate.crt -cert example.com.crt -url http://ocsp.int-x3.letsencrypt.org -CAfile /etc/nginx/ssl/trusted-ocsp-ca.pem -text - 成功标志：输出含
Response verify OK或response is good，且无unable to get local issuer certificate类报错
resolver 必须显式声明且带缓存与超时控制
Nginx 不继承系统 DNS 配置，resolver 缺失或写法不完整会导致 OCSP 查询卡死，进而触发握手失败。仅写 resolver 8.8.8.8 是无效的。
- 标准写法：
resolver 1.1.1.1 8.8.8.8 valid=300s;—— 至少两个 DNS，valid强制设定缓存有效期 - 建议追加：
resolver_timeout 5s;，防止 DNS 延迟拖垮 TLS 握手 - 若服务器仅支持 IPv6，需额外添加：
resolver ipv6=on;
OCSP 响应源连通性与响应格式需提前确认
证书 AIA 扩展中声明的 OCSP URL 是 Nginx 主动发起请求的目标。它不是“尽力而为”，而是“必须可达且合规”，否则 ssl_stapling_verify on 直接拒绝连接。
- 查 URL：
openssl x509 -in example.com.crt -noout -text | grep -A1 "OCSP" - 测连通：
curl -v -I http://ocsp.int-x3.letsencrypt.org（注意多数 CA 使用 HTTP，非 HTTPS） - 关键检查点：返回状态码必须为 200；响应体必须是 RFC 6960 兼容的 DER 编码 OCSP 响应，不能是 HTML 错误页、重定向或空响应
四项指令必须共存于同一 server 块且全部启用
ssl_stapling_verify on 本身不触发任何 OCSP 行为，它只是校验开关。只有当以下四者同时存在、位置正确、语法无误时，整套机制才真正生效：
-
ssl_stapling on;—— 启用 stapling 机制 -
ssl_stapling_verify on;—— 启用本地响应校验 -
ssl_trusted_certificate /path/to/trusted-ocsp-ca.pem;—— 提供验证所需完整信任链 -
resolver ... valid=300s;—— 保障 OCSP 查询路径畅通
任意一项缺失或路径错误，日志中会出现 SSL_do_handshake() failed 或 502 Bad Gateway，而非静默降级。
