详解Nginx no live upstreams while connecting to upstream

网上看到几个相关的文章，觉得很不错，这里整理记录分享一下，供大家参考。

upstream配置分

在分析问题原因之前，我们先来看下关于上面upstream配置一些相关的参数配置说明，参考下面表格

ngx_http_proxy_module

这里重点看框出来的三个参数：proxy_connect_timeout、proxy_send_timeout、proxy_read_timeout，默认超时时间是60s

官方地址：http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_connect_timeout

upstream_server

参考问题：排查Nginx-no live upstreams错误_nginx_lucky猿-GitCode 开源社区

还是重点关注我们目前使用的max_fails和fail_timeout，可以看到我们使用的是15s内失败2次即认为该服务不可用。再结合proxy_connect_timeout的默认60s，以上no live upstreams while connecting to upstream问题就很明朗了。

1、Nginx代码：

502伴随出现错误no live upstreams while connecting to upstream的原因:

具体场景：接入层的负载均衡的nginx集群转发给业务nginx，业务nginx再转发给后端的应用服务器。业务nginx配置文件如下：

upstream ads {

server ap1:8888 max_fails=1 fail_timeout=60s;

server ap2:8888 max_fails=1 fail_timeout=60s;

}

• 如果业务nginx出现日志： no live upstreams while connecting to upstream 的日志，
• 此外还有大量的“upstream prematurely closed connection while reading response header from upstream”的日志。

看“no live upstreams”的问题。
看字面意思是nginx发现没有存活的backend后端了，但是奇怪的是，只有部分接口访问异常出现502。

可以从nginx源码的角度来看了。

因为是upstream有关的报错，所以在ngx_http_upstream.c中查找“no live upstreams”的关键字，可以找到如下代码（其实，你会发现，如果在nginx全局代码中找的话，也只有这个文件里面有这个关键字）：

在这里可以看出，当rc等于NGX_BUSY的时候，就会记录“no live upstreams”的错误。

往上看1328行，可以发现rc的值又是ngx_event_connect_peer这个函数返回的。

ngx_event_connect_peer是在event/ngx_event_connect.c中实现的。这个函数中，只有这个地方会返回NGX_BUSY，其他地方都是NGX_OK或者NGX_ERROR或者NGX_AGAIN之类的。

rc = pc->get(pc, pc->data);

if (rc != NGX_OK) {

return rc;

}

这里的pc是指向ngx_peer_connection_t结构体的指针， get是个ngx_event_get_peer_pt的函数指针，具体指向哪里，根据配置和使用的轮询规则来确定。

接着翻看ngx_http_upstream.c

在ngx_http_upstream_init_main_conf中看到了，如下代码：

uscfp = umcf->upstreams.elts;

for (i = 0; i < umcf->upstreams.nelts; i++) {

init = uscfp[i]->peer.