All containers become intermittently unreachable

Docker Desktop
1

I am running Docker Desktop (Version 4.48.0 (207573)) for Windows 11 (24H2) and use docker compose for creating/editing my containers. I have 32GB RAM with 16 cores. According to Docker Desktop, my container CPU usage is typically around 2-5%/1600%, with the largest spike I’ve seen to be about 50% and my container memory usage hovers around 2.6GB / 15.14GB. I am fairly new to Docker, so I’m not sure what info is really relevant, but I have been working on this issue for a few days with ChatGPT and I’m summarizing the info I’ve been asked. I have also done google searches and can’t find anything in the documentation or this forum that matches exactly what I am seeing, likely due to me not knowing the correct wording to look for.

Approximately every 15-20 minutes all of my docker services become unreachable in the web browser. If I go to http://localhost:port for any of my docker services, it will not load. If I go to https://service.mydomain (I am running NPM with proxy hosts for each of my services, SSL certs via DuckDNS, and AdGuardHome as a Windows service doing DNS rewrites), it’s the same story. If I run the following command (ChatGPT’s recommendation) while they are unreachable, it appears that the ports are still communicating over TCP:

while ($true) {
$time = Get-Date -Format “HH:mm:ss”
$res = Test-NetConnection localhost -Port 32400 # Example: Plex port
“$time - TCP Test: $($res.TcpTestSucceeded)” | Tee-Object -Append docker_netlog.txt
Start-Sleep -Seconds 5
08:53:40 - TCP Test: True
08:53:52 - TCP Test: True
08:53:59 - TCP Test: True
08:54:06 - TCP Test: True

After 1–2 minutes, everything corrects itself and begins functioning as before. Nothing else appears to be affected as I can still stream Netflix/Youtube and visit other sites and apps without issue. This issue has seemingly become more frequent as I spin up more containers (currently at 19 and I can provide a list if that’s relevant). Also, my AdGuardHome Windows service appears to be functioning perfectly according to the query log and was one of my first services I began using so I don’t think sporadic DNS issues are the culprit.

Any advice or leads on where I can find more info would be greatly appreciated.

1 Like
2

What backend are you using for Docker Desktop? WSL2?

When it comes to accessing containers, adguard should be irrelevant, except for the initial dns lookup of your domain that should return the ip of the docker host.

With localhost, it’s irrelevant anyway. Just out of curiosity, if you execute ping localhost, does it ping 127.0.0.1 or ::1? Does it make a difference if you access the published ports using http://127.0.0.1:<port>?

Does it make a difference, if you leave NPM out of the loop, and directly access published host ports of containers?

You might want to try, if the http endpoint can be queried, instead just chcking whether its reachable:

Invoke-WebRequest -Verbose -Debug -Uri "http://127.0.0.1:<port>"

Those are just some thoughts. To be honest, I have no idea what is causing your issue. But it should help to get a better idea of your situation.

3

Maybe docker desktop or the VM’s pausing for a bit. Did you check its log or event viewer when it happens?

4

Hi, I’ve also faced a similar issue, and it was fixed after I downgraded to my previous version:

.\"Docker Desktop Installer 4.44.0.exe" install --disable-version-check
5

For anyone who may be having the same issue, it was caused by a WSL 2.0 network bandwidth issue. I am running about 20 containers, but the issue stopped when I removed the containers that are heavier graphically (Plex, Jellyfin, etc.). I stopped the Plex and Jellyfin containers and the problem stopped. I started them back up and the problem returned. I installed them as Windows programs instead and have them running normally, and the issue has not returned. My computer does not have a devoted GPU, as it uses Intel integrated graphics. I imagine this issue could be solved by having/utilizing a good GPU, how I handled it, or tinkering with the WSL network bandwidth settings (or some combination of all three). I may end up having to adjust the WSL network bandwidth settings anyway as I add more containers/projects, but the problem is at least temporarily solved.

6

I just run some tests with Oaakla Speedtest to verify the hypothesis.
I have a 600/300 fiber line and used WLAN during the tests.

Linux Container on Docker Desktop with WSL2 backend:

docker run -it --rm gists/speedtest-cli speedtest --server-id=31469

   Speedtest by Ookla

      Server: Deutsche Telekom - Hamburg (id: 31469)
         ISP: Deutsche Telekom AG
Idle Latency:     4.78 ms   (jitter: 3.75ms, low: 4.08ms, high: 18.06ms)
    Download:   418.28 Mbps (data used: 486.0 MB)
                 15.58 ms   (jitter: 13.29ms, low: 3.48ms, high: 52.11ms)
      Upload:   272.83 Mbps (data used: 461.9 MB)
                 20.92 ms   (jitter: 14.73ms, low: 3.06ms, high: 239.08ms)
 Packet Loss:     0.0%
  Result URL: https://www.speedtest.net/result/c/2e67ef5c-e677-4b9c-a3e2-a58d828124df

Windows host:

d:\tmp>speedtest.exe --server-id=31469


   Speedtest by Ookla

      Server: Deutsche Telekom - Hamburg (id: 31469)
         ISP: Deutsche Telekom AG
Idle Latency:     3.32 ms   (jitter: 1.05ms, low: 3.13ms, high: 6.58ms)
    Download:   635.35 Mbps (data used: 558.2 MB)
                 26.02 ms   (jitter: 10.06ms, low: 6.24ms, high: 63.47ms)
      Upload:   281.96 Mbps (data used: 312.8 MB)
                  6.29 ms   (jitter: 6.90ms, low: 2.67ms, high: 55.94ms)
 Packet Loss:     0.0%
  Result URL: https://www.speedtest.net/result/c/37f80f9a-cd29-4581-9e2d-695834e71d9e```

WSL2 distro:

me@host ~$ ./speedtest  --server-id=31469

   Speedtest by Ookla

      Server: Deutsche Telekom - Hamburg (id: 31469)
         ISP: Deutsche Telekom AG
Idle Latency:     3.00 ms   (jitter: 0.89ms, low: 2.72ms, high: 4.59ms)
    Download:   629.47 Mbps (data used: 519.4 MB)
                 29.51 ms   (jitter: 14.64ms, low: 8.60ms, high: 142.58ms)
      Upload:   276.24 Mbps (data used: 288.3 MB)
                  9.05 ms   (jitter: 8.26ms, low: 2.72ms, high: 72.50ms)
 Packet Loss:     0.0%
  Result URL: https://www.speedtest.net/result/c/b8780bc8-a95f-4fb4-9592-94d531d6d963

I repeated each test a couple of times, and had similar results in each environment. The results between on Windows and the WSL2 distribution are more or less on par (I usee networkMode=mirrored for WSL2).

The Linux container had a performance loss of 1/3 comared to the host/wsl2 disto when it comes to incoming traffic.

I am not sure how a GPU would be relevant for network performance. I can see how a container with greedy cpu consumption might starve other containers, or drive the system load in hights that make the WSL system vm irresponsive.

If you should give a new try, I would be currious how the output of top looks like inside the docker-desktop distro, and it’s system distro:

wsl -d docker-desktop top
wsl -d docker-desktop --system top

Anyhow, I am glad you found a solution that works for you.