Nginx不校验后端证书，SSL证书校验开销源于客户端首次HTTPS连接时的证书链验证、签名检查及OCSP吊销查询；加速核心是OCSP Stapling闭环配置、精简证书链、双轨会话复用（cache+tickets）及TLS 1.3协议升级。
Nginx 本身不“校验后端证书”，它面向客户端做 TLS 终结，所谓“SSL 证书校验开销”实际指：客户端首次建立 HTTPS 连接时，需验证服务器证书链完整性、签名有效性、吊销状态（OCSP）等环节带来的延迟。高并发下，这些操作若未缓存或复用，会显著拖慢握手。真正有效的加速不是靠堆 CPU，而是让协议层、会话层、响应层协同跳过重复计算。
强制启用 OCSP Stapling 并确保稳定生效
客户端不再自己查 OCSP，Nginx 提前获取并附在 TLS 握手中——这是削减证书验证耗时最直接的手段，可避免 150–300ms 的额外往返。但必须闭环配置，缺一不可：
-
ssl_stapling on;和ssl_stapling_verify on;写在server { listen 443 ssl; }块内 -
ssl_trusted_certificate指向仅含中间 CA + 根 CA 的 PEM 文件（顺序：中间在前、根在后），不能混入域名证书 -
resolver 1.1.1.1 8.8.8.8 valid=300s; resolver_timeout 2s;——Nginx 不读系统 DNS，必须显式指定且能连通 OCSP 域名 - 证书必须含 Authority Information Access 扩展（
openssl x509 -in cert.pem -text -noout | grep -A1 OCSP可验证）
若 Nginx 日志频繁出现 stapling ignored，说明 OCSP 请求失败（DNS 不通、CA 服务不可达或时间偏差超 ±5 分钟），此时 stapling 自动退化，延迟照旧。
精简证书链 + 预置可信根
长链（如 3 级以上）会让部分安卓旧版本、IoT 设备反复下载中间证书或校验失败。推荐使用 Let’s Encrypt 等签发的 2 级链（域名证书 → 中间 CA → 根 CA），并确保：
-
ssl_certificate指向fullchain.pem（域名证书 + 中间证书合并） -
ssl_trusted_certificate单独提供根+中间证书，用于 OCSP 验证和客户端链补全 - 避免手动拼接、人工遗漏中间证书；Certbot 自动更新时默认输出 fullchain.pem，应直接部署
这样既减少传输体积，又避免客户端运行时动态查找信任根，移动端弱网下效果尤其明显。
双轨会话复用机制全覆盖
完整握手才会触发证书解析与 OCSP 验证；复用会话则跳过全部校验步骤。实测复用率超 70% 时，证书相关开销基本归零：
- 在
http块顶层配置共享缓存：ssl_session_cache shared:SSL:10m;（10MB 支持约 4 万个会话） - 设合理超时：
ssl_session_timeout 4h;（比默认 5 分钟更适配移动端间歇访问） - 启用 Session Tickets：
ssl_session_tickets on;并轮换密钥ssl_session_ticket_key /etc/nginx/ticket.key; - 若 Nginx 作为反向代理且后端也走 HTTPS（如微服务），加
proxy_ssl_session_reuse on;复用上游连接
注意：Session Cache 和 Session Tickets 是互补机制，不是二选一。Cache 依赖内存共享，Tickets 依赖密钥加密，双开才能覆盖更多客户端类型。
协议与密码套件精简，减少协商负担
TLS 1.3 默认跳过证书签名算法协商，CPU 开销比 TLS 1.2 低 30%～50%，且强制前向保密：
-
ssl_protocols TLSv1.2 TLSv1.3;（彻底禁用 TLSv1.0/v1.1） -
ssl_ciphers 'TLS13-AES-128-GCM-SHA256:TLS13-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-CHACHA20-POLY1305'; - 可进一步限定曲线与签名算法：
ssl_conf_command Curves X25519:secp256r1;和ssl_conf_command SignatureAlgorithms ecdsa_secp256r1_sha256:rsa_pss_rsae_sha256;
这些设置压缩协商过程，让证书验证阶段更轻量，尤其利于高并发短连接场景。
不复杂但容易忽略
