So I've been reading up on this whole server set up in which Nginx is used in front of nodejs as a reverse proxy so that it serves the static content while allowing node to do the dynamic stuff. My question is, why would someone want to use the nginx front to reverse proxy to the websocket? If nginx serves the static content (HTML, CSS, JS, media, etc.) then can't the JS file that is served simply connect to the server directly using the ip address and the port that the websocket is listening on in the nodejs server? Why go through nginx to connect to the websocket on the server? Or am I not understanding this situation clearly? Thank you!

So I've been reading up on this whole server set up in which Nginx is used in front of nodejs as a reverse proxy so that it serves the static content while allowing node to do the dynamic stuff. My question is, why would someone want to use the nginx front to reverse proxy to the websocket? If nginx serves the static content (HTML, CSS, JS, media, etc.) then can't the JS file that is served simply connect to the server directly using the ip address and the port that the websocket is listening on in the nodejs server? Why go through nginx to connect to the websocket on the server? Or am I not understanding this situation clearly? Thank you!

• javascript
• node.js
• nginx

• you get nginx's security model, for one. any (say) ip address/referer restrictions you've set on the main site would also apply to the websocket. – Marc B Commented Jul 27, 2016 at 18:52
• You should read this...stackoverflow./questions/224664/… – JClarke Commented Jul 27, 2016 at 18:57
• @Jclarke sorry for using the term "proxy" I edited my question to use the term "reverse proxy". However, my question still stands.. – TheMAAAN Commented Jul 27, 2016 at 19:22
• 1 The only reason I can think of is load balancing... but what if your not using multiple nodejs servers? Is there still a point to using Nginx as a reverse proxy for the websocket connection besides what @MarcB has pointed out? – TheMAAAN Commented Jul 27, 2016 at 19:25

2 Answers 2

A WebSocket application keeps a long-running connection open between the client and the server, facilitating the development of real-time applications. The HTTP Upgrade mechanism used to upgrade the connection from HTTP to WebSocket uses the Upgrade and Connection headers. There are some challenges that a reverse proxy server faces in supporting WebSocket. One is that WebSocket is a hop-by-hop protocol, so when a proxy server intercepts an Upgrade request from a client it needs to send its own Upgrade request to the backend server, including the appropriate headers. Also, since WebSocket connections are long lived, as opposed to the typical short-lived connections used by HTTP, the reverse proxy needs to allow these connections to remain open, rather than closing them because they seem to be idle.

NGINX supports WebSocket by allowing a tunnel to be set up between a client and a backend server. For NGINX to send the Upgrade request from the client to the backend server, the Upgrade and Connection headers must be set explicitly, as in this example:

location /wsapp/ {
    proxy_pass http://wsbackend;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
}

Once this is done, NGINX deals with this as a WebSocket connection.

For more details please visit:- https://www.nginx./blog/websocket-nginx/ https://blog.martinfjordvald./2013/02/websockets-in-nginx/

Hope this would help!

One reason I could think of is that Nginx gives you more flexibility and customizations like load balancing, ratelimiting, etc.