-
Notifications
You must be signed in to change notification settings - Fork 5.9k
[Bug]: 'Error: WebSocket close with status code 1006' behind nginx proxy #6023
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
It looks like it is using 80 because you are accessing the website over |
Thanks for your replay @code-asher
code-server --log=debug --port 9997
|
Is this a self-signed certificate? Some browsers (like Chrome,
not sure about Edge though) will have trouble connecting web
sockets with self-signed certificates. If you see something like
a gray or green lock then you should be OK but if not you may need
to either get a certificate signed by a CA or trust the
certificate on your local machine (you can do this manually or
install mkcert to do it for you).
You might also want to check NGINX's logs and code-server's output
just in case it is an error on the server side rather than the
browser.
|
Yes, it is a self-signed certificate generated by OpenSSL
|
I have tried the following two methods:
but neither of them worked. Is it because the the output logs of the Edge: |
Sorry for the delayed response.
You will need port 443 open on the machine running NGINX.
But you said you access via `https://${myhost}/code/` right? That
means you are already accessing through port 443 so it should
already be open. Both https:// and wss:// default to port 443.
Interesting that there are no error logs from NGINX, that does
suggest it might still be a certificate issue. Did you update
NGINX to use the certificates generated by mkcert?
|
Hi, Due to security concerns, the administrator of the host machine will not allow WebSocket forwarding requests. Are there any alternative solutions? |
Ahh that makes sense!
There is currently no way to use code-server without web sockets
so you would need to figure out some other way to get the web
sockets to connect.
For example if you are able to use SSH you could access
code-server through an SSH tunnel.
```
ssh -N -L 8080:127.0.0.1:8080 [user]@<instance-ip>
```
Then visit `localhost:8080`.
|
Unfortunately, the direct SSH connection to the remote host has also been blocked by the administrator (requiring connection through a jump host and do some authentication), so SSH tunnel won't work. |
I can confirm that this issue is present since 4.10.1. |
@SimonTod 4.10.1 added a security check that uses the host and origin headers; do you have code-server behind a reverse proxy and does it forward the host header? |
In my installation with Nginx-Proxy the following works with 4.11.0 location / {
|
That makes sense but do keep in mind that if you are always
setting the origin to the host then you are bypassing the security
check.
However the exploit only happens on older browsers that do not
support SameSite cookies and attacks across sub-domains that share
the same root domain so if neither of these apply to you then
there should be no problem.
|
@TomBraun02 solution worked for me, even though if it's not secure I would like to find a way to not bypass the check |
Just released 4.12.0 with some debug logs, running with `--log
debug` should show why the requests are being blocked.
|
Might need to use |
@code-asher Thanks a lot. I had this next line missing in my reverse proxy config
and this next one had to be commented
|
Ahh, that makes sense, |
I think you will have to set `trusted_proxies` in the LAN Caddy so
it trusts the `X-Forwarded-*` headers from the WAN Caddy and
passes them along rather than overriding them.
https://caddyserver.com/docs/caddyfile/directives/reverse_proxy#defaults
|
Thanks for your help! After a few more debugging and testing, it finally worked, that's really saved my day! Keep the network topology AS SIMPLE AS YOU CAN to avoid hard-to-locate errors. Or, if you have to set a relatively complex cases that are not directly connected to code-server using one layer Caddy's reverse_proxy, just like mine, then, switch on all debug logs available during the whole route to locate the main issue. For me, some lack of network knowledge I guess led me to not accurately understand the default behavior of how caddy deal with requests. Besides the after setting it, the To fix that, I edit the Caddyfile of my WAN caddy, replace the After reloading, everything worked. Remember to switch off those debug to set a production state! Hope this helped XD. |
Whoops, ignore my last message if you saw it. I replied to the wrong email. Glad you got it working! |
This works for me (yay) but I was wondering if there is a way to do it securely? As someone in this thread mentioned it could pose a security risk. Or am I just being thick... Thanks for this tho 🙏 (edit) |
Yeah the config in the docs is good. You want to avoid setting Lines 195 to 197 in 3e8100b
|
Is there the docs link?🙏 |
Closing since I think we ended up not finding anything in code-server that needs to be changed. |
Is there an existing issue for this?
OS/Web Information
code-server --version
: 4.6.0Steps to Reproduce
proxy with nginx:
run code-server
${myhost}/code/
Expected
Code server opens up to home screen.
Actual
error log:

Logs
Screenshot/Video
No response
Does this issue happen in VS Code or GitHub Codespaces?
Are you accessing code-server over HTTPS?
Notes
Why does code-server create a websocket connection with port 80? And how can this issue be solved?
The network environment of the host machine:
The port 80 has been disabled by the administrator of the host machine, only a few ports are open.
The text was updated successfully, but these errors were encountered: