code-server: code-server 4.0.0 behind nginx reports wrong port

Using the following nginx configuration (fragment) in combination the SSL and code server reports port 80 in code-server instead of 443/https?

    location / {
      proxy_pass http://localhost:8080/;
      proxy_set_header Host $host;
      proxy_set_header Upgrade $http_upgrade;
      proxy_set_header Connection upgrade;
      proxy_set_header Accept-Encoding gzip;
    }

About this issue

Original URL
State: closed
Created 3 years ago
Comments: 15 (12 by maintainers)

Commits related to this issue

Set remote authority on frontend (#25) Trying to determine the remote authority on the backend is brittle because it does not work behind reverse proxies unless they send the right headers containi... — committed to coder/vscode by code-asher 3 years ago
Update VS Code Fixes https://github.com/cdr/code-server/issues/3410 Fixes https://github.com/cdr/code-server/issues/4604 Fixes https://github.com/cdr/code-server/issues/4607 Fixes https://github.com/... — committed to code-asher/code-server by code-asher 3 years ago
Update VS Code (#4631) Fixes https://github.com/cdr/code-server/issues/3410 Fixes https://github.com/cdr/code-server/issues/4604 Fixes https://github.com/cdr/code-server/issues/4607 Fixes https://... — committed to coder/code-server by code-asher 3 years ago
Set remote authority on frontend (#25) Trying to determine the remote authority on the backend is brittle because it does not work behind reverse proxies unless they send the right headers containi... — committed to ZauberNerd/vscode by code-asher 3 years ago
Set remote authority on frontend (#25) Trying to determine the remote authority on the backend is brittle because it does not work behind reverse proxies unless they send the right headers containi... — committed to ZauberNerd/vscode by code-asher 3 years ago
Set remote authority on frontend (#25) Trying to determine the remote authority on the backend is brittle because it does not work behind reverse proxies unless they send the right headers containi... — committed to ZauberNerd/vscode by code-asher 3 years ago

Most upvoted comments

As a temporary solution just in case this helps anyone, I’ve just made sure that X-Forwarded-Host returned the https://<code-server-url>:443 (hardcoded the 443 port) and everything works perfectly.

tjpalanca on Dec 15, 2021

Ah…the headers appear to be lowercased so they do not match. Not sure if they always come that way or if Express lowercases them. 🤦

So I guess forwarded should work since we have it lowercase but not the X- variants. But as mentioned next version will get rid of all this.

code-asher on Dec 14, 2021

Same problem with my setup. I’m running code-server via JupyterHub as part of a JupyterLab image with Traefik as a reverse proxy.

@code-asher @jsjoeio @bpmct You may check at https://vscode-r.jupyter.b-data.ch.
ℹ️ I have whitelisted your GitHub accounts for this deployment back in June.

benz0li on Dec 11, 2021

I fixed this issue in Apache by adding a Forwarded header to my apache config as follows: RequestHeader set Forwarded "for=%{REMOTE_ADDR}s;host=%{SERVER_NAME}s;proto=https" Not sure exactly what the syntax is for nginx, but a similar approach should solve it.

rrgeorge on Dec 21, 2021

Well pretty simple and without any magic:

Configure Caddy:

mydomain.com {
  reverse_proxy 127.0.0.1:8080
}

Restart caddy
Start code-server
Open code-server in your browser
Recognize that the port in lower left corner is :80 and service-workers don’t work

fritterhoff on Dec 13, 2021

Propably completely independent from the proxy. Can reproduce it with Caddy and Apache 😉.

fritterhoff on Dec 11, 2021

I poked into it anyway but it seems like the forwarded headers should work:

> uri = getRemoteAuthority({ headers: { "X-Forwarded-Proto": "https", "X-Forwarded-Host": "vscode-r.jupyter.b-data.ch" }})
> `${uri.hostname}:${uri.port || (uri.protocol === 'https:' ? '443' : '80')}`
'vscode-r.jupyter.b-data.ch:443'

And yet it is actually setting the remote authority to “vscode-r.jupyter.b-data.ch:80”.

I guess it is academic at this point but quite confusing. 😕

code-asher on Dec 14, 2021

Huh, interesting. There must be something else wrong with the code. I am curious as to the problem but I ended up just removing the logic entirely in favor of just setting it to location.host on the frontend so it should just work regardless of headers now. I might look into it later just to see what went wrong.

code-asher on Dec 14, 2021

Forwarded is the best one (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Forwarded) followed by X-Forwarded-Proto combined with either X-Forwarded-Host or Host.

code-asher on Dec 14, 2021