谁能想到Nginx 502问题居然是因为它

上一篇文章说了502问题，看着满屏的502错误，很是困惑，502发生的时候proxy很快就响应了，nginx日志也看不出什么问题，这时候真不知道怎么办了！

然后自己就对着日志发呆：

2023/11/07 14:41:53 [error] 28863#28863: *80920 no live upstreams while connecting to upstream, client: 123.11.2.217, server: _, request: "POST /v1/ HTTP/1.1", upstream: "https://api.test.com/v1/", host: "47.251.43.233"

server: 后面是个_符号？why？下面的日志也很类似，为什么to的是api.test.com：

[09/Nov/2023:09:57:42 +0000] 123.11.2.217 - - - _ 10.18.239.6 to: api.test.com: POST /v1/ HTTP/1.1 502 upstream_response_time 0.000 msec 1699523862.887 request_time 0.000
[09/Nov/2023:09:57:45 +0000] 123.11.2.217 - - - _ 10.18.239.6 to: api.test.com: POST /v1/ HTTP/1.1 502 upstream_response_time 0.000 msec 1699523865.070 request_time 0.000

正常的200请求是ip地址：

[10/Nov/2023:05:55:30 +0000] 123.11.2.217 - - - _ 10.18.239.6 to: 114.18.17.192:443: POST /v1/ HTTP/1.1 200 upstream_response_time 50.060 msec 1699595730.337 request_time 50.061

难道是域名解析失败！！！！，此时内心很激动，大概率觉得就是这个原因导致的。

快速的找个解决方案验证下，先查看本地的DNS解析配置：

cat /etc/resolv.conf

直接修改host文件，/etc/hosts：

123.11.2.217 api.test.com

reload nginx，发现502没有了，这种方案简单粗暴，因为如果域名解析的ip变更了就会存在问题，所以可以采用下面这种方案，换一个dns解析，比如：

location / {
    resolver 8.8.8.8;
    proxy_pass http://api.test.com; 
}

这种方案的性能没有第一个好，多了层解析。

可为什么在debug日志中没有发现蛛丝马迹呢？因为nginx直接使用的c基础函数，没有太多的debug信息，见ngx_connection.c文件：

if (getsockname(c->fd, &sa.sockaddr, &len) == -1) {
      ngx_connection_error(c, ngx_socket_errno, "getsockname() failed");
      return NGX_ERROR;
}

谁能想到，问题解决居然日常简单！