Nginx WebSocket proxying keep getting HTTP 301 redirects

Question

I have been trying to to get the Nginx WebSocket proxy to work for the past few days but for the life of me I couldn't get it to work. I followed the official guide here and have been using Python's websockets module as the server and a npm package wscat as the client. Direct connection from wscat to the Python WebSocket backend is working fine (so is the connection from Browser). But as soon as I layer in Nginx, it's not working and keep giving me a standard HTTP 301 redirect.

cURL debugging output with Nginx proxy:

$ curl 'http://test.ws:8080/websocket' \
> -H 'Pragma: no-cache' \
> -H 'Origin: http://localhost:8080' \
> -H 'Accept-Encoding: gzip, deflate, sdch' \
> -H 'Sec-WebSocket-Version: 13' \
> -H 'Sec-WebSocket-Key: V15bszpaQ+8Vq7mWR6NQbQ==' \
> -H 'User-Agent: Mozilla/5.0' \
> -H 'Upgrade: websocket' \
> -H 'Cache-Control: no-cache' \
> -H 'Connection: Upgrade' \
> -H 'Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits' \
    --compressed -v
* Hostname was NOT found in DNS cache
*   Trying 127.0.0.1...
* Connected to test.ws (127.0.0.1) port 8080 (#0)
> GET /websocket HTTP/1.1
> Host: test.ws:8080
> Accept: */*
> Pragma: no-cache
> Origin: http://localhost:8080
> Accept-Encoding: gzip, deflate, sdch
> Sec-WebSocket-Version: 13
> Sec-WebSocket-Key: V15bszpaQ+8Vq7mWR6NQbQ==
> User-Agent: Mozilla/5.0
> Upgrade: websocket
> Cache-Control: no-cache
> Connection: Upgrade
> Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits
> 
< HTTP/1.1 301 Moved Permanently
* Server nginx/1.8.0 is not blacklisted
< Server: nginx/1.8.0
< Date: Mon, 10 Aug 2015 15:04:26 GMT
< Content-Type: text/html
< Content-Length: 184
< Location: http://test.ws:8080/websocket/
< Connection: keep-alive
< 
<html>
<head><title>301 Moved Permanently</title></head>
<body bgcolor="white">
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx/1.8.0</center>
</body>
</html>
* Connection #0 to host test.ws left intact

cURL debugging output without Nginx proxy:

$ curl 'http://test.ws:8765/' \
> -H 'Pragma: no-cache' \
> -H 'Origin: http://localhost:8080' \
> -H 'Accept-Encoding: gzip, deflate, sdch' \
> -H 'Sec-WebSocket-Version: 13' \
> -H 'Sec-WebSocket-Key: V15bszpaQ+8Vq7mWR6NQbQ==' \
> -H 'User-Agent: Mozilla/5.0' \
> -H 'Upgrade: websocket' \
> -H 'Cache-Control: no-cache' \
> -H 'Connection: Upgrade' \
> -H 'Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits' \
> --compressed -v
* Hostname was NOT found in DNS cache
*   Trying 127.0.0.1...
* Connected to test.ws (127.0.0.1) port 8765 (#0)
> GET / HTTP/1.1
> Host: test.ws:8765
> Accept: */*
> Pragma: no-cache
> Origin: http://localhost:8080
> Accept-Encoding: gzip, deflate, sdch
> Sec-WebSocket-Version: 13
> Sec-WebSocket-Key: V15bszpaQ+8Vq7mWR6NQbQ==
> User-Agent: Mozilla/5.0
> Upgrade: websocket
> Cache-Control: no-cache
> Connection: Upgrade
> Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits
> 
< HTTP/1.1 101 Switching Protocols
* Server Python/3.4 websockets/2.5 is not blacklisted
< Server: Python/3.4 websockets/2.5
< Upgrade: WebSocket
< Connection: Upgrade
< Sec-WebSocket-Accept: yR97tmHAm9KPEI5vfKiM0/sfTqQ=
^C

My Nginx (version 1.8.0) configuration is this (websockets running on test.ws (127.0.0.1) on port 8765) and nginx is listenning on port 8080 on localhost:

worker_processes  1;

error_log  logs/error.log debug;

events {
    worker_connections  1024;
}


http {
    include       mime.types;
    default_type  application/octet-stream;

    sendfile        on;
    keepalive_timeout  65;

    upstream ws {
        server 127.0.0.1:8765;
    }

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

    server {
        listen       8080;
        server_name  test.ws;

        access_log  logs/localhost.access.log;

        location / {
            root   html;
            index  index.html index.htm;
        }

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

        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   html;
        }
    }

}

include servers/*;

Anyone know what did I do wrong here and why is it giving me 301 redirect?

Have you tried changing from location /websocket/ to location /websocket (withtout trailing /)? — Soichi Hayashi, Apr 02 '17 at 17:58

score 8 · Answer 1 · answered Jun 20 '18 at 13:18

8

In my case, it came from the client using path /websocket instead of /websocket/ thereby preventing the location rule to kick in. But the impact of locations order was a good hint!

answered Jun 20 '18 at 13:18

PeeWee2201

1,464
2
15
23

Devy · Answer 2 · 2015-08-10T18:17:21.840

As it turns out, the root location stanza in my Nginx configuration has been interfering with the WebSocket proxy pass tunnel. There are three ways to solve this problem.

Modify the root location stanza to match exactly.

location = / {
    root   html;
    index  index.html index.htm;
}

Re-order the root location stanza to be after the websocket location stanza (specific ones first, general ones last, just like how rewrite matching rule works).
Removing the following root location stanza in the Nginx configuration will make it work.
```
location / {
    root   html;
    index  index.html index.htm;
}
```

Ryan Kopf · Answer 3 · 2017-01-02T08:27:28.213

0

Pay attention to your headers. In the header sent by web browsers and clients, it is Upgrade not upgrade.

change this:

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

to

    location /websocket/ {
        proxy_pass http://ws;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "Upgrade";
    }

Note the capital Upgrade

edited Jan 02 '17 at 08:27

answered Jan 01 '17 at 07:43

Ryan Kopf

404
4
9

4

I don't think this matters. – Soichi Hayashi Apr 02 '17 at 17:57
1

You are right that they are SUPPOSED to be case-insensitive, but in many cases they are not. Many browsers will not accept headers not capitalized. In my case, when using the lowercase "upgrade", nginx would refuse to pass that header along. Changing it to uppercase was the only think that helped. [There's a discussion on Stack Overflow about this](http://stackoverflow.com/questions/5258977/are-http-headers-case-sensitive) – Ryan Kopf Apr 03 '17 at 18:17
Also note, in official usage when it was introduced, the "Upgrade" had to be capitalized. See the [MSDN article](https://msdn.microsoft.com/en-us/hh969243.aspx) – Ryan Kopf Apr 03 '17 at 18:19
It does not make any difference. – bastianwegge Feb 06 '20 at 09:46

Nginx WebSocket proxying keep getting HTTP 301 redirects

3 Answers3