我有一个 HTTPS 网站，有时，对于相同的客户端，$request_time 是 $upstream_response_time 的 10 倍，甚至是 100 倍。我理解 2 次之间的区别： $request_time 是接收到的第一个字节和发送的最后一个字节之间的持续时间。
一些用户告诉我他们遇到了连接超时，所以我认为这些长 $request_time 是真正的问题。
这些长 $request_time 发生在 GET 请求中（典型请求大小：185 字节）。上游是一个fastcgi进程。我想知道在哪种情况下 $request_time 可能太高：
- 没有 fastcgi 工作人员正在接受连接，$request_time 包括 fastcgi 进程的“等待时间”
- 响应不正确（错误的内容长度，分块响应）并且客户端正在等待未到来的数据
- SSL 证书：客户端获取我们的 SSL 证书，请求 OCSP 并完成 SSL 连接。
我想知道哪些选项实际上是可能的，以及我如何找出实际创建 long $request_time 的原因。
OSCP 时不时地是一个问题，但我会在超时/不可用的 fastcgi-workers-direction 中进行更多调查。这是一个真正的 heisenbug 还是发生在不同的用户身上？您是否有基于 http 的监控（例如，通过 Nagios、Selenium 等的真正 GET 请求，而不仅仅是端口 80/443 - 检查）
调试步骤：