最近遇到了nginx疯狂抛错，access.log一天一共5W多条，但error.log中有大概9K多条，基本都是111: Connection refused，这到底是为什么呢？
从日志看起
我们还是先来看日志。我提取了一条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代替，感觉还是不错的。
有兴趣的话可以关注我的公众号，说不定会有意外的惊喜。
