Node, ws, ssl, nginx giving error 426, upgrade needed

Question

I am serving an app using Node.js and NGINX. I am securing NGINX with LetsEncrypt, and running my node app on server with pm2 (using NGINX as a reverse proxy).

My site will not load anything (426 error - upgrade required), but I can connect with the following scratchpad:

var port = 443;
var ws = new WebSocket("wss://mywebsite.com:" + port);

ws.onopen = function() {
  console.log("Connected");
}

ws.onmessage = function(comment) {
  console.log(JSON.parse(comment.data));
}

Here is the NGINX setup:

server {

        root /var/www/html;

        # Add index.php to the list if you are using PHP
        index index.html index.htm index.nginx-debian.html;

        server_name mywebsite.com www.mywebsite.com;

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

    listen [::]:443 ssl ipv6only=on; # managed by Certbot
    listen 443 ssl; # managed by Certbot
    ssl_certificate /path/to/cert; # managed by Certbot
    ssl_certificate_key /path/to/key; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot


}
server {
    if ($host = www.mywebsite.com) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


    if ($host = mywebsite.com) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


        listen 80 default_server;
        listen [::]:80 default_server;

        server_name mywebsite.com www.mywebsite.com;
    return 404; # managed by Certbot
}

My client code is basically identical to the scratchpad. This is the relevant server-side code:

var WebSocket = require('ws');
var serverPort = 8080;
var wss = new WebSocket.Server({port:serverPort});
console.log("Server running on port " + serverPort + " started at: " + new Date());

wss.on('connection', function(ws) {

        console.log("Connected to websocket: " + ws);
        var introComment = JSON.stringify({
                user: "Welcome!",
                data: {
                        body: "Welcome to the realtime feed!",
                        name: "realtime-intro-connection-message",
                },

        });
        ws.send(introComment);
});

These are the response headers the browser receives:

HTTP/1.1 426 Upgrade Required
Server: nginx/1.10.3 (Ubuntu)
Date: Wed, 23 May 2018 19:20:36 GMT
Content-Type: text/plain
Content-Length: 16
Connection: keep-alive

I read that there should be an "Upgrade" header, is that part of the problem?

Answer 1

To turn a connection between a client and server from HTTP/1.1 into WebSocket, the protocol switch mechanism available in HTTP/1.1 is used.

There is one subtlety however: since the “Upgrade” is a hop-by-hop header, it is not passed from a client to proxied server. With forward proxying, clients may use the CONNECT method to circumvent this issue. This does not work with reverse proxying however, since clients are not aware of any proxy servers, and special processing on a proxy server is required.

Since version 1.3.13, nginx implements special mode of operation that allows setting up a tunnel between a client and proxied server if the proxied server returned a response with the code 101 (Switching Protocols), and the client asked for a protocol switch via the “Upgrade” header in a request.

As noted above, hop-by-hop headers including “Upgrade” and “Connection” are not passed from a client to proxied server, therefore in order for the proxied server to know about the client's intention to switch a protocol to WebSocket, these headers have to be passed explicitly:

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

A more sophisticated example in which a value of the “Connection” header field in a request to the proxied server depends on the presence of the “Upgrade” field in the client request header:

http {
    map $http_upgrade $connection_upgrade {
        default upgrade;
        ''      close;
    }

server { ...

    location /chat/ {
        proxy_pass http://backend;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
    }
}

Answer 2

I never really found the answer to this, so I changed my tactics:

I moved from ws (npm's websockets) to socket.io. This seems to be more widely supported. For an example app using socket.io, look here at these great videos! Everything now works fine.