Issue with websocket connection using nginx

Initially when I set up Mattermost on Debian, I used the default nginx configuration file that was shown in the production install instructions:

 server {
    server_name mattermost.example.com;
    location / {
        client_max_body_size 50M;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $http_host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header   X-Frame-Options   SAMEORIGIN;
        proxy_pass http://localhost:8065;
    }
  }

However, when I reloaded nginx I started getting 400 errors from the websocket requests:

[19/Oct/2015:12:54:26 +0000] "GET /api/v1/websocket HTTP/1.1" 400 161 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.101 Safari/537.36"

and seeing this message when I connected to the service:

We cannot reach the Mattermost service. The service may be down or misconfigured. Please contact an administrator to make sure the WebSocket port is configured properly.

I found the following post: Setup behind nginx - #6 by pbruna that suggests a slightly different nginx configuration which I followed to create this:

server {
   listen 80;
   server_name mattermost.<domain>;

   location / {
      client_max_body_size 50M;
      proxy_set_header Host $http_host;
      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header X-Forwarded-Proto $scheme;
      proxy_set_header X-Frame-Options SAMEORIGIN;
      proxy_pass http://localhost:8065;

      # websocket support
      proxy_http_version 1.1;
      proxy_set_header Upgrade $http_upgrade;
      proxy_set_header Connection "upgrade";
   }

   location /api/v1/websocket {
     proxy_pass http://localhost:8065;
     proxy_http_version 1.1;
     proxy_set_header Upgrade $http_upgrade;
     proxy_set_header Connection "upgrade";
   }

   keepalive_timeout 10;
}

now I am not getting 400s but 101s instead:

[19/Oct/2015:14:38:31 +0000] "GET /api/v1/websocket HTTP/1.1" 101 12 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.101 Safari/537.36"

and still on the channel that I have created the following message shows:

We cannot reach the Mattermost service. The service may be down or misconfigured. Please contact an administrator to make sure the WebSocket port is configured properly.

Any thoughts on what could be going on here?

Does it work in any other browsers?

Not that I can see, we have people connecting from Firefox, Chrome, and Safari. The short term solution was to disable webhooks, this is non-ideal because we can’t create any cool integrations.

What happens when you comment out the instances of “proxy_http_version 1.1;” in your config file?

https://gitlab.com/gitlab-org/omnibus-gitlab/issues/740

I think your issue might be resolved by following the directions in this link.

Still seeing the same 102 status with the upgrade block from that post.

Wait. A 101 or a 102? did it change on you? 102 has to do with webdav timing out. 101 should be okay, its just the server acknowledging that you are switching protocols (which is probably not desired)

Sorry, 101. That was a typo. I think there could be an underlying network issue. I am going to rebuild everything from scratch.

Good idea. I was going to suggest looking at your root /etc/nginx/nginx.conf file to see if there is a conflicting http version setting