详解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.init_upstream uscfp[i]->peer.init_upstream:

ngx_http_upstream_init_round_robin;

if (init(cf, uscfp[i]) != NGX_OK) {

return NGX_CONF_ERROR;

}

}

这里可以看到，默认的配置为轮询（事实上负载均衡的各个模块组成了一个链表，每次从链表到头开始往后处理，从上面到配置文件可以看出，nginx不会在轮询前调用其他的模块），并且用ngx_http_upstream_init_round_robin初始化每个upstream。

再看ngx_http_upstream_init_round_robin函数，里面有如下行：

r->upstream->peer.get = ngx_http_upstream_get_round_robin_peer;

这里把get指针指向了ngx_http_upstream_get_round_robin_peer

在ngx_http_upstream_get_round_robin_peer中，可以看到：

#if (NGX_HTTP_UPSTREAM_ZONE)

if (peers->config && rrp->config != *peers->config) {

goto busy;

}

#endif

if (peers->single) {

peer = peers->peer;

if (peer->down) {

goto failed;

}

if (peer->max_conns && peer->conns >= peer->max_conns) {

goto failed;

}

rrp->current = peer;

ngx_http_upstream_rr_peer_ref(peers, peer);

} else {

/* there are several peers */

peer = ngx_http_upstream_get_peer(rrp);

if (peer == NULL) {

goto failed;

}

ngx_log_debug2(NGX_LOG_DEBUG_HTTP, pc->log, 0,

“get rr peer, current: %p %i”,

peer, peer->current_weight);

}

再看看failed的部分：

failed:

if (peers->next) {

ngxlog_debug0(NGX_LOG_DEBUG_HTTP, pc->log, 0, “backup servers”);

rrp->peers = peers->next;

n = (rrp->peers->number + (8 * sizeof(uintptr_t) - 1))

/ (8 * sizeof(uintptr_t));

for (i = 0; i < n; i++) {

rrp->tried[i] = 0;

}

ngx_http_upstream_rr_peers_unlock(peers);

rc = ngx_http_upstream_get_round_robin_peer(pc, rrp);

if (rc != NGX_BUSY) {

return rc;

}

ngx_http_upstream_rr_peers_wlock(peers);

}

#if (NGX_HTTP_UPSTREAM_ZONE)

busy:

#endif

ngx_http_upstream_rr_peers_unlock(peers);

pc->name = peers->name;

return NGX_BUSY;

这里就真相大白了，如果连接失败了，就去尝试连下一个，如果所有的都失败了，就会进行quick recovery 把每个peer的失败次数都重置为0，然后再返回一个NGX_BUSY，然后nginx就会打印一条no live upstreams ,最后又回到原始状态，接着进行转发了。

这就解释了no live upstreams之后还能正常访问。

重新看配置文件，如果其中一台有一次失败，nginx就会认为它已经死掉，然后就会把以后的流量全都打到另一台上面，当另外一台也有一次失败的时候，就认为两个都死掉了，然后quick recovery，然后打印一条日志。

2、错误的常见原因

有几个问题可能会触发此错误：

• 后端服务器关闭：所有后端服务器均已关闭或无法访问。
• 配置错误：上游服务器的 NGINX 配置不正确。
• DNS 问题：影响后端服务器地址的 DNS 解析问题。
• 网络问题：NGINX 和后端服务器之间的网络连接问题。

3、诊断错误

请按照以下步骤诊断错误：

1. 检查 NGINX 日志：查找 NGINX 日志中的错误消息。

tail -f /var/log/nginx/error.log

2. 验证后端服务器：确保后端服务器正在运行且可访问。

curl -I http://backend_server

3.检查配置：检查您的 NGINX 配置是否有错误。

cat /etc/nginx/nginx.conf

解决方案 1：重新启动后端服务器

如果后端服务器宕机，请重新启动它们。

systemctl restart backend_service

解决方案 2：修复配置错误

确保 NGINX 中的上游块配置正确。

upstream backend {server backend1.example.com;server backend2.example.com;
}

检查服务器地址是否正确。

解决方案 3：DNS 配置

如果您使用上游服务器的 DNS 名称，请确保 DNS 配置正确。

1.验证 DNS 解析：检查 NGINX 是否可以解析 DNS 名称。

nslookup backend1.example.com

2. 更新 DNS 记录：如果需要，请更新 DNS 记录以确保准确性。

解决方案 4：网络连接

检查 NGINX 和后端服务器之间的网络连接。

1. Ping 后端服务器：测试连通性。

ping backend1.example.com

2. Traceroute：识别网络路径问题。

traceroute backend1.example.com

解决方案 5：使用 max_fails=0 选项

该max_fails指令设置与服务器通信失败的次数，在将服务器视为不可用之前应发生此次数。通过设置max_fails=0，NGINX 将不会将服务器标记为不可用。

更新上游块以包含此选项：

upstream backend {server backend1.example.com max_fails=0;server backend2.example.com max_fails=0;
}

这确保了 NGINX 总是会尝试向上游服务器发送请求，即使它们之前已经失败过。

解决方案 6： keepalive连接数不够，导致大量TIME_WAIT暂用

参考：nginx偶发502 no live upstreams while connecting to upstream-CSDN博客

后台排查nginx后台偶尔大量报错：no live upstreams while connecting to upstream

在nginx服务器上nestat查看

发现存在大量的 TIME_WAIT状态的连接

问题分析

问题表现在nginx与下游服务器的连接出现了异常，在突发流量以后由于TIME_WAIT状态的连接过多导致无法创建足够的连接。

为什么会有如此之多的TIME_WAIT呢？

我的分析是nginx中upstream与下游服务器之间要么是配置的短连接，要么是keepalive 的数量太少了。经过排查发现upstream中并无keepalive相关的配置。

如果nginx与下游服务器连接都是短连接的话，会频繁的创建和断开连接。每次断开连接都会导致连接处于TIME_WAIT一段时间才能被回收掉。
TIME_WAIT状态的持续时间是2MSL，2MSL的是时间还是比较长的，大概几十秒到几分钟。
当流量突增的时候，会出现大量无法回收的连接，最终导致新连接无法创建而报错。

如果nginx与下游服务器配置了长连接，但是upstream中keepalive很小的话也会出问题。

举个极端的例子:

假如nginx最多可以建10000个连接，keepalive的连接数配置的是1000个，即，对空闲连接最多可以维持1000个。空闲连接的回收时间为60秒。

在第一秒突然流量高峰，瞬间建了10000个连接，抗住了压力，没出什么大问题。然后在接下来的60秒，几乎没有什么流量访问，那么在此期间nginx会把9000个空闲连接给断开进行回收。但是回收中的连接会经历2MSL时间的TIME_WAIT。**也就是说在此期间，这9000个连接是无法提供服务的。等到第61秒后，又来了一波流量高峰，需要建10000个连接才能抗住。这时就要出问题了，由于9000个连接无法有效回收，nginx只能拿出1000个连接应对请求，新建连接失败，后台报错。**服务器上存在大量TIME_WAIT状态的连接。

配置修改

为了解决上面的问题，对nginx做了如下的配置调整后，问题解决。

解决方案 7：修改timeout值

nginx部分请求都是502，但是这些请求某些时间段内是正常的，有正常返回结果，已确认后端服务存活，并且是健康的。经排查发现，有个长连接请求是60s，nginx默认请求时间也是60s，超过60s，nginx默认后端服务器已经挂了，然后不再转发请求了，所有这段时间所有请求都是502.

解决办法:修改nginx超时时间，

• proxy_connect_timeout 100s;
• proxy_send_timeout 100s;
• proxy_read_timeout 100s;

解决方案 8： 其他配置，或者使用nginx_upstream_check_module

方案一：根据业务合理设置proxy_connect_timeout，调整fail_timeout、max_fails阈值

将nginx中的proxy_connect_timeout默认超时时间设置大于下游业务最大执行时间。Nginx默认：fail_timeout为10s,max_fails为1次。如果调大，Nginx相当于把请求缓冲，如果整体的的后端服务处于可用状态，对于高并发的场景来说，建议适当调大是有效的。

方案二：优化下游超时接口

方案三：取消fail_timeout、max_fails配置，增加主动检测机制（Nginx默认被动检测），插件包 nginx_upstream_check_module，下面将详细介绍该方案。

官方介绍：https://github.com/yaoweibin/nginx_upstream_check_module

系统问题

基础环境

版本信息

• Centos 7.1
• nginx version: openresty/1.13.6.2

nginx配置信息

stream {server {listen 53 udp;proxy_pass close_stream_backend;}upstream close_stream_backend {server 10.0.1.2:53;server 10.0.1.3:53;}
}

异常问题

20个线程连续压测一分钟后开始交替出现两台目标机器已经宕机（单线程访问没什么问题），出现日志如下所示：

[error] 7184#0: *142585778 no live upstreams while connecting to upstream, udp client: 10.0.1.2, server: 0.0.0.0:53, upstream: "dns", bytes from/to client:40/0, bytes from/to upstream:0/0

主要有两个疑惑点：

• 首先直接访问目标机器，目标机器处于正常访问状态，而且没什么压力；
• 另外一点如果负载均衡目标服务机器两台改为一台反而不会出现这个异常，但是服务所在机器压力非常大；
• 所以怀疑是nginx这台机器除了问题。

分析解决

1. nginx官网查询了下负载均衡策略含义，大概意思是这样的，首先nginx默认的配置为轮询，负载均衡的各个模块组成了一个链表，每次从链表到头开始往后处理，如果连接失败了，就去尝试连下一个，如果所有的都失败了，就会进行quick recovery 把每个peer的失败次数都重置为0，然后再返回一个NGX_BUSY，然后nginx就会打印一条no live upstreams ,最后又回到原始状态，接着进行下次转发。 查看配置文件，如果其中一台有一次失败，nginx就会认为它已经死掉，然后就会把以后的流量全都打到另一台上面，当另外一台也有一次失败的时候，就认为两个都死掉了，就开始打印错误日志。

2. 第一个想到的办法就是增大重试次数和时间，server 10.0.1.2:53 max_fails=5 fail_timeout=60s；把max_fails从1改成5，有一定效果，no live upstreams出现的概率变少了很多，但却没有完全消失。另外压测QPS上不去，还不如单台机器。

3. 于是使用tcpdump -i eth2 udp port 53 -s0 -XXnn，通过wireshark分析后，压力测试工具产生数据已经全部发送到nginx所在机器，但是这台机器没有正确处理。

4. 后来想了下Nginx底层采用的IO多路复用模型epoll，其epoll又是基于linux内核实现，于是看了下/var/log/messages内核日志，于是发现大量如下丢包日志：

   kernel: nf_conntrack: table full, dropping packet.

为了证实问题，再次进行压力数据发送，发现只有再进行压力测试时才会出现这种内核丢包日志。怀疑是服务器访问量大，内核netfilter模块conntrack相关参数配置不合理，最终导致新连接被drop掉。

1. 查看netfilter参数配置sudo sysctl -a | grep conntrack发现65536，于是我直接提升了4倍

   sudo sysctl -w net.netfilter.nf_conntrack_max=262144
   suod sysctl -w net.nf_conntrack_max=262144

执行sudo sysctl -p使其立即生效，再次执行压力测试，发现内核不在出现丢包，nginx也不会出现如上错误日志，问题解决。

总体分析

本文主要通过分析nginx网络请求异常，然后定位为内核参数设置太小导致丢包，最后通过修改内核配置解决，但是conntrack又是什么？搜索之后发现conntrack是针对状态防火墙的。如果有兴趣，请阅读Netfilter的连接跟踪系统。它还包括Netfilter基本的框架。因此conntrack是用来创建记录连接状态以检查流量并避免DDoS安全问题。

另外如上分析问题的过程中，我直接把conntrack值设置为原来的四倍，这样是否合理？碰到这类问题，又该如何设置呢？下面给出一个公式：推荐大小：CONNTRACK_MAX = RAMSIZE (in bytes) / 16384 / (ARCH / 32)。例如，在x86_64 OS中，我有8GB内存，因此我将它设置为8*1024^3/16384/2=262144。

4、预防未来问题

为了避免将来出现此错误，请考虑以下最佳做法：

• 冗余：使用多个后端服务器来防止单点故障。
• 监控：实施监控以尽早发现问题。
• 负载均衡器：使用强大的负载均衡器来有效地管理流量分配。

结论

NGINX 中的“连接到上游时没有实时上游”错误可能会中断您的服务。通过诊断根本原因并应用正确的解决方案，您可以解决此问题并防止将来再次发生。

参考

[Troubleshooting “No Live Upstreams While Connecting to Upstream” Error in NGINX - Akmatori Blog](https://akmatori.com/blog/nginx-no-live-upstreams “Troubleshooting “No Live Upstreams While Connecting to Upstream” Error in NGINX - Akmatori Blog”)

Nginx Bad Gateway和no live upstreams错误分析 | 墨寒轩

压测nginx出现no live upstreams while connecting to upstream的问题分析-腾讯云开发者社区-腾讯云

压测引起的 nginx报错 502 no live upstreams while connecting to upstream解决 - 雪山上的蒲公英 - 博客园

排查Nginx-no live upstreams错误_nginx_lucky猿-GitCode 开源社区

https://xiezefan.me/2017/09/27/nginx-502-bug-trace/