Change:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes/No <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --Issue similar to - this time it affects Devcontainers running on remote ssh hosts Client: Windows 11 Remote-Host: Ubuntu 22.04 Container: Debian 11 Repo for reproduction: Steps to Reproduce: to ssh host in devcontainer when asked Task "Serve" to start webserver http://localhost:4000 and see indefinite loading. I can't test it without the remote ssh host :/ <details<summaryShared-Log</summary<p</p</detailsDev console doesn't contain anything related. The extension host shows: Although I'm not sure if that's related. The server output is interesting: This is directly related - it happens right/shortly after opening the url in the browser.
Insiders has upgraded to Node 18 which now prefers ipv6 in dns lookups for localhost. I wonder if your service listens only on ipv4 localhost. When connecting to a tunnel we ask for , though this might be configurable ( we could do what I did in and try to connect both to ipv4 and ipv6 localhost for any forwarded connection asking for , and use whatever is accepted first.
Using 127.0.0.1 has no effect... Worth mentioning: My remote host and the docker network are both ipv6 enabled (dual stack)
I corrected my comment, that would not have worked. Do you know if the server running in the repo bound to the ipv6 or ipv4 localhost?
Ah, okay. That seems to be what is happening. I imagine this may be a popular issue with our next release. Will discuss whether we want to put in a patch at this point.
If you pull the regular release to node 18 - that would be great. I only work in devcontainers... If not... I can move those containers that use port forwarding back to the regular version.
Local/dev verification steps: two machines on an ipv6-enabled network, and 'remote' and 'local' to return from the method on the test resolver, and comment out its on the 'remote' machine the 'local' machine, run OSS dev and run the command "Connect to TestResolver in Current Window" port 3000 on the local machine the remote machine, run . Verify you can hit it on the local machine. This should work in main. the remote machine, run . Verify you can hit it on the local machine. This will fail
Labelling as candidate for discussion
This sounds like the extension host uses ipv6 to connect to localhost. Wasn't supposed to keep the Node 16 behavior of preferring ipv4?
Yes the extension host prefers the legacy result order of ipv4 first, it is configured for both local and remote extension hosts
I am not familiar with port forwarding code, but the change here is addressing the connection to the server. I have not changed the behavior for server main process, basically it will use the newer behavior of whatever the OS prefers. Should the server also be changed to use the legacy result order ?
Not entirely sure, but it seems like it would make sense to keep the user-visible behavior the same and avoid surfacing the change in On the other hand, users will gradually upgrade to 18 and since also changes its behavior, the ports the forwarding code is connecting to will change interfaces. So maybe the flag you suggest or probing of both interfaces when connecting to localhost might be more future proof.
The code that sets up a tunnel executes in the server process, where it tries to to , so that is why the extension host flag doesn't have any effect. I also like the idea of using node's builtin rather than us reimplementing it.
I was able to reproduce via SSH to an Ubuntu 22 installation only after configuring to add to , in the following way: !
The repro steps which worked for me: install ubuntu 22.04.3 in Parallels change and add to e.g. connect via SSH create a js file launch the file via the node installed by the server e.g. add port forwarding for port 3002 open localhost:3002 in the local machine
I just want to raise the question if makes sense to build something complicated for detecting the address family now - not sure how often ipv6 is used for localhost binding? I'd be perfectly fine if it always goes for ipv4 for the time being. Edit: ... or I take the fix that just got finished while writing this comment
Verified in latest insider, works. Thank you very much for saving me! For documentation: does now show up in the server output when opening the port. Doesn't seem to prevent it from working though.

Discussion:
const socket = net.createConnection( { host: host, <del> port: port </del> <ins> port: port, autoSelectFamily: true </ins> }, () => { socket.removeListener('error', e); socket.pause();