如何通过OCSP响应缓存优化提升Nginx的HTTPS性能？

OCSP（在线证书状态协议）是用来检查SSL证书是否被吊销的机制。传统模式下，浏览器在TLS握手时会主动向CA的OCSP服务器查询证书状态，这个过程不仅增加了几百毫秒的握手延迟，还把用户的访问行为暴露给了证书颁发机构。OCSP Stapling技术把这项工作转移到了服务端：Nginx定期获取OCSP响应并缓存起来，握手时直接发给浏览器，一举解决了延迟和隐私两个问题。

一、OCSP的工作原理与性能瓶颈

当浏览器访问一个HTTPS站点时，证书链验证是必不可少的环节。浏览器需要确认服务器证书没有被CA吊销。在未启用Stapling的情况下，浏览器会根据证书中的AIA扩展字段找到OCSP responder地址，然后发起一次独立的HTTP请求查询状态。这个请求往返时间取决于用户到CA服务器的网络状况，如果CA的OCSP服务器响应缓慢甚至宕机，浏览器要么阻塞等待，要么在超时后降级放行，两种情况体验都很差。

国内用户访问境外CA的OCSP服务器时尤为明显。以某境外大型CA为例，其OCSP节点部署在海外，平均查询延迟在200ms以上，遇到网络波动时可能直接超时。而OCSP Stapling的思路是让Nginx代替所有客户端去查询：Nginx按证书中指定的OCSP nextUpdate周期（通常几天到一周）提前拉取签名后的响应，缓存在内存中。客户端握手时通过Certificate Status消息一次性拿到结果，省去了浏览器与CA之间的往返。

此外，传统OCSP查询还存在隐私问题：CA能通过查询日志得知哪些IP访问了哪些域名。Stapling模式下查询方变成了服务器本身，客户端不再与CA直接通信，用户访问轨迹得到了保护。这也是为什么现代浏览器厂商（如Chrome通过CRLSet、Firefox通过OneCRL）都在推动各自的替代方案，而服务端Stapling仍然是兼容性最好的选择。

二、Nginx中开启OCSP Stapling的完整配置

开启OCSP Stapling只需要几行配置，但每个指令都有讲究。核心指令是ssl_stapling和ssl_stapling_verify，前者启用功能，后者要求Nginx验证OCSP响应的签名链，防止下发被篡改的响应。验证响应需要信任链上所有CA的证书，所以必须通过ssl_trusted_certificate指定包含中间证书和根证书的文件。

server {
    listen 443 ssl;
    server_name www.ipipp.com;

    ssl_certificate         /etc/nginx/ssl/www.ipipp.com.crt;
    ssl_certificate_key     /etc/nginx/ssl/www.ipipp.com.key;

    # 指定包含中间证书与根证书的完整链，用于验证OCSP响应签名
    ssl_trusted_certificate /etc/nginx/ssl/trusted_chain.pem;

    # 开启OCSP Stapling并验证响应
    ssl_stapling            on;
    ssl_stapling_verify     on;

    # 必须配置resolver，Nginx需要解析OCSP responder的域名
    resolver 223.5.5.5 8.8.8.8 valid=300s;
    resolver_timeout 5s;
}

这里最容易被忽略的是resolver指令。Nginx获取OCSP响应时需要解析证书中AIA字段记录的responder域名，而Nginx自带的解析器不会读取系统/etc/resolv.conf（运行时解析与启动时解析是两回事），不配置resolver的话Stapling会静默失败，error.log中会出现类似resolver not defined或no resolver defined to resolve ocsp.xxx.com的报错。建议配置至少两个DNS服务器保证可用性，并用valid参数控制DNS缓存时间。

另一个细节是证书文件本身。如果ssl_certificate指向的文件没有包含中间证书，握手时客户端可能无法构建完整信任链，Stapling验证也会失败。正确的做法是服务器证书在前、中间证书在后拼接成一个文件。配置完成后执行nginx -t检查语法，再reload生效。注意Nginx需要在处理过一次请求后才会去拉取OCSP响应，刚重启时Stapling尚未就绪属于正常现象。

三、验证缓存效果与生产环境调优

配置完成后必须实际验证，而不是想当然认为已经生效。OpenSSL命令可以直接探测目标站点是否返回了stapled响应：

# 查看OCSP响应URL
openssl x509 -in www.ipipp.com.crt -noout -ocsp_uri

# 测试站点是否下发stapled证书状态
openssl s_client -connect www.ipipp.com:443 -status < /dev/null 2>&1 | grep -A 4 "OCSP"

# 期望输出包含：
# OCSP response: no response sent  表示未生效
# OCSP Response Status: successful (0x0)  表示Stapling正常

如果输出no response sent，优先排查三个方向：第一，确认ssl_trusted_certificate文件包含了完整的中间证书和根证书链；第二，检查resolver是否配置以及DNS能否解析responder域名，可以在Nginx所在机器上用dig手动验证；第三，查看error.log中的OCSP相关日志，常见问题包括responder返回未授权（证书链不完整导致）或网络超时。

生产环境还可以进一步优化。对于多域名虚拟主机，每个server块都要单独配置Stapling指令，或者将公共SSL配置抽取到http级别的公共片段中。若Nginx版本在1.19.x以上，可以考虑通过proxy_cache或第三方模块配合本地缓存OCSP响应，避免responder故障时所有worker同时重新拉取。部分证书（如某些自签名证书或私有CA签发的证书）不包含AIA扩展，Nginx无法自动发现responder地址，这时可以用ssl_stapling_file手动指定预先下载好的OCSP响应文件，由外部定时任务负责更新：

# 手动获取OCSP响应并保存
openssl ocsp -issuer chain.pem -cert server.crt \
    -url http://ocsp.example-ca.com -respout /etc/nginx/ssl/ocsp.resp

# Nginx中直接引用本地响应文件
# ssl_stapling_file /etc/nginx/ssl/ocsp.resp;

最后要理解Stapling的降级行为：当缓存的响应过期且重新拉取失败时，Nginx不会在握手中携带证书状态，客户端会回退到自行查询或直接软失败。因此对可用性要求高的场景，务必通过监控（如定时执行openssl s_client探测脚本并结合告警）确保Stapling持续在线。经验上，开启Stapling后首次握手的证书验证耗时平均可减少100ms到300ms，配合HTTP/2和会话复用，整体HTTPS性能会有可感知的提升。

NginxOCSP StaplingSSL证书优化修改时间：2026-09-14 05:04:39