开启ssl_stapling_verify on必须由最前端Nginx独立完成完整验证，下游代理仅透传不校验；需配置ssl_trusted_certificate（含中间+根证书，顺序正确）、resolver及可达OCSP URL，否则TLS握手失败。
直接开启 ssl_stapling_verify on 无法解决多层代理下的 OCSP 响应校验问题，反而会因验证链断裂导致 TLS 握手失败。真正可行的做法是：在代理链最上游（即直连客户端的 Nginx）完成完整验证，下游代理不参与 OCSP 校验，仅透传已装订的响应。
上游 Nginx 必须独立完成全部验证环节
OCSP 响应签名验证只能由实际发起 OCSP 查询、持有完整信任链并能访问 OCSP 响应器的那台服务器执行。多层代理中，只有最前端的 Nginx 满足这些条件：
- 它必须配置
ssl_stapling on和ssl_stapling_verify on，且二者不可分离 -
ssl_trusted_certificate必须指向含中间证书 + 根证书的 PEM 文件，顺序为中间在前、根在后；不能复用ssl_certificate文件 -
resolver需显式设置，例如resolver 1.1.1.1 8.8.8.8 valid=300s;，避免 DNS 解析阻塞握手 - 确保该服务器能直连证书 AIA 扩展中的 OCSP URL（如
http://ocsp.int-x3.letsencrypt.org），可用curl -v或openssl ocsp提前验证
下游代理只需透传，不重验也不重取
中间层反向代理（如另一台 Nginx 或 HAProxy）不应启用任何 stapling 相关指令。否则会引发冲突或重复查询：
- 禁用
ssl_stapling和ssl_stapling_verify，避免其尝试解析或缓存 OCSP 响应 - 保持
proxy_ssl_server_name on;和proxy_ssl_protocols正确，确保 TLS 1.2+ 握手能携带certificate_status扩展 - 不要设置
ssl_trusted_certificate或resolver，这些配置对透传场景无意义，还可能干扰日志或错误处理
关键验证点：确认响应是否真实有效
最终效果是否达成，不能只看配置是否存在，而要看客户端实际收到的 OCSP 数据是否通过了可信验证：
- 用
openssl s_client -connect example.com:443 -status连接前端域名，检查输出中是否有OCSP Response Status: successful (0x0)且无Response Verify Failure - 抓包分析 TLS 握手阶段的
certificate_status扩展内容，确认其中的 OCSP 响应为 DER 编码、含有效签名及合理nextUpdate时间 - 查看上游 Nginx 错误日志，若出现
no issuer cert matches OCSP responder或OCSP response error，说明ssl_trusted_certificate文件缺失对应中间证书
常见误操作与后果
以下做法在多层代理中尤其危险，容易导致服务中断：
- 在中间代理上也开启
ssl_stapling_verify on：它既无权限访问 OCSP URL，又缺少正确ssl_trusted_certificate，必然触发握手失败 - 把前端生成的
full-chain-trusted.pem复制到下游代理并启用验证：该文件对下游无效，因为 OCSP 响应签名由前端证书链决定，而非下游所用证书 - 依赖系统证书库或省略
resolver：Nginx 不读/etc/ssl/certs，也不自动查/etc/resolv.conf，未配置则验证直接中止
