Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm if it's https, shouldn't it be on 8443?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know nothing about setting up NGINX + Let's Encrypt so I would take your word over mine. Here's the discussion if you want to know why I opened the PR: #3709
also cc @code-asher
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I’m a noob and know nothing about anything. I just found that when following the instructions as written, I got a redirect error when visiting my domain from a remote device. It got caught in a 302 redirect loop, constantly being redirected to https://domain.com. I tried tweaking a couple of things in the nginx config, and this was the change which made it work.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah. I'm confused about the discussion but can offer you some more context on how people typically use reverse proxies.
Many services default to HTTP (without encryption) because it avoids the need to handle TLS certificates. My guess is that Express does this by default, and code-server runs without encryption. However, it's unsafe to access things over HTTP over the Internet, because anyone inbetween the browser and server can intercept and modify traffic, including view credentials, which are sent in plaintext when not using HTTPS.
So the solution that many people use is to have a reverse proxy that receives the HTTPS traffic, decrypts it, and passes the connection through to code-server.
I believe this nginx configuration is saying: when a user accesses https://joes-codeserver-site.joesdomain.com, we want to decrypt the traffic and pass it through to localhost:8080. The proxy_pass part refers to the actual host protocol and port of the service (in this case code-server) that we're reverse proxying, and the reason we needed http is because we want to decrypt the incoming traffic before handing it to code-server.
If we use https here, then it means that nginx will decrypt and re-encrypt traffic for localhost, but the code-server backend service will be confused because it's expecting unencrypted traffic, not encrypted traffic.
The docs for proxy_pass aren't super friendly, but I think this is why the examples all use http, since it's relatively common to use nginx in a configuration where it terminates TLS traffic and passes decrypted traffic to code-server.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yup
http
is correct here. With regards to the discussion one possibility is that code-server is being started with--cert
? With that code-server will redirect from http to https. So the page redirects, nginx makes another request to http, code-server redirects again, and on and on we go.If this is the case then starting without
--cert
would resolve the issue.The only use case for
https
here I think is if you need to encrypt traffic internally (from NGINX to code-server) for some reason. I don't think most people's threat models need to account for this.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ahhh, got it. I'm going to close this PR then. But it does sound like we could flesh out this guide more. Once we are done with the testing priority, I can do a run through the docs and address things like this.
Noting in the roadmap