[macOS][4.90.0] Docker VMM silently loses all VM egress after ~15 h; only a restart fixes it

Start with the supplied diagnostics ID and inspect httpproxy.log, com.docker.backend.log, and the retained vm/init.log entries around the first refused connection. Compare Docker VMM behavior with the Apple Virtualization framework and the listed container, VM, and host network observations. Done means identifying the cause of guest egress loss and ensuring the failure is either prevented or logged clearly.

Description

With Docker VMM selected as the Virtual Machine Manager, Docker Desktop 4.90.0 on Apple Silicon silently lost all outbound network from the VM after about 15.5 hours of uptime. Every container was affected, and so was the engine itself (docker pull failed). The macOS host had normal connectivity throughout. No error was written to any Docker Desktop log. Restarting Docker Desktop restores connectivity; this was the third restart needed in the four days since the 4.90.0 update.

Reproduce

No reliable trigger found. What was running when it broke:

• Two long-running containers (restart: unless-stopped), one of them driving several claude CLI agent processes that open many concurrent HTTPS connections to api.anthropic.com through an in-container loopback proxy; the other a small Python web app.
• VM uptime at failure: 20h20m; time since Docker VMM was selected and the VM rebooted: ~15.5 h.
• Host was awake the whole time (no sleep/wake events in pmset -g log), Tailscale running without an exit node, macOS firewall off.

Expected behavior

Container and engine egress keeps working, or the failure is logged somewhere.

Observed behavior (measured while broken)

From inside any container, including freshly started ones on the default bridge, a compose network and --network host:

$ curl -sS -m 8 https://api.anthropic.com/
curl: (7) Failed to connect to api.anthropic.com port 443 after 1 ms: Couldn't connect to server

• TCP to every destination refused in 1–8 ms: public IPs (160.79.104.10, 140.82.121.4, 1.1.1.1, 8.8.8.8), the Mac's own LAN address, host.docker.internal, and the gateway's own proxy port 192.168.65.1:3128.
• ICMP to 192.168.65.1 answers; ICMP to 1.1.1.1 is dropped; raw UDP DNS to 8.8.8.8:53 times out.
• DNS via the embedded resolver still resolves (it reaches the host over services1 / 192.168.65.7, not eth0), which is why the failure looks partial at first.

From the engine:

$ docker pull alpine:3.20
Error response from daemon: failed to resolve reference "docker.io/library/alpine:3.20": failed to do request:
Head "https://registry-1.docker.io/v2/library/alpine/manifests/3.20": proxyconnect tcp: dial tcp 192.168.65.1:3128: connect: connection refused

Inside the VM (nsenter -t 1 -m -u -n -i via a privileged container): dmesg clean, sockets: used 164, TCP: inuse 4 orphan 7 tw 0 alloc 30, file-nr 591, memory 915 MB free — nothing exhausted on the guest side. wget https://api.anthropic.com/ and wget http://192.168.65.1:3128/ both fail from the VM's own namespace.

On the host, com.docker.backend services had 191 open files (no fd pressure) and still held several ESTABLISHED sockets to 160.79.104.10:443 that no guest-side socket corresponded to any more.

httpproxy.log kept logging every container connection attempt normally and then refused it — no error line anywhere:

[2026-09-11T07:42:00.199724000Z] TCP 160.79.104.10:443 container via direct connection because disabled has no TCP proxy

com.docker.backend.log error-line rate was flat (~1740/h, all the idle event streamer: error: EOF noise) before, at and after the failure. vm/init.log had no matching lines for the window (rotates every ~10 min, 10 kept, so the window is now gone).

Possibly related: #630 (Docker VMM on macOS answers container DNS itself regardless of the nameserver), which also points at the VMM host-side network stack, though that one is about DNS and this one is about every TCP/UDP/ICMP flow through 192.168.65.1.

Timeline (local time, UTC+2)

Event	Time
Docker Desktop updated to 4.90.0 (238679)	2026-09-07 22:50
Docker Desktop restarted (two agent runs had died with exit 1 an hour earlier)	2026-09-09 18:44
Docker Desktop restarted again	2026-09-10 11:45
Docker VMM selected in Settings, VM rebooted	2026-09-10 13:26
First refused container connection in the app log	2026-09-11 05:04
Diagnosed as above	2026-09-11 09:40–10:00

Workaround

docker desktop stop (a plain quit of the app was ignored; the backend's own stats GET /ping was returning context deadline exceeded), switch the Virtual Machine Manager to Apple Virtualization framework, docker desktop start. Egress verified from both containers, a fresh container and docker pull afterwards. Restarting Docker Desktop alone had fixed it twice before, for a day at a time.

Platform

macOS

Version information

• Docker Desktop 4.90.0 (238679), engine 29.7.2, kernel 7.0.12-linuxkit, UseContainerdSnapshotter: true, 8 GiB / 4 GiB swap
• macOS 26.x (Darwin 25.6.0), Apple Silicon (arm64), Mac mini
• Settings at failure: UseLibkrun: true, UseVirtualizationFramework: false (i.e. Docker VMM); no proxy configured; Tailscale installed (no exit node)

Diagnostics ID

17F9C479-A300-499D-AE5C-2281C91ED37E/20260911090418 (uploaded 2026-09-11 09:05 UTC, after the workaround; the rotated com.docker.backend.log.* and httpproxy.log it contains still cover the failure window)