nginx 反代高并发时，偶尔出现 upstream timed out 该怎么排查原因？

[kisshere]

高并发状态下，error_log 偶尔出现：

upstream timed out (110: Connection timed out) while reading response header from upstream

因为是偶尔出现这个 time out, 我自己访问又没有任何问题，所以不知道该怎么排查，是 upstream 服务器请求太多处理不过来？还是反代服务器和 upstream 服务器网络连接有问题，还是反代服务器 nginx 配置问题？

so 上给出的最高赞答案： https://stackoverflow.com/questions/18740635/nginx-upstream-timed-out-110-connection-timed-out-while-reading-response-hea 把 proxy_read_timeout 加大就可以了，感觉完全是治标不治本啊

nginx 能不能设置一个超过 time out 就自动再向 upstream 服务器重新发送请求的功能？

[kisshere]

@facelezz 查了下默认超时是 60s ，话说你愿意等待一个网页加载超过 60s 么？大多数人等个三四秒没反应就关闭网页了，这个超时时间加长和没加长又有什么区别。。。

[picone]

@lambdaq 查了一下 nginx 的 backlog 的配置文档：
sets the backlog parameter in the listen() call that limits the maximum length for the queue of pending connections. By default, backlog is set to -1 on FreeBSD, DragonFly BSD, and macOS, and to 511 on other platforms.
这个 backlog 也就是 listen 队列的长度。其实调整这个感觉是治标不治本，相当于更多需要 accept 的连接都没被处理到，如果都 accept 了就是往 upstream 建立更多的连接。upstream 其实是能指定 nginx 放弃请求的，TCP 会 FIN ，对应比如 Go 里面就是 context canceled 。
定位错误的另外一个方法是开启 debug 级别的日志观察一下。

[picone]

@kisshere 下游服务也是 nginx 服务？ 可以查一下下游的 access_log ，如果是对应的请求有 499 的话基本实锤是下游服务的问题了。
感觉你们的日志并没有串起来，建议在最上游的服务搞一个 logid/traceid 之类含义的字段，放 header ，然后全链路都透传这个字段，查日志就能一一对应了。

[lambdaq]

@picone 这里说的不是 nginx 的 backlog 。说的是响应 nginx 请求的 upstream 的 backlog 。

[facelezz]

@kisshere 不是 这个有的公司会配的很短 你如果没配的话 就没必要改

[facelezz]

我感觉这个少了 APM 和日志链 并不好排查 可以按照上面的提示调整下 backlog 或者配置 proxy_next_upstream 来缓解

[dusu]

1. Accesslog 里把 upstream_response_time 写上
2. 自己写个 bash 统计上游平均响应时长
3. ss -s 看看系统连接情况
4. ss -tlnp 看 backlog 占用情况

[kisshere]

@dusu 试了，upstream_response_time 几乎都是在毫秒范围内，出现了极个别“-”值

[julyclyde]

你把 upstream server address 记录下来看看，有些请求可能会有好几个 upstream server address