https变慢需分tls握手、代理转发、后端响应三环排查：用nginx的$upstream_connect_time等四字段拆解耗时，curl直连后端比对time_appconnect与$upstream_connect_time定位tls问题，检查ocsp stapling是否卡worker，确认proxy_http_version 1.1启用keep-alive。
HTTPS 配置后访问变慢，不能只盯着“加了 SSL 就变卡”这个表象。关键是要快速锁定延迟发生在哪一环：是 TLS 握手拖了后腿，还是代理转发出了问题，又或是后端本身响应滞后。下面这几个动作，5 分钟内就能帮你划出责任范围。
看日志里四段耗时，别只盯 $request_time
Nginx 默认的 $request_time 是个“总账”，混着握手、网络、后端处理、缓冲写入全算在一起，看不出谁在拖。必须拆开看：
- $upstream_connect_time：Nginx 连上后端花了多久（含与后端的 TLS 握手）→ 如果各请求间波动大，说明后端证书链不一致或 TLS 配置不统一
- $upstream_header_time：后端返回第一个响应头的时间 → 直接反映后端业务逻辑启动快慢
- $upstream_response_time：后端发完全部响应的时间 → 持续偏高，问题就在后端代码或数据库
- $request_time 减去上面三项，剩下的就是 Nginx 自身处理（如 SSL 握手给客户端、缓冲、日志等）
在 log_format 中加上这四个变量，重启后立刻查 access.log，比猜快得多。
绕过 Nginx 测后端，确认是不是它的问题
用 curl 直连后端地址，把 Nginx 这层“中间商”摘掉：
-
curl -w "@format.txt" https://backend-ip:port/api（format.txt 内容：
%{time_appconnect} %{time_starttransfer} %{time_total}） - %{time_appconnect} ≈ 客户端与后端完成 TLS 握手的时间 → 若明显高于 Nginx 到后端的 $upstream_connect_time，说明后端 TLS 配置有问题（比如没开 TLSv1.3、证书链缺中间件）
- %{time_starttransfer} ≈ 后端首字节返回时间 → 和 $upstream_header_time 对比，基本能判断后端是否真慢
检查 OCSP Stapling 是否静默卡住 worker
ssl_stapling on 不等于真正生效。一旦配置不到位，Nginx 会在首次请求时同步发起 DNS 解析 + HTTP 请求去拉 OCSP 响应，卡住整个 worker 进程几秒——日志会批量涌出，接口首字节严重延迟。
- 运行 openssl x509 -in cert.pem -text -noout | grep -A1 "OCSP"，确认输出有真实可用的 URI
- 检查 nginx.conf 是否写了 resolver 1.1.1.1 8.8.8.8 valid=30s;（不能依赖系统 DNS）
- 临时加一行 ssl_stapling off;，reload 后观察延迟是否立刻缓解，就能验证是不是它
确认代理协议版本，避免 HTTP/1.0 暗坑
这是最常被忽略却影响最大的点：Nginx 默认用 HTTP/1.0 转发请求到后端，每个请求都重建 TCP 连接。尤其在移动端或高并发下，三次握手 + TLS 握手反复叠加，TTFB 直接翻倍。
- 在 location 或 server 块中加：proxy_http_version 1.1;
- 同时确保后端服务支持 keep-alive（比如 Spring Boot 默认就支持，Node.js 需显式启用）
- 验证方式：抓包看后端请求头是否有
Connection: keep-alive，或用ss -ant | grep :8080观察连接是否复用
