Only one port can be accessed by the host through localhost at the same time

[zed76r]

Windows build number: 10.0.19536.1000

Steps to reproduce:

1. Listen on port A vianc -l <PortA>.
2. The browser accesses http://localhost:PortA, and the console can output the browser request body.
3. Listen on port B via nc -l <PortB>.
4. When the browser accesses http://localhost:PortB, the error ERR_CONNECTION_REFUSED directly appears.
5. Shut down wsl2 through the wsl.exe --shutdown command, repeat the test in the order of 3, 4, 1, 2, and the result is that PortB can receive the packet, and PortA has an error ERR_CONNECTION_REFUSED.

Another reproduction method:

Using vscode's wsl-remote plug-in, it can be started correctly through the code . command for the first time. After closing vscode and using the command to open it again, the file under wsl cannot be displayed and an error message is displayed.

[BabyDino]

I think I'm running into this issue as well. I've just upgraded to 19536 and can't use vscode and my localhost:3000 app at the same time.

[ad-on-is]

I have exactly the same issue:

1. Opening a Remote WSL instance in VSCode (works)
2. Run vue ui
3. localhost:8000 gives error ERR_CONNECTION_REFUSED

After wsl --shutdown

1. Run vue ui
2. localhost:8000 works
3. Open a Remote WSL instance in VSCode gives error
   

[wlbrough]

Similar issue to previous comments, but slightly different error path.

Windows 10 Pro Insider Preview Build 19536.rs_prerelease.191211-1446 (WSL 2 Enabled)

1. Open a Remote WSL instance.
2. Start node server on WSL (running in a Docker container for an additional complication 🙂 )
3. Cannot access the server at localhost:3000, which was working prior to Windows update.

[prsnnami]

Same issue, multiple connections to localhost doesn't work after the update 19536.1000

Issue Identical to @ad-on-is 's comment.

Don't know much about WSL's network arch to debug further.

[berwyn]

I have noticed that this is infinitely more flakey than just one port being available.

• I have Docker on my machine setup with WSL2 as its backend. I can run as many containers as I like on Docker and all the ports there get correctly exposed to the host.
• With Ubuntu, however, only the first opened port ever gets exposed to the host, and even that never works if the process dies and then I try to re-bind that port (a good example being VS Code -- if I have to re-open the window, the port won't bind).
• Lastly, with CentOS (which I installed to test a theory about the port issue), I can't bind any ports whatsoever, they all fail.

Not sure what steps I can/should take to debug WSL2 networking, but I can confirm the update to 19536 is what broke me.

[benhillis]

Thanks for reporting, there is an issue in Insider Fast, and a fix is coming in a future build (hopefully next week).

[alexisferat]

I have a LAMP setup on Ubuntu and I have the same issue. I cannot access my sites when using localhost.

Until the fix is coming, I found a workaround. Do a ifconfig and take the inet value of the eth0 connection and use it instead of localhost (for example in your host file).

The only problem is this address changes when the VM restart.

Windows 10.0.19041

[GMory]

Is there a way to downgrade to previous build?

[berwyn]

Settings -> Update & Security -> Recovery -> Go back to a previous version of Windows 10

This should allow you to go back to the build you were running prior to this one. Make sure to pause updates from there, else your system will attempt to upgrade again to the problematic build.

[OctavioBR]

I witness that after 19536 update, it started to give me this same error.

[alechstong]

I ran into this problem as well.
I experimented a little and found out that the problem is better described as "one port per ip address".

For example, I start server A on port 3000 and server B on 4000. If I access server A first on 127.0.01:3000 on the windows side, but I cannot access server B on 127.0.0.1:4000. However, I can access server B using wsl's ip address (let's say 172.23.134.64:4000). If I start another server C on port 5000, I cannot access it from either ip.

So if you are like me, that are only running at most 2 servers in WSL, you are fine for now, and can wait for the update to drop.

[hristo-banchev]

@benhillis would you share an update on the fix? Any vague ETA?

[puco]

Any news on the fix?

[mituso89]

Any news on the fix?

[benhillis]

Fix was delayed by holiday break but still inbound.

[BabyDino]

Just installed 19541. Works for me :)

[wlbrough]

19541 fixed it for me as well. Thanks @benhillis & WSL team!

[penavincent]

19541 Seems to have fixed vscode not being able to "fetch remote environment",

However it does NOT seem to have fixed the issue of not being able to access more than one port at a time.

I have a React project which runs on localhost:3000, and a Gatsby project which runs on localhost:8000, previous to this issue, I could run both of them simultaneously and access them from windows on Chrome.

Follow these steps to recreate the behavior:

• Open WSL2
• Go to the React project root directory and run npm start to start the server running onlocalhost:3000
• On a new tab, go to the root directory of the Gatsby project and run npm start, this starts the server on localhost:8000
• Open Google Chrome and go to localhost:3000, you should see the react project.
• Now try to go to localhost:8000, you will not be able to see the Gatsby project, and you should see an error like the following:

Fun thing is you can stop both the servers, ONLY start the gatsby project on localhost:8000, and you will get the same error, but if you start another react project, it'll be fine on localhost:3000.

It seems like the first port you use while WSL2 is active sticks and becomes the only one you can see from Windows, running wsl --shutdown on a command prompt window and starting WSL2 again seems to reset the slate, so say now you start the Gatsby project on localhost:8000 first then stop it right away, you won't be able to see any apps running on localhost:3000 if you start them after starting the localhost:8000 app, you will only have port 8000 visible on windows.

[rabbitXIII]

@Joe-Pena i observed the same behavior before updating to 19541. :( was feeling hopeful about this version. Does VSCode work while your server is occupying a port? I've had to resort to just using VIM while leaving my react dev server up..

[dparker2]

Also having this issue again with version 10.0.19592.1001

[mMoovs]

Updated from wsl 1 to 2 today and can cofirm this issue is still present. Slow ring, version 10.0.19041.173. Using @alexisferat 's fix for now...

[Himakar-PV]

@benhillis please check our above comments, the issue if back in the latest versions. Thank you.

[ad-on-is]

Windows 200410-1438 Build 19608, no issue here!

[onomatopellan]

Windows Insider Slow Ring build 19041.207. No issue here trying OP's instructions.

[dparker2]

Just updated to version 10.0.19608.1000 and the issue appears to be resolved again

[craigloewen-msft]

If you're experiencing this issue again, could you please collect detailed logs for us (instructions here) and post them here so we can help diagnose it?

Thank you!

[Kenan7]

@craigloewen-msft
detailed_logs.zip

[ahmedalnuaimi]

I faced the same problem and found that running Docker commands or any other command that creates listeners with sudo solves the problem! Adding the current user to the docker group made no difference.

[renevall]

I was having issues with kubectl port-forward. What worked for me was stopping docker desktop(wsl2) windows. Then I ran the port-forward. It suddenly started to work again. I started docker desktop again and everything seems to work

[gvalenzuelas]

When upgrade WSL 1 to WSL 2 the apache2 conf only listen on tcp v6 (ubuntu 20.04). I solved this problem, apply configuration in file /etc/apache2/ports.conf to Listen 0.0.0.0:80 (tcp v4)

[e00dan]

The issue still persists in slow ring. Is there any plan to fix it? It is breaking basic workflow of typical developer. I can't access page I'm hosting on linux therefore I can't use WSL to develop.

[e00dan]

Why is this issue closed?

[onomatopellan]

@kuzirashi Try disabling Fast Startup. If it works then you are hitting bug #5298

[sarim]

This issue comes and goes it seems. One day its working, next day its not. Some ports are working, some ports aren't. Not sure what is going on. Ex: last night everything was working, now i can't connect to my wsl's mysql from windows with localhost:3306. Where a http server running in 4444 is working fine.

How does this localhost forward work actually? Can I run a powershell cmd to get a list of ports LXSS is current forwarding? Can I reset it? Edit it?

[onomatopellan]

@sarim Can you check if you have Fast Startup enabled?

[sarim]

I had fast startup enabled. But I had explicitly disabled hibernate from powercfg. AFAIK fast startup doesn't effectively enables if there is no hiberfil.sys. Which I don't have bcz I disabled hibernate. Nevertheless I explicitly disabled fast startup from registry.

[sarim]

It happened again. Restarting LxssManager from Task Manager -> Services didn't help. Had to restart windows. Now its working.

[lemchen]

It happened again. some specific ports not working for localhost:ports, but some other ports works. for example, i run node use localhost:3000 doesn't work, by changing the port number it does.

[onomatopellan]

@lemchen That sounds like docker/for-win#7196
What's the output of netsh int ipv4 show dynamicport tcp ?

[lemchen]

@lemchen That sounds like docker/for-win#7196
What's the output of netsh int ipv4 show dynamicport tcp ?

yes , the port is in the range of excludedportrange by using netsh interface ipv4 show excludedportrange protococol=tcp.
i have solved this problem by disable Hyper-V function and re-enable it.

[a-abella]

I've began experiencing (I think) some manifestation of this issue. I am not limited to one bound port at a time, but which ports are accessible from the Windows host seems arbitrary. I had ports 3000 and 222 working yesterday. After a shutdown, they are not working today. Additional testing of random ports has yielded the following results:

(testing methodology: sudo netcat -kl 0.0.0.0 $port from wsl2, and try to access from browser on Windows host)

Working:
1024
1025
1026
1027
1194
2111
4099
4170
4455
4567
6974

Not working:
1111
2024
2025
2026
2027
2255
3000
3005
3456
4000
4001
4002
4003

The ports that work always work, even after wsl --shutdown. The ports that fail always fail. I'm curious what the condition is that causes this.

The WSL-side iptables are blank:

iptables-save output

# Generated by iptables-save v1.6.1 on Sun Aug  2 22:18:51 2020
*security
:INPUT ACCEPT [29:3752]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [27:3286]
COMMIT
# Completed on Sun Aug  2 22:18:51 2020
# Generated by iptables-save v1.6.1 on Sun Aug  2 22:18:51 2020
*raw
:PREROUTING ACCEPT [49:8733]
:OUTPUT ACCEPT [27:3286]
COMMIT
# Completed on Sun Aug  2 22:18:51 2020
# Generated by iptables-save v1.6.1 on Sun Aug  2 22:18:51 2020
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
COMMIT
# Completed on Sun Aug  2 22:18:51 2020
# Generated by iptables-save v1.6.1 on Sun Aug  2 22:18:51 2020
*mangle
:PREROUTING ACCEPT [49:8733]
:INPUT ACCEPT [29:3752]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [27:3286]
:POSTROUTING ACCEPT [27:3286]
COMMIT
# Completed on Sun Aug  2 22:18:51 2020
# Generated by iptables-save v1.6.1 on Sun Aug  2 22:18:51 2020
*filter
:INPUT ACCEPT [29:3752]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [27:3286]
COMMIT
# Completed on Sun Aug  2 22:18:51 2020
# Generated by iptables-save v1.6.1 on Sun Aug  2 22:18:51 2020
*security
:INPUT ACCEPT [29:3752]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [27:3286]
COMMIT
# Completed on Sun Aug  2 22:18:51 2020
# Generated by iptables-save v1.6.1 on Sun Aug  2 22:18:51 2020
*raw
:PREROUTING ACCEPT [49:8733]
:OUTPUT ACCEPT [27:3286]
COMMIT
# Completed on Sun Aug  2 22:18:51 2020
# Generated by iptables-save v1.6.1 on Sun Aug  2 22:18:51 2020
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
COMMIT
# Completed on Sun Aug  2 22:18:51 2020
# Generated by iptables-save v1.6.1 on Sun Aug  2 22:18:51 2020
*mangle
:PREROUTING ACCEPT [49:8733]
:INPUT ACCEPT [29:3752]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [27:3286]
:POSTROUTING ACCEPT [27:3286]
COMMIT
# Completed on Sun Aug  2 22:18:51 2020
# Generated by iptables-save v1.6.1 on Sun Aug  2 22:18:51 2020
*filter
:INPUT ACCEPT [29:3752]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [27:3286]
COMMIT
# Completed on Sun Aug  2 22:18:51 2020

[onomatopellan]

@a-abella Open an elevated Powershell and post the output of these:
netsh int ipv4 show excludedportrange protocol=tcp
netsh int ipv4 show dynamicport tcp

[a-abella]

@onomatopellan

Aha, I knew about show dynamicport but not the excludedportrange.

Protocol tcp Port Exclusion Ranges

Start Port    End Port
----------    --------
      1028        1127
      1239        1338
      1675        1774
      1775        1874
      1875        1974
      1975        2074
      2075        2174
      2180        2279
      2280        2379
      2380        2479
      2480        2579
      2580        2679
      4514        4613
      4614        4713
      4714        4813
      4814        4913
      4914        5013
      5041        5140
      5141        5240
      5241        5340
      5355        5454
      5455        5554
      5555        5654
      5655        5754
     50000       50059     *

* - Administered port exclusions.

PS C:\WINDOWS\system32>
PS C:\WINDOWS\system32> netsh int ipv4 show dynamicport tcp

Protocol tcp Dynamic Port Range
---------------------------------
Start Port      : 1024
Number of Ports : 64511

This is after a reboot since my previous comment, so it looks like the exclusions affecting my random port findings are now different.

Your comment led me to #5306 , which suggested moving the dynamic port range with netsh int ipv4 set dynamic tcp start=49152 num=16384 Presumably an Insider update or something moved the Start Port to 1024.

After moving the Start Port and rebooting things look sane again, and I can bind ports reliably from WSL2 again.

Thanks a lot!

[ntrp]

Thanks for this, I wasted 4 hours finding out why it does not work... Did not think about changing port after seeing that a demo python server on 8000 was working fine...

[danielcinome]

19541 Parece que el vscode fijo no puede "recuperar el entorno remoto",

Sin embargo, NO parece haber solucionado el problema de no poder acceder a más de un puerto a la vez.

Tengo un proyecto de React que se ejecuta localhost:3000y un proyecto de Gatsby que se ejecuta localhost:8000, antes de este problema, podía ejecutar ambos simultáneamente y acceder a ellos desde Windows en Chrome.

Siga estos pasos para recrear el comportamiento:

• Abrir WSL2
• Vaya al directorio raíz del proyecto React y ejecute npm startpara iniciar el servidor en ejecuciónlocalhost:3000
• En una nueva pestaña, vaya al directorio raíz del proyecto Gatsby y ejecute npm start, esto inicia el servidor enlocalhost:8000
• Abra Google Chrome y vaya a localhost:3000, debería ver el proyecto de reacción.
• Ahora intente ir a localhost:8000, no podrá ver el proyecto Gatsby, y debería ver un error como el siguiente:

Lo divertido es que puede detener ambos servidores, SOLO iniciar el proyecto gatsby localhost:8000y obtendrá el mismo error, pero si inicia otro proyecto de reacción, estará bien localhost:3000.

Parece que el primer puerto que usa mientras WSL2 está activo y se convierte en el único que puede ver desde Windows, ejecutarse wsl --shutdownen una ventana del símbolo del sistema e iniciar WSL2 nuevamente parece restablecer la pizarra, así que diga ahora que inicia el proyecto Gatsby localhost:8000primero luego deténgalo de inmediato, no podrá ver ninguna aplicación ejecutándose localhost:3000si las inicia después de iniciar la localhost:8000aplicación, solo tendrá el puerto 8000 visible en Windows.

this has worked for me, thank you.

[gxtaillon]

Same problem as described above. Setup working fine with Docker for Windows & Kube. After restarting the computer, nothing works from the windows side. Running wsl --shutdown, restarting docker from the UI and rerunning kubectl proxy, now everything works fine.

Edit 1: 2/2 restarts where Docker was set to run on startup this issue has occurred. I disabled this setting and i'll see what happens if Docker is started manually after a restart.