Nginx Reverse Proxy for WebSocket

nginx-websocket-proxy.conf

upstream websocket {
    server localhost:3000;
}

server {
    listen       80;
    server_name  localhost;

    access_log  /var/log/nginx/websocket.access.log  main;

    location /socket.io/ {
        proxy_pass http://websocket;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }

    location /socket.io/socket.io.js {
        proxy_pass http://websocket;
    }

    location /sample.html {
        root   /usr/share/nginx/html/;
    }
}

Very useful!

I agree !

It works. *****

Why are you using http:// protocol instead of ws:// for the proxy_pass direction URL?

Very useful +1!

+1 Greeeeeaaaaaaaaat!!!!!

@isaackg wondering this too. Did you find out?

@isaackg & @CoreyCole Nginx would complain about invalid URL prefix.

nginx: [emerg] invalid URL prefix in /usr/local/etc/nginx/nginx.conf:75

@isaackg @CoreyCole It's because ws:// doesn't mean anything in this context. ws:// is a protocol built on top of http://.

@isaackg @CoreyCole It's because ws:// doesn't mean anything in this context. ws:// is a protocol built on top of http://.

not according to wikipedia https://en.wikipedia.org/wiki/WebSocket

Should it be put inside http {} block ?

anybody experiencing timeouts after 1-2 minutes?
Getting a "The remote party closed the WebSocket connection without completing the close handshake" on the server side behind NGINX. Apparently timeout is required but not seeing a difference.

Thanks for saving my day

INCREDIBLE thank you a lot

@ms4720 ws:// is a valid protocol (according to WikiPedia and IETF) but it's a protocol built on top of HTTP. Just like HTTP is "TCP used in a certain way", WebSockets are "HTTP used in a certain way". Specifically the server sends response headers and then leaves the connection open so that the client and server can pass messages back and forth on the (pre-established) TCP connection without the overhead of a new TCP handshake or additional HTTP headers.

nginx doesn't understand the ws:// scheme. It's designed as an HTTP proxy, so it expects all traffic to be either HTTP or HTTPS. Therefore as far as nginx is concerned, ws:// is just http:// but handled in a funny way and wss:// is just https:// but handled in a funny way. As for the "handled in a funny way" bit, support for that (specifically support for the Upgrade and Connection headers) was added to nginx in v1.13

If nothing else, just think of it as a quirk of nginx's implementation

I wish I had the same luck as everyone else commenting in getting this to work :( I tried setting up an nginx reverse websocket proxy and it kept closing my connection immediately (not after 1 minute, but immediately). I created a StackOverflow post about it, but never got any answers.

@stevendesu check out https://www.nginx.com/blog/websocket-nginx/

@mlakes-sigsci That's actually where I started with getting it set up :) After that I trolled around the internet and found all sorts of blog posts, forum posts, StackOverflow posts, etc. with tips to get it working, and it never did.

I later spun up a simple NodeJS WebSocket server and it worked fine, so it was some quirk of the web server that was preventing a reverse proxy -- not an issue with nginx. Instead of diagnosing the problem and figuring it out, we ended up ignoring the problem and finding another solution to our actual issue (I was using a reverse proxy to add a valid SSL certificate to a server being managed by someone else - we just got them to install a valid SSL cert so the proxy wasn't necessary)

@stevendesu 👍

Thanks!! work perfectly with cloudflare + aws + nginx
This solves CORS problems