最常见的源头是证书未嵌入ocsp uri，必须用openssl x509 -in cert.crt -text -noout | grep -a1 "ocsp"验证，无输出即不支持；uri存在后还需curl测试可达性，不可达则需重签证书。
Nginx OCSP Stapling 无法生效，最常见的源头不是配置写错，而是证书压根没嵌入 OCSP 查询地址。没有这个地址，Nginx 连发起请求的依据都没有，后续所有配置都形同虚设。
确认证书是否含 OCSP URI
这是排查的第一步，也是最关键的硬性前提。必须用 OpenSSL 直接读取证书内容验证，不能只看 CA 官网说明或假设“Let’s Encrypt 的证书肯定有”。
运行命令：
openssl x509 -in /path/to/your.crt -text -noout | grep -A1 "OCSP"
正常输出应类似：
Authority Information Access:
OCSP - URI:http://r3.o.lencr.org
若无任何输出，或只显示 OCSP - URI: 后面为空，说明证书缺失 Authority Information Access（AIA）扩展，不支持 OCSP 查询。
检查常见证书类型的实际支持情况
- Let’s Encrypt（R3、E1 等）证书默认包含 OCSP URI，但极少数旧签发或自定义 CSR 可能遗漏；
- Sectigo、DigiCert 商业证书一般支持，但免费版或精简链可能省略 AIA；
- 私有 CA 签发的证书，需明确在签发模板中启用
authorityInfoAccess扩展，并配置OCSP;URI:http://...。
区分“证书有 URI”和“URI 可访问”
即使输出了 URI，也要验证该地址是否真实可用：
curl -I -m 3 http://r3.o.lencr.org 2>/dev/null | head -1
预期返回 HTTP/1.1 200 OK 或 400 Bad Request（合法响应）。若返回 curl: (7) Failed to connect 或超时，说明 OCSP 响应器本身不可达——这属于网络或 CA 侧问题，但根源仍是证书指向了一个无效地址。
补救方式很明确
证书一旦签发，OCSP URI 就固化在其中，无法后期添加。唯一可靠办法是：
- 重新生成 CSR（确保未禁用 AIA 扩展）；
- 向 CA 提交新 CSR，申请重签；
- 使用新证书替换，再验证
grep -A1 "OCSP"是否出现有效 URI。
不复杂但容易忽略：很多运维人员花几小时调 resolver 和 ssl_trusted_certificate，却没先花 10 秒跑一遍 openssl x509 -text。只要证书没 OCSP 地址，其他所有配置都只是空转。
