"So let us say that you are developing a Node.js / Socket.IO application that both uses websockets and serves files the old-fashioned way, such as through Express - this is a fairly common situation. You want to have an HTTP proxy server rather than Node.js field all incoming traffic, so that you can set up load balancing, route requests for static files to some other server process, avoid having to set up SSL configuration in Node.js, and so forth.
"Unfortunately at this point in time it isn't completely straightforward to proxy both websocket traffic and ordinary web requests for Node.js through a single port - which would be the ideal situation. It becomes even less straightforward if you want to use SSL. The following is a brief overview of present options as of early Q3 2012."
"The up-front summary: if you are reading this after Nginx adds support for proxying websocket traffic to Node.js (supposedly coming up in version 1.3), then everything is rainbows and unicorns - just use Nginx. If you are reading this prior to Nginx support for proxying of websocket traffic, then you will likely have to do more work and investigation in order to create a good proxy setup for your servers."
Sorry if this is obvious, but you need it when nginx is your front-end and you want to use web sockets without exposing your backend. A lot of people deploy nginx in their DMZ because of its security and don't want to expose their backend servers, e.g. JEE or Ruby or what have you.
AFAIK there aren't that many robust approaches for reverse proxying web sockets. Apache mod_proxy doesn't work with web sockets, nginx (until now) only worked with websockets if you compiled and patched an unstable dev branch yourself, and not everyone was happy to get their hands dirty with HAProxy. An alternative was to build your own reverse proxy in Node.JS using node-http-proxy, but again, not everyone's cup of tea.
Use cases of websockets enabled reverse proxies are for when you have a number of websockets based apps all sitting on the same box or in the same private local network and you need a way to route incoming traffic to them based on the hostname or path or whatever.
Now you won't need a separate reverse proxy for Websockets. That also means, with just nginx, now you can have both websocket and http on the same url subdomain (for same origin policy and sharing ssl certificate etc).
