https访问变慢本质是某层拖后腿，需分层剥离：先用curl -w查%{time_appconnect}定位tls瓶颈，再验证书链、会话复用、proxy_buffering及http/2协商是否生效。
HTTPS 访问变慢，通常不是“整体变慢”，而是某一层在拖后腿——可能是 TLS 握手卡顿、代理转发失真、后端响应滞后，或是连接复用完全失效。关键在于分层剥离、逐段验证，而不是笼统调优。
先确认是不是 TLS 层在拖
很多“慢”其实卡在握手阶段，但日志里只显示 request_time 高，容易误判为后端问题：
- 用 curl -w "@format.txt" https://your-domain.com 测，重点关注 %{time_appconnect}（TLS 握手完成耗时）；若它占总耗时 60% 以上，就是 TLS 瓶颈
- 检查 Nginx 日志中 $ssl_protocol/$ssl_cipher 字段：如果大量出现 TLSv1.2 + RSA 或 DHE 套件，说明客户端正在走低效密钥交换，握手比 ECDHE 慢 3–5 倍
- 运行 openssl s_client -connect your-domain.com:443 -servername your-domain.com -tlsextdebug，看是否返回完整证书链；缺中间证书会触发客户端 OCSP 查询，多加 200–800ms
看代理行为有没有引入缓冲延迟
尤其对 JS/CSS/大文件或流式接口（SSE、gRPC-Web），Nginx 默认缓冲策略可能造成“攒够才发”的假性卡顿：
- 检查配置中是否有 proxy_buffering on;（默认开启）；若启用，Nginx 会等满 buffer（默认仅 32KB）才加密发送，HTTPS 下更明显
- 对静态资源或实时接口，建议显式关闭：proxy_buffering off;，并配 proxy_buffer_size 128k; 和 proxy_buffers 32 128k; 防止临时文件写入
- 确认 proxy_http_version 1.1; 已启用——否则 Nginx 默认用 HTTP/1.0 连后端，每个请求都重连 TCP，移动端感知极差
验证会话复用是否真正生效
每次完整 TLS 握手消耗 0.5–2ms CPU，而复用只需查缓存。但“开了”不等于“生效”：
- ssl_session_cache 必须写在 http { } 块顶层，且全局唯一；写在 server 块里会被忽略
- ssl_session_timeout 建议设为 10m 或 4h；默认 5 分钟太短，连接刚复用完就过期
- 执行 ss -s | grep -i tls 查 ESTABLISHED 连接数；若持续超 5000 且 nginx -T | grep session_cache 显示缓存命中率低，说明复用基本没起作用
检查 HTTP/2 和 ALPN 协商是否成功
HTTP/2 多路复用能显著降低并行资源加载的 RTT，但需服务端、证书、客户端三方配合：
- Nginx listen 指令必须含 http2：如 listen 443 ssl http2;
- 用 Chrome DevTools → Network → 刷新页面，看 Protocol 列是否为 h2；或 curl -I --http2 https://your-domain.com 看是否返回 HTTP/2 200
- 自签名或私有 CA 证书大概率不支持 ALPN 扩展，会导致协商失败降级到 HTTP/1.1；务必使用 Let’s Encrypt 或 DigiCert 等主流 CA 签发的证书
