nginx報錯111: Connection refused

• 2019 年 11 月 3 日
• 筆記

最近遇到了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代替，感覺還是不錯的。