nodejs+socket.io用nginx反向代理提示400 Bad Request及ws://…沒法鏈接的解決方法

在nginx反向代理k8s中weave scope的時候出現400 bad request

 

proxy_http_version 1.1;

proxy_set_header Upgrade $http_upgrade;

proxy_set_header Connection "upgrade";

 

Nginx擔當WebSockets代理

WebSocket 協議提供了一種建立支持客戶端和服務端實時雙向通訊Web應用程序的方法。做爲HTML5規範的一部分，WebSockets簡化了開發Web實時通訊程序的難度。目前主流的瀏覽器都支持WebSockets，包括火狐、IE、Chrome、Safari以及Opera等，並且，愈來愈多的服務器應用框架也開始支持WebSockets。

要在企業產品中使用WebSockets，爲知足高性能和高可用性，須要多個WebSocket服務器。負載均衡層須要支持WebSocket協議。Nginx從1.3版起就開始支持WebSocket協議，並且能夠擔當WebSocket應用程序的反向代理以及實現負載均衡。

WebSocket協議和HTTP協議不一樣，可是WebSocket協議的握手和HTTP是兼容的，它使用HTTP的Upgrade協議頭將鏈接從HTTP鏈接升級到WebSocket鏈接。這個特性使得WebSocket應用程序能夠很容易地應用到現有的基礎設施。例如，WebSocket應用可使用標準的80和443 HTTP端口，所以能夠經過現有的防火牆設施。

WebSockets應用程序會在客戶端和服務器之間創建一個長鏈接，使得開發實時應用很容易。HTTP的Upgrade協議頭機制用於將鏈接從HTTP鏈接升級到WebSocket鏈接，Upgrade機制使用了Upgrade協議頭和Connection協議頭。反向代理服務器在支持WebSocket協議方面面臨着一些挑戰。挑戰之一是WebSocket是一個逐段轉發（hop-by-hop）協議，所以當代理服務器攔截到來自客戶端的Upgrade請求時，代理服務器須要將本身的Upgrade請求發送給後端服務器，包括適合的請求頭。並且，因爲WebSocket鏈接是長鏈接，與傳統的HTTP端鏈接大相徑庭，故反向代理服務器還須要容許這些鏈接處於打開（Open）狀態，而不能由於其空閒就關閉了鏈接。

Nginx經過在客戶端和後端服務器之間創建隧道來支持WebSockets通訊。爲了讓Nginx能夠未來自客戶端的Upgrade請求發送到後端服務器，Upgrade和Connection的頭信息必須被顯式的設置。以下所示：

Nginx WebSockets 實例

下面的例子講述了Nginx是如何爲WebSocket作代理的。此例將使用ws模塊，它是基於node.js構建的WebSocket實現。Nginx將擔當反向代理服務器，後端服務器是一個使用了ws和Node.js的簡單WebSockets應用。例子使用的命令在Ubuntu 13.10和CentOS 6.5上測試經過，但對於其餘操做系統或許須要稍做修改。就這個例子來講，WebSocket服務器的IP地址是192.168.100.10，Nginx服務器的IP地址是192.168.100.20。若是你尚未安裝node.js和npm，你能夠經過如下命令安裝：