HTTPS资源加载慢的核心在于TLS握手开销、协议协商低效、连接复用不足和证书链处理拖沓；优化需启用HTTP/2、全局配置ssl_session_cache shared:SSL:10m与ssl_session_timeout 10m、禁用ssl_session_tickets、精简加密套件、升级proxy_http_version至1.1并启用OCSP Stapling。
HTTPS 下资源加载慢，问题通常不在带宽或服务器 CPU，而在于 TLS 层的握手开销、协议协商低效、连接复用不足和证书链处理拖沓。Nginx 作为 HTTPS 入口网关，配置稍有偏差，就会让首字节时间（TTFB）明显升高，尤其在移动端 WebView 或弱网环境下感知强烈。优化关键不是“加资源”，而是“减往返、提复用、精路径”。
启用 HTTP/2 并确认 ALPN 生效
HTTP/2 的多路复用能避免 HTTP/1.1 的队头阻塞，显著降低并发请求的总延迟。但必须满足两个前提：服务端显式开启 + 客户端不降级。
- 在
server块中将监听行改为：listen 443 ssl http2;（IPv6 同理加listen [::]:443 ssl http2;） - 确保 SSL 证书由主流 CA（如 Let’s Encrypt、DigiCert）签发，支持 ALPN 扩展；自签名或私有 CA 证书需补全中间链
- 验证方式：Chrome DevTools → Network → 刷新页面 → 查 Protocol 列是否为
h2；或执行curl -I --http2 https://your-domain.com，返回头含HTTP/2 200
优化 TLS 握手与会话复用
WebView 或小程序频繁新建连接时，若每次握手都走完整流程（1–2 RTT），TTFB 直接被拉高。重点不是“更快握手”，而是“尽量不握手”。
- 全局启用共享缓存：在
http块中写ssl_session_cache shared:SSL:10m;（一次定义，所有 server 继承） - 设置合理超时：
ssl_session_timeout 10m;（太短复用率低，太长内存压力大） - 关闭 Session Tickets：
ssl_session_tickets off;（Nginx 当前实现存在兼容性风险，且安全边界模糊） - 精简加密套件，聚焦现代高效算法：
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305; ssl_protocols TLSv1.2 TLSv1.3;
修复反向代理链路退化
Nginx 默认以 HTTP/1.0 连接后端，导致每个请求都重连 TCP，移动端卡顿明显。这不是 HTTPS 本身的问题，而是代理层“倒退”。
- 在
location或server块中添加：proxy_http_version 1.1; - 确保后端服务（如 Spring Boot、Node.js）响应
Connection: keep-alive头，且未主动关闭长连接 - 若代理 WebSocket，还需补充：
proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade";
精简证书链并启用 OCSP Stapling
证书链缺失或过长，会让客户端在 TLS 握手阶段额外发起 OCSP 查询，造成不可控延迟。
- 用命令检查链完整性：
openssl s_client -connect your-domain.com:443 -servername your-domain.com -showcerts
确保返回包含根证书 → 中间证书 → 域名证书的完整链
- 启用 OCSP Stapling：
ssl_stapling on; ssl_stapling_verify on; resolver 8.8.8.8 1.1.1.1 valid=300s;
注意：
resolver必须显式配置，否则 stapling 不生效
不复杂但容易忽略
