if it's only happening with one user, it sounds like there's something specific to the user's machine that must be causing this behavior. Odd that the header would be stripped from the request. Is the user's desktop client up to date?
Here's something to consider: check to see if the client is actually sending the "upgrade" header. The easiest way to do this is either through Firebug OR through the "Live HTTP Headers" extensions for firefox. Here's an example of what my client produces when attempting to establish a connection to the web socket.
GET /api/v3/users/websocket HTTP/1.1
Host: mattermost.example.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Sec-WebSocket-Version: 13
Origin: http://mattermost.example.com
Sec-WebSocket-Extensions: permessage-deflate
Sec-WebSocket-Key: UbRTgCWQQoPkqcWcGnsZHA==
Cookie: _ga=GA1.2.103658428.1458591402; __utma=87737482.103658428.1458591402.1458591411.1458591411.1; __utmz=87737482.1458591411.1.1.utmcsr=careers.caci.com|utmccn=(referral)|utmcmd=referral|utmcct=/; MMAUTHTOKEN=bngkb16d6pyqmffukcoaep6quw
Connection: keep-alive, Upgrade
Pragma: no-cache
Cache-Control: no-cache
Upgrade: websocket
HTTP/1.1 101 Switching Protocols
Upgrade: Websocket
Sec-WebSocket-Accept: f/vZdmO8Y0MLbc8Zta7C1Mq+BvU=
X-Powered-By: ARR/3.0, ASP.NET
Connection: Upgrade
Access-Control-Allow-Origin: *
Date: Wed, 07 Sep 2016 14:19:36 GMTDo you see the client producing the header?