ssl_stapling 是 nginx 在 tls 握手 serverhello 阶段主动装订已验证 ocsp 响应的机制，使客户端跳过单独查询 ca 的网络请求，实测减少 150–300ms 首次握手延迟；其生效需同时满足五项硬性前提（证书含 ocsp uri、nginx≥1.3.7、openssl≥1.0.1、时间偏差≤±5 分钟、证书链完整）及四条核心配置指令（ssl_stapling on、ssl_stapling_verify on、ssl_trusted_certificate、resolver），缺一即静默失效。
ssl_stapling 是什么，为什么它能提速
ssl_stapling 不是开关式优化，而是让 Nginx 在 TLS 握手的 ServerHello 阶段，主动把已获取并验证过的 OCSP 响应“装订”进响应包。客户端拿到后，无需再单独向 CA 的 OCSP 服务器发起一次 HTTP 查询（含 DNS、TCP、TLS、HTTP 全流程），直接完成证书吊销状态校验。实测可减少 150–300ms 首次握手延迟，对移动网络、跨境链路或高丢包环境效果更明显。
五项硬性前提，缺一不可
只要其中任一条件不满足，Nginx 不报错、不警告，ssl_stapling 会静默失效——日志里可能只有一行 no resolver defined 或 silently disabled，但实际未工作。
- 证书必须含有效 OCSP URI：用
openssl x509 -in your.crt -text -noout | grep -A1 "OCSP"检查，输出需类似OCSP - URI: http://ocsp.int-x3.letsencrypt.org - Nginx ≥ 1.3.7（生产建议 ≥ 1.11.0），OpenSSL ≥ 1.0.1（推荐 1.1.1+ 或更新）
- 系统时间偏差 ≤ ±5 分钟：运行
chronyc tracking或ntpdate -q pool.ntp.org确认 - 证书链完整：ssl_certificate 必须指向 fullchain.pem（站点证书 + 所有中间证书），不能仅是域名证书 .crt
- 服务器能直连 OCSP 地址：用
curl -I http://ocsp.int-x3.letsencrypt.org或openssl ocsp -url http://ocsp.int-x3.letsencrypt.org -text测试是否返回responseStatus: successful
四条核心配置指令，必须写在 server 块内
这些指令不能放在 http 块顶层或 location 块中，必须置于监听 443 的 server { listen 443 ssl; ... } 内部：
-
ssl_stapling on;：显式启用，默认为 off -
ssl_stapling_verify on;：强制校验 OCSP 响应签名、颁发者及有效期，防止缓存伪造或过期数据 -
ssl_trusted_certificate /path/to/fullchain.pem;：指向仅含中间证书 + 根证书的 PEM 文件（顺序：中间证书在前、根证书在后），不是你的站点证书文件；Let’s Encrypt 用户可直接复用/etc/letsencrypt/live/example.com/chain.pem或fullchain.pem（去掉首段域名证书即可） -
resolver 1.1.1.1 8.8.8.8 223.5.5.5 valid=300s;：Nginx 不读 /etc/resolv.conf，必须显式指定至少两个 DNS；valid=300s 表示 DNS 缓存 5 分钟
增强稳定性的关键补充项
以下非必需，但在生产环境中强烈建议加入，避免因 DNS 卡顿、缓存失效或握手阻塞引发连锁问题：
-
resolver_timeout 5s;：限制单次 DNS 查询超时为 5 秒，防止 OCSP 解析卡住整个 TLS 握手 -
ssl_session_cache shared:SSL:10m;和ssl_session_timeout 4h;：启用会话复用，大幅降低重复连接的 OCSP 查询频次 - 若服务器支持 IPv6，加
resolver ipv6=on;，否则可能因 IPv6 DNS 查询失败导致 stapling 降级 - 禁用老旧协议与弱套件：
ssl_protocols TLSv1.2 TLSv1.3;，搭配现代 cipher 如ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256
