nginx报错111: Connection refused

原创
2019/09/18 10:03
阅读数 4.7K

最近遇到了nginx疯狂抛错,access.log一天一共5W多条,但error.log中有大概9K多条,基本都是111: Connection refused,这到底是为什么呢?

<!-- more -->

从日志看起

我们还是先来看日志。我提取了一条error.log当中抛错的日志(稍微分一下行,否则实在太长,敏感信息稍微处理了一下):

2019/06/06 10:09:45 [error] 28652#0: *883239 connect() failed (111: Connection refused) while connecting to upstream, 
client: 124.104.90.145, server: xxx.xxxxx.com, request: "POST /test-service/upload?mcachenum=155978698 HTTP/1.1", 
upstream: "http://[::1]:17000/test-service/upload?mcachenum=155978698", host: "xxx.xxxxx.com", 
referrer: "https://servicewechat.com/x98b46f69/2/page-frame.html"

看了一下前面的报错和后面的描述,第一眼看上去感觉都是正常。但再看之后发现,upstream中的host有些不一样。[::1],这实际是一个IPv6的地址。

这时候你可以查看一下你的机器是否开启了IPv6的地址,linux的命令是:ip address,看看返回结果中是否出现了inet6,如果有,那么恭喜你,原因找到了。

解决办法

解决方法有两种,一个是禁用你机器的IPv6配置,另一个则是修改nginx.conf中的配置。

个人觉得后一个方法更加保险一些,因为这不涉及到你的机器配置,应该相对而言最少。

nginx.conf的修改,则是针对server模块中的location,修改proxy_pass中的host,我们在网上经常看到别人用的是:

proxy_pass http://localhost:18000/test-service/;

但为了强制指定IPv4的地址,需要变成:

proxy_pass http://127.0.0.1:18000/test-service/;

这样操作之后,再观察nginx的error.log,应该就不会再报upstream里含有IPv6地址的错误了。

总结

以上就是我这次错误的整个过程,虽然整个过程不长,但确实让我知道了,作为一个后端开发,我的知识面还是太窄了。而且Bing也是真的好用,最近无法翻墙了,暂时用Bing代替,感觉还是不错的。

有兴趣的话可以关注我的公众号,说不定会有意外的惊喜。

展开阅读全文
打赏
0
0 收藏
分享
加载中
更多评论
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部