Skip to content
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

[Windows+WSL2+Docker] Impossible to reach forwarded port from DevContainer #9893

Closed
andreujuanc opened this issue May 17, 2024 · 10 comments
Closed
Assignees
Labels
containers Issue in vscode-remote containers info-needed Issue requires more information from poster

Comments

@andreujuanc
Copy link

andreujuanc commented May 17, 2024

  • VSCode Version: latest 3 tested
  • Local OS Version: 10.0.22631 Build 22631
  • Remote OS Version: 5.15.146.1-microsoft-standard-WSL2
  • Remote Extension/Connection Type: Containers/WSL/Server: WSL+Docker DevContainer

Steps to Reproduce:

  1. Open repo with a DevContainer, Open in Container,
  2. Start webserver
  3. Port is forwarded automatically (8080 in my case)
  4. Cant connect from any browser, curl, etc

In the DevContainer
image

Host:
image

I have tried:

  • Restarting my machine
  • Restarting WSL
  • Stopping and deleting all containers
  • Installing previous versions of VSCode and Remote Extensions
  • Manually forward the port
  • Change the port number
  • Using "appPort" from devcontainer.json. (tried different port numbers) Does not work.

This started two days ago, and I haven't installed or updated anything on my system.
I know this might be a problem with my box, but since this team is very knowledgeable about networking+extensions+wsl+docker I guessed that maybe it's something that can happen to more people and leaving trace of a way to fix it would be the best thing to do.

Would appreciate any help regarding this matter.

@andreujuanc
Copy link
Author

andreujuanc commented May 17, 2024

UPDATE:
Weirdly, a local curl within the DevContainer would work. but not outside of the container.
One obvious thing I didn't try was to run a different server. So I did a quick npx serve with an simple html file.
This worked.
My main server is question is a vite one on dev mode. I removed the certificate part and still does not work. I suspect it might be related to the way vite binds.

UPDATE 2:
Welp, Found that there is a "--host" param that if passed , it will work now.
Not sure when they introduced this, or if it's a breaking change from DevContainers or Vite, but it's definitely an unexpected behavior from both. Specially that the port shows as forwarded and with the green dot even without the "--host" param.

@VSCodeTriageBot VSCodeTriageBot added the containers Issue in vscode-remote containers label May 17, 2024
@mswawola
Copy link

mswawola commented May 18, 2024

I am currently developing a web application using Vite and DevContainer. A few days ago, I encountered an issue where I could not access the application from the browser anymore despite having port forwarding set up for port 3000 as usual. This had been functioning as expected for several months until, possibly, the most recent automatic update of VSCode.

As pointed out by @andreujuanc, the --host option when running Vite allows me to access the application. However, this should be considered a workaround, and the underlying issue still needs to be resolved.

The following is an error displayed in the Server output when attempting to access localhost:3000 from the web browser:
image

@yamdan
Copy link

yamdan commented May 20, 2024

The same issue happened to me, and it was worked around by setting the --host option as @andreujuanc mentioned above. The root cause of this problem might be related to the discussion at vitejs/vite#16522.
It might be better to use --host 127.0.0.1 as it only exposes locally, as mentioned in vitejs/vite#16522 (comment)

@andreujuanc
Copy link
Author

The same issue happened to me, and it was worked around by setting the --host option as @andreujuanc mentioned above. The root cause of this problem might be related to the discussion at vitejs/vite#16522. It might be better to use --host 127.0.0.1 as it only exposes locally, as mentioned in vitejs/vite#16522 (comment)

Brilliant!! Thanks for letting me know.

I'll keep this issue open since it's not a vite problem but it looks like a DNS issue when the latest version of docker resolves with ipv6 instead o v4. Maybe the remote extensions can do something about it not to add the host param or disabling ipv6 on all docker projects.

@yamdan
Copy link

yamdan commented May 20, 2024

Yes, indeed, the comment at vitejs/vite#16522 (comment) is quite insightful :)

@biggyspender
Copy link

docker/for-mac#7276

is a similar issue.

FWIW, I solved this (on Windows) by downgrading from Docker 4.30.0 to 4.29.0 using the 4.29.0 installer

'.\Docker Desktop Installer.exe' install --disable-version-check

@chrmarti
Copy link
Contributor

@alexr00 This works for me with a simple HTTP server listening on [::]:3000 in the container.

Could someone seeing this run netstat -l inside the container and post the output here?

@chrmarti chrmarti assigned alexr00 and unassigned chrmarti May 21, 2024
@chrmarti chrmarti added the info-needed Issue requires more information from poster label May 21, 2024
@andreujuanc
Copy link
Author

andreujuanc commented May 21, 2024

Hi @chrmarti , sure here it is. First with the host:true set, and then the default.
image

I can see there is one difference with the http:alt thing

BTW, I just got a friend to do this without devcontainers natively on linux, and when he updated to the latest docker >= 23.1.0 it reproduced the issue.

So this is most likely an network incompatibility issue between docker and vite, and the remote extensions just got tangled in. But I can still be wrong.

@andreujuanc
Copy link
Author

Server NOT RUNNING:
image

Server without the host:true
image

So there is a difference, and something is being forwarded. It's outside of my networking knowledge.

@chrmarti
Copy link
Contributor

I can reproduce with vite and the latest Docker Desktop for Mac.

It seems [::] works, but localhost doesn't. Continuing in #7029.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
containers Issue in vscode-remote containers info-needed Issue requires more information from poster
Projects
None yet
Development

No branches or pull requests

7 participants