I have been running a small docker compose app with multiple containers on my local network for a long time. After a recent update (not sure if it is Windows or Docker Desktop update) I no longer can access the app unless I am on the host and using localhost. From the host if I try the host IP or 127.0.0.1 it will not load. From anywhere on the network if I try the IP or hostname it will not work. I reinstalled the host from the ground up and it is the same issue. I have turned off Windows Firewall completely and it still doesnāt work. Iām at a loss and might just switch to Linux hoping that it is some new Windows + DD wonkiness.
What does that mean? Connection refused? ā404 Not foundā?
localhost and 127.0.0.1 should be the same, it seems strange they shows different results.
It is not connection refused. It acts as if it does not exist.
And I agree that localhost and loopback should be identical. They arenāt. Blows my mind. Iām not dumb on networking but this one is hurting my head. And the thing is, I have been running this server with this OS install running the same docker compose file for a really long time. It just stopped working a couple of days ago. I have since restored older versions of various network component config files (I have a complex setup with multiple VLANs and other stuff) and I completely reinstalled the OS a d Docker Desktop. I have tried basic hello world containers to remove my docker compose and dockerfiles from the equation. Even dumb pre built test containers show the same behavior. Works fine using localhost from the host but even the loop ack address or host IP from the host does not work. Even with the firewall shutoff.
Iām going to try Linux next. Part of me is wondering if something got hacked with the NIC firmware. I know..still doesnāt make sense. Itās all Iāve got to think about and Linux is the easiest diagnostic to isolate at this point.
Iām not sure to understand where the problem can be located.
Did you have run docker compose up ādetach ?
Did you have your container running ? Is he running or stopped ?
Which port is listening ? (run docker ps to see this)
Which error message did you get ?
I use docker compose up -d like I always have. There is no error. The browser acts as if it is an invalid address. The port is 8080 and it has been port mapped like it always has been. There are no logs to look at because it never reaches the containers.
I donāt believe this is a usage issue but something environmental or configuration related to Docker Desktop on Windows 11. I use docker containers professionally (I mostly write them for our apps, or j am authorized k8s files to deploy to a large cluster). So Iām not exactly dumb on how this all works. Iām posting mostly because I donāt know what else to look at with regards to Docker Desktop. My gut tells me so has changed after I did a DD update. I just donāt know what changed.
I donāt think I know the answer, but some questions to keep the topic and the discussion alive hoping for the best:
Have you tried using curl from a terminal or only from webbrowsers? I would try curl in verbose mode. That should show what IP address it uses for ālocalhostā.
Just a idea that could be a difference between the updates: Ipv4 vs ipv6. ālocalhostā could be resolved to an ipv6 loopback IP even if ipv4 doesnāt work, so you could also try ::1 instead of localhost.
curl -v http://[::1]:8080
If the process is available only on ipv6 for some reason, that would explain why an IPv4 IP doesnāt work from a remote machine.
How Ipv4 would break, I donāt know yet.
Very good suggestions. I did try curl with the same results. It is very confusing. I am currently reinstalling the host machine with Linux to see if it will work better with docker. The part that gets me is I can reproduce the problem on the host machine itself. Although I guess I havenāt tried configuring a static IP and take it off of the network yet to remove the network from the equation. Iāll try that if Linux produces the same issues
I appreciate the suggestions. Iāll post back when I know more.
It does work fine with Linux on the same host and network setup. So it seems something has changed with either Windows 11 or Docker Desktop that is breaking things. I know I recently had applied updates for both and then the problem started. I even did a complete reinstall of Windows 11 Pro on this machine (not a reset, but ISO download and repartition to ensure it is a clean install), disabled the firewall, and hacked on it hard to try to figure out why I could only access things via localhost but not loopback, or host name.
Not necessarily. It could return the ipv6 version ::1 instead.
I just tried by starting an nginx container:docker run -ti --rm -p 80:80 nginx, then trying to access it from Powershell:
PS C:\Users\metin> Invoke-WebRequest -ConnectionTimeoutSeconds 1 http://localhost
Invoke-WebRequest: The request was canceled due to the configured HttpClient.Timeout of 1 seconds elapsing.
PS C:\Users\metin> Invoke-WebRequest -ConnectionTimeoutSeconds 1 http://[::1]
Invoke-WebRequest: The request was canceled due to the configured HttpClient.Timeout of 1 seconds elapsing.
PS C:\Users\metin> Invoke-WebRequest -ConnectionTimeoutSeconds 1 http://127.0.0.1
StatusCode : 200
StatusDescription : OK
Content : <!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
html { color-scheme: light dark; }
body { width: 35em; margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif; }
</styleā¦
RawContent : HTTP/1.1 200 OK
Server: nginx/1.29.2
Date: Fri, 17 Oct 2025 19:51:47 GMT
Connection: keep-alive
ETag: "68e54807-267"
Accept-Ranges: bytes
Content-Type: text/html
Content-Length: 615
Last-Modifā¦
Headers : {[Server, System.String[]], [Date, System.String[]], [Connection, System.String[]], [ETag,
System.String[]]ā¦}
Images : {}
InputFields : {}
Links : {@{outerHTML=<a href="http://nginx.org/">nginx.org</a>; tagName=A; href=http://nginx.org/},
@{outerHTML=<a href="http://nginx.com/">nginx.com</a>; tagName=A; href=http://nginx.com/}}
RawContentLength : 615
RelationLink : {}
And the same with curl:
PS C:\Users\metin> curl --connect-timeout 1 -6 http://localhost
curl: (28) Connection timed out after 1012 milliseconds
PS C:\Users\metin> curl --connect-timeout 1 -4 http://localhost
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
html { color-scheme: light dark; }
body { width: 35em; margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif; }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>
<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>
<p><em>Thank you for using nginx.</em></p>
</body>
</html>
But that wouldnāt explain why the containers are not reachable by your host ip and published port, unless you use the host name, and it gets resolved to its ipv6 address as well.
1 Like
I have exactly the same problem since yesterday. Itās either the October Microsoft updates or the Docker Desktop update. Most likely the Windows updates are the cause. I installed both prior to this problem happening. Unfortunately the much-touted Windows Update uninstall fails.
What is that feature on Windows where you can rollback?
I tried a reset and a fresh install from media blowing away the partition. Same issue. Installed Linux on the same machine and ran the same docker compose file and boom.. working.
Iām sticking with Linux for this particular machine but I used docker desktop daily for work. This is going to cause serious problems for professionals once these updates trickle down to enterprise users.
Settings->Windows Update-> Update History, there is a button at the bottom to uninstall updates. Or you can use (say) wusa /uninstall /kb:5066835 from the cmd line.
This looks relevant but kind of the opposite https://learn.microsoft.com/en-us/answers/questions/5585563/localhost-not-working-anymore-after-2025-10-cumula
Another related topic:
And it was also reported on GitHub
You can join the conversation and share logs as it was asked for by the github-actions bot
Has anyone managed to solve this yet?
Yes. This issue started after recent Windows and Docker Desktop updates. It happens because Docker Desktop now uses WSL2 networking, which isolates the containers from the local network.
When you use localhost on the host, Docker forwards the port correctly. But when you try the host IP or hostname, it fails because Windows does not route that traffic into WSL2. Turning off the firewall does not help since the problem is in how Windows handles the network bridge, not in blocking the traffic.
You can fix this in a few ways. The simple way is to add a manual port forwarding rule using PowerShell. For example:
netsh interface portproxy add v4tov4 listenport=8080 listenaddress=0.0.0.0 connectport=8080 connectaddress=172.23.176.1
Replace 8080 with your container port and 172.23.176.1 with the WSL2 gateway IP, which you can find by running āip addrā inside WSL.
If you want a permanent and stable setup, using Linux for Docker is the best option. Linux supports direct host networking, so the app will be reachable from anywhere on the local network without any extra steps.
Nick R
Cloud Team Lead
AccuWeb.Cloud
I am not sure, if I am able to make sense of this statement. When didnāt Docker Desktop for Windows didnāt use WSL2 networking when WSL2 was used as backend? Are you referring to networkMode=mirrored?
Anyhow, I tested it with networkMode=mirrored and networkMode=nat (=default). With both settings, I can access the container started with docker run -p 80:80 nginx using http://localhost and http://<host-ip>. Note: in WSL Settings the Hyper-V Firewall is activated in both cases.
In networkMode=mirrored the host ip is visible in the docker-desktop distribution, but is not passed through to the Docker Engine that runs inside the docker-desktop distribution.
This is only required if docker-ce runs in a WSL distribution. If Docker Desktop is used, Docker Desktop takes care of creating the required forwardings.
This is my C:\Users\<USER>\.wslconfig:
[wsl2]
nestedVirtualization=true
autoProxy=false
networkingMode=mirrored
[experimental]
hostAddressLoopback=true
Note: the hostAddressLoopback setting has no effect if networkingMode=mirrored is used.
1 Like
Hi,
Iāve finally got it working again.
In the WSL Settings App I changed from NAT to Mirrored and set Host Address Loopback to True (The note beside it says that it only has an effect in Mirrored mode). That got me access on the host using itās IP Address. To get access from other machines on the network I created a firewall inbound rule to allow the specific ports I needed to access the containers.
This claim is not correct. I tested it with Default networking mode āDual IPv4/IPv6ā with Docker Desktop 4.50.0 and a container created like this:
docker run -it --rm -p 80:80 traefik/whoami:latest
I checked in Powershell whether the port listens on the Windows host:
PS C:\Users\metin> netstat -ano | findstr ':80 '
TCP 0.0.0.0:80 0.0.0.0:0 ABHĆREN 6932
TCP [::]:80 [::]:0 ABHĆREN 6932
TCP [::1]:80 [::]:0 ABHĆREN 32312
Then I used curl to test in the Powershell terminal on the Windows host:
curl -4 localhost
curl -6 localhost
curl <host ipv4>
curl <host ipv6 ULA>
curl <host ipv6 GA>
The first three get a response, the last two time out.
Then I tried curl <host ipv4> from a remote host: it works as well.
Update: if Default networking mode āipv4 onlyā is used, all 5 curl commands work from the Windows host. But from a remote host still only the host ipv4 address works.
Note: the tests are done with wsl2 networkmode=nat (=the default mode)
Update2: with wsl2 networkmode=mirrored it behaves the same.