OCSP Stapling 失效主因是静默失败而非未配置，需依次检查证书OCSP URI、Nginx网络连通性、ssl_trusted_certificate验证链、缓存状态及日志警告。
OCSP Stapling 无法获取响应，通常不是“没配”，而是某个环节在静默失败。Nginx 不会报错中断服务，但会跳过装订、返回空响应，最终导致浏览器自行查询（甚至查不到），性能与安全性双双受损。排查需从证书链、网络连通性、验证逻辑、缓存状态四方面逐层验证。
检查证书是否声明了有效 OCSP 地址
这是最基础也最容易被忽略的一环。若证书里没有 Authority Information Access (AIA) 扩展中的 OCSP URI，Nginx 根本不会尝试发起请求。
- 运行命令：openssl x509 -in your.crt -text -noout | grep -A1 "OCSP"，确认输出中包含类似 CA Issuers - URI:https://ocsp.example.com 的行
- 自签名证书或测试证书常无此字段，此时 stapling 必然失效，需换用私有 CA 签发的证书
- Let’s Encrypt 证书默认含 OCSP URI；若使用 Cloudflare 或某些代理服务，可能被剥离，需检查原始证书
验证 Nginx 是否能解析并访问 OCSP 响应器
Nginx 必须先 DNS 解析 OCSP 域名，再发起 HTTP 请求。任一环节失败，都会导致响应拉取失败，且默认不记录详细日志。
- 确认配置中存在 resolver 指令（如 resolver 8.8.8.8 1.1.1.1 valid=300s;），且后接 resolver_timeout 5s;
- 手动模拟请求：在 Nginx 所在服务器上执行 openssl ocsp -issuer intermediate.crt -cert your-domain.crt -url http://ocsp.int-x3.letsencrypt.org -text（注意协议用 http/https 要匹配实际 URI）
- 若提示 unable to get certificate from responder 或超时，说明网络不通、防火墙拦截、或 OCSP 服务不可达（内网私有 CA 尤其常见）
确认 ssl_trusted_certificate 配置正确且可验证
Nginx 验证 OCSP 响应签名时，只信任 ssl_trusted_certificate 文件里的证书，且顺序必须严格匹配签发链。
- 该文件必须只含根证书 + 中间证书（不含站点证书），顺序为：根证书在前，中间证书紧随其后，拼成一个 PEM 文件
- 执行校验命令：openssl ocsp -verify_other ca.crt -CAfile full-trust-chain.pem -respin response.der -text，输出含 Response verify OK 才算通过
- 常见错误：文件路径写错、权限不足（Nginx worker 进程需可读）、混入了 Let’s Encrypt 根证书等公网 CA
检查缓存是否为空或过期，并确认生效状态
即使配置全对，Nginx 也可能因首次启动未完成预取、或响应已过期而发不出 OCSP 数据。
- 查看 Nginx 错误日志（error_log /var/log/nginx/error.log notice;），搜索 stapling 或 ocsp，留意 issuer certificate not found 或 stapling ignored 类警告
- 用 OpenSSL 实测是否装订成功：openssl s_client -connect your.site:443 -status -servername your.site 2>&1 | grep -A17 "OCSP response"，看到 OCSP Response Status: successful (0x0) 且有二进制内容才表示真正生效
- 内网环境建议直接禁用自动拉取，改用 ssl_stapling_file 手动指定响应文件，并配合 cron 定期更新
