必须同时配置 ssl_stapling on、ssl_stapling_verify on、ssl_trusted_certificate 和 resolver 四项指令，缺一不可；否则 ocsp 装订验证失败，导致 tls 握手异常。
直接在 Nginx 配置里加上 ssl_stapling_verify on 并不能启用验证，它必须和另外三项指令协同工作，否则 TLS 握手会失败（常见 502 或 handshake timeout）。它的作用是在 OCSP 响应发给客户端前，由 Nginx 本地完成签名、时间戳和证书匹配三重校验，确保响应真实可信。
必须共存的四个配置项
这四行必须全部写在同一个 HTTPS 的 server 块中，缺一不可：
-
ssl_stapling on;—— 启用 OCSP 装订机制本身，没有它，Nginx 不会拉取或缓存任何 OCSP 响应 -
ssl_stapling_verify on;—— 开启强制校验：检查响应是否由可信 CA 签发、签名是否有效、ThisUpdate/NextUpdate是否在当前时间 ±5 分钟内、响应是否针对当前站点证书 -
ssl_trusted_certificate /path/to/full-chain-trusted.pem;—— 指向专用于验签的信任链文件，内容只能是：中间 CA 证书（如 Let’s Encrypt R3）在前 + 根 CA 证书（如 ISRG Root X1）在后；不能含域名证书，也不能顺序颠倒 -
resolver 1.1.1.1 8.8.8.8 valid=300s;—— 显式指定 DNS 解析器，Nginx 不读系统/etc/resolv.conf；valid=300s是必需参数，防止 DNS 缓存过期导致 stapling 中断
ssl\_trusted\_certificate 文件怎么准备
这个文件不是你的站点证书链副本，而是 OCSP 响应验签的“信任锚”。常见错误包括复用 ssl_certificate、只放根证书、或顺序反了。
- Let’s Encrypt 用户可直接用
chain.pem（不含私钥，且顺序正确） - 自建或企业证书需手动拼接：
cat intermediate.crt root.crt > /etc/nginx/ssl/full-chain-trusted.pem - 验证是否有效：
openssl ocsp -issuer intermediate.crt -cert example.com.crt -url http://ocsp.int-x3.letsencrypt.org -CAfile /etc/nginx/ssl/full-chain-trusted.pem -text，输出含 Response verify OK 才算通过
如何确认 ssl\_stapling\_verify 真正生效
不看配置是否写上，要看实际校验是否触发：
- 终端执行：
openssl s_client -connect yourdomain.com:443 -status -servername yourdomain.com 2>&1 | grep -A17 "OCSP response"，成功时应看到 OCSP response: successful (0x0) 和 CertStatus: good - 检查 Nginx 错误日志，搜索 ocsp、verify failed、no resolver defined 等关键词
- 用 SSL Labs 测试页（ssllabs.com）查看结果中 “OCSP stapling” 是否显示 Yes，并注意下方是否有 “Stapling verified” 提示
关键注意事项
即使配置全对，以下几点出问题也会导致验证失败：
- 系统时间偏差超过 ±5 分钟：OCSP 响应含严格有效期，Nginx 会直接拒绝
- 防火墙拦截出站 HTTP 请求：多数 CA（如 Let’s Encrypt）使用 HTTP 协议的 OCSP 端点，不是 HTTPS
- OCSP 地址不可达：Nginx 在 reload 或首次握手时会主动访问证书 AIA 扩展里的 URL，失败即中断握手
- 未追加
resolver_timeout 5s;：DNS 查询卡住会导致整个 TLS 握手超时，建议加上
