If you’re using Socket.io and want to reverse proxy your web socket connections, you’ll quickly find it’s somewhat difficult. Since web sockets are done over HTTP 1.1 connections (where the handshake and upgrade are completed), your backend needs to support HTTP 1.1, and from what I have researched, they break the HTTP 1.0 spec (see this discussion at stackoverflow).
Some people have been able to get HAProxy to work for effective proxying of websocket connections, but I couldn’t get this to work reliably when I tried the latest version and TCP mode.
If you’re using nginx, you won’t be able to proxy web socket connections using the standard nginx proxy_pass directives. Fortunately, Weibin Yao has developed a tcp proxy module for nginx that allows you to reverse proxy general tcp connections, especially well suited for websockets.
Let’s get a simple web socket proxy up and running. Download nginx sources and tcp_proxy module:
Compile Nginx with tcp_proxy module
Create a simple vhost like the following (note tcp must be defined at the server directive level):
You’ll notice there is an additional http section, with a check_status directive. The tcp_proxy module provides a simple and convenient status check page which you can use to see if your backend node processes are up:
Create a Simple Websocket Server
Start four node processes, each listening on different ports:
You should now check your status page to verify all backends are up and running:
You can also go to our proxy via standard http (web browser) and correctly see “Hello World” to verify we’re hitting one of our node backends.
Test Websocket Proxying
Now lets create a simple web socket client to test if we can actually create a websocket connection over the proxy:
For simplicity, I used a node static page server to serve this test page from the same node process and attached my Socket.IO instance to it:
Now, when we run our node instances:
And when we go to http://localhost, we can see successful websocket handshakes (which means we’re going over the nginx proxy):
Using this method you can successfully balance a cluster of web socket nodes, with some simple failure provided by the tcp_proxy module. Depending on the need and placement of nginx within your specific application stack, the ability to use this instead of something like HAProxy or some other balancer strategy could allow scaling many more connections per server without introducing significant complexity.
One thing that should be noted is you can no longer guarantee that a client will always connect to the same node process, like in the event of disconnection, so your application will need to understand this and implement session management across the cluster (such as using a redis or memcache session store, for example).