[GH-ISSUE #590] Having trouble with websockets #390

New issue

Closed

opened 2026-03-03 01:28:40 +03:00 by kerem · 3 comments

kerem commented

2026-03-03 01:28:40 +03:00

Owner

Originally created by @grahamPegNetwork on GitHub (Aug 28, 2019).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/590

Hello there, great work on the server. I've been reading through the getting started info as well as past issues and seem to be stuck. Overall the server is working great, is way easier to get set up and is super lightweight. My only hangup is sync triggers.

Mobile: I see there isn't much we can do about that, I can live with that for now.
Extension: It seems that it is supposed to connect through websockets but fails silently.
Browser Vault: I see what I presume to be websocket failure errors in the browser console, though I can't find anything matching when I search:
Firefox can’t establish a connection to the server at wss://(redacted)/notifications/hub?id=XYZ==&access_token=XYZABC. WebSocketTransport.js:85 [2019-08-28T06:53:11.866Z] Error: Failed to start the transport 'WebSockets': null Utils.js:203 [2019-08-28T06:53:11.868Z] Error: Failed to start the connection: Error: Unable to initialize any of the available transports.

My setup:

Docker-compose with the following relevant info:
ports: 6062:80 6063:3012 environment: WEBSOCKET_ENABLED: "true"

Nginx reverse proxy with certbot/letsencrypt SSL on the host:

server {
        listen 443 ssl http2; # managed by Certbot
        listen [::]:443 ssl http2; # managed by Certbot
        server_name (redacted);

        client_max_body_size 128M;

        location / {
                proxy_pass http://127.0.0.1:6062;
                proxy_set_header Host $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;
        }
        location /notifications/hub {
                proxy_pass http://127.0.0.1:6063;
                proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection "upgrade";
        }
  
        location /notifications/hub/negotiate {
                proxy_pass http://127.0.0.1:6062;
        }
(snipped Certbot stuff: Certificate setup, redirecting 80 to 443, the usual)
}

I have verified that websockets are (supposed to be) offered on 3012 which Docker provides on the host as 6063. Docker also offers 80 through port 6062. Both ports are handled by nginx with a config nearly identical to the example in the reverse proxy section.
When I navigate to (domain)/notifications/hub I receive a message indicating that websockets are active:
WebSocket Protocol Error: Unable to parse WebSocket key.

At the end of the day, it appears that all traffic/ports are being routed properly, however the browser extension and web vault are unable to connect. What can I do to debug/resolve this?

Thanks in advance! Everything else works great and probably took 10% of the time to set up that vanilla BitWarden did.

Originally created by @grahamPegNetwork on GitHub (Aug 28, 2019). Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/590 Hello there, great work on the server. I've been reading through the getting started info as well as past issues and seem to be stuck. Overall the server is working great, is way easier to get set up and is super lightweight. My only hangup is sync triggers. Mobile: I see there isn't much we can do about that, I can live with that for now. Extension: It seems that it is supposed to connect through websockets but fails silently. Browser Vault: I see what I presume to be websocket failure errors in the browser console, though I can't find anything matching when I search: `Firefox can’t establish a connection to the server at wss://(redacted)/notifications/hub?id=XYZ==&access_token=XYZABC. WebSocketTransport.js:85 [2019-08-28T06:53:11.866Z] Error: Failed to start the transport 'WebSockets': null Utils.js:203 [2019-08-28T06:53:11.868Z] Error: Failed to start the connection: Error: Unable to initialize any of the available transports.` # My setup: Docker-compose with the following relevant info: `ports: 6062:80 6063:3012 environment: WEBSOCKET_ENABLED: "true"` Nginx reverse proxy with certbot/letsencrypt SSL on the host: ``` server { listen 443 ssl http2; # managed by Certbot listen [::]:443 ssl http2; # managed by Certbot server_name (redacted); client_max_body_size 128M; location / { proxy_pass http://127.0.0.1:6062; proxy_set_header Host $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; } location /notifications/hub { proxy_pass http://127.0.0.1:6063; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; } location /notifications/hub/negotiate { proxy_pass http://127.0.0.1:6062; } (snipped Certbot stuff: Certificate setup, redirecting 80 to 443, the usual) } ``` I have verified that websockets are (supposed to be) offered on 3012 which Docker provides on the host as 6063. Docker also offers 80 through port 6062. Both ports are handled by nginx with a config nearly identical to the example in the reverse proxy section. When I navigate to (domain)/notifications/hub I receive a message indicating that websockets are active: `WebSocket Protocol Error: Unable to parse WebSocket key.` At the end of the day, it appears that all traffic/ports are being routed properly, however the browser extension and web vault are unable to connect. What can I do to debug/resolve this? Thanks in advance! Everything else works great and probably took 10% of the time to set up that vanilla BitWarden did.

kerem closed this issue

2026-03-03 01:28:40 +03:00

kerem commented

2026-03-03 01:28:40 +03:00

Author

Owner

@mprasil commented on GitHub (Aug 30, 2019):

The configuration looks OK to me. Usually I suspect that this is not actually the configuration used or there is some extra configuration somewhere that might override some bit. Can you maybe try to strip down the configuration to bare minimum and see if that helps?

@mprasil commented on GitHub (Aug 30, 2019): The configuration looks OK to me. Usually I suspect that this is not actually the configuration used or there is some extra configuration *somewhere* that might override some bit. Can you maybe try to strip down the configuration to bare minimum and see if that helps?

kerem commented

2026-03-03 01:28:41 +03:00

Author

Owner

@mprasil commented on GitHub (Oct 11, 2019):

No response, so hopefully you managed to resolve the problems. If not feel free to reopen.

@mprasil commented on GitHub (Oct 11, 2019): No response, so hopefully you managed to resolve the problems. If not feel free to reopen.

kerem commented

2026-03-03 01:28:41 +03:00

Author

Owner

@grahamPegNetwork commented on GitHub (Oct 21, 2019):

Hi, thanks for the response, apologies for not responding before.

Over the last month or so I did migrate to a VPS from my overly complicated dedicated server for better performance and security. It would appear that during that transition the issue has worked itself out. When checking the web vault I can see websocket connected in the console, and the extension appears to sync within a second or so of updating an item so I'm just assuming everything is working properly at this point.

Again, great work, on the implementation, I'm a big fan!

@grahamPegNetwork commented on GitHub (Oct 21, 2019): Hi, thanks for the response, apologies for not responding before. Over the last month or so I did migrate to a VPS from my overly complicated dedicated server for better performance and security. It would appear that during that transition the issue has worked itself out. When checking the web vault I can see websocket connected in the console, and the extension appears to sync within a second or so of updating an item so I'm just assuming everything is working properly at this point. Again, great work, on the implementation, I'm a big fan!