Docker Desktop Engine API HTTP 500 after persisted custom network overlaps internal 192.168.65.7 endpoint

[yangruichao3q]

Bug report

The Docker Desktop CLI reported the diagnostic ID as uploaded successfully on 2026-09-05.

Issue summary

Docker Desktop remains indefinitely in the starting state. The host API proxy Unix socket exists and is owned by the running Docker Desktop backend, but Docker CLI requests such as /v1.55/version and /v1.55/info return HTTP 500. API 1.44 fails in the same way, so this is not a simple client/server API-version mismatch.

Read-only log analysis shows that the Docker VM starts, the Docker data disk mounts read/write, containerd reports ready, and dockerd completes initialization and begins listening inside the VM. The host API proxy then repeatedly fails to connect to Docker Desktop's internal Engine endpoint at 192.168.65.7:2376 with no route to host.

Immediately before the failure, a persistent custom Docker network named phase1c-r18a4-calibration-v4-net was created with subnet 192.168.65.0/28. This subnet contains the internal Engine endpoint 192.168.65.7. The Docker Desktop gVisor network layer added the route 192.168.65.0/28 via 192.168.65.3, after which the API proxy became unable to reach 192.168.65.7:2376.

One authorized docker desktop restart exited with status 0. During that restart, the VM, data disk, containerd, and dockerd all came up successfully and the internal Engine ping briefly returned OK. The persistent custom network was then re-registered and the overlapping /28 route was re-added, after which the API proxy resumed failing with no route to host. Docker Desktop returned to the indefinite starting state.

There is no observed evidence of insufficient host disk space, VM or daemon panic, ext4 mount failure, bad superblock, journal abort, or Docker data-disk corruption. The sparse Docker.raw file is present and was successfully attached and mounted by the VM.

Docker.raw contains existing Docker state that must be preserved, including a protected MySQL volume and database recovery evidence. Because the Engine API is unavailable, the current identities and fingerprints of the protected container and volume cannot be re-verified. We must not risk modifying or deleting any existing container, volume, network, image, or database data.

The user explicitly declines factory reset, Clean / Purge data, destructive reinstallation, direct mounting or editing of Docker.raw, and manual modification of Docker's internal network database.

Requested supported recovery procedure

Please provide a Docker-supported, non-destructive procedure to remove or neutralize only the conflicting persistent network, or otherwise restore the internal route to 192.168.65.7:2376, while preserving the existing Docker.raw, containers, volumes, images, networks, and database contents.

Please also state whether Docker Desktop should be fully quit before copying Docker.raw as a safety backup, and provide the officially supported copy procedure for this macOS/Apple Silicon configuration, including how to preserve sparse-file semantics and ownership/permissions.

Questions requiring explicit answers

1. When the Engine API is inaccessible, how can we safely remove or neutralize the persistent network whose 192.168.65.0/28 subnet overlaps Docker Desktop's internal 192.168.65.7 Engine endpoint?
2. During the supported recovery procedure, how can we guarantee that the current Docker.raw, containers, volumes, images, networks, and database data are not modified or deleted?
3. If reinstalling Docker Desktop is absolutely required, how can a new installation be made to reuse the original Docker.raw without initializing, migrating over, truncating, or otherwise overwriting it?

Please do not recommend factory reset, Clean / Purge data, or deletion of Docker resources as a first-line action. We will not perform any remediation until the preservation guarantees and exact procedure are provided and reviewed.

Additional diagnostic observations

• The uploaded diagnostic output itself lists both 192.168.65.7/32 via 192.168.65.3 and the conflicting 192.168.65.0/28 via 192.168.65.3 route.
• The host Docker socket is a current Unix socket, not a stale symlink, and there is no context or DOCKER_HOST mismatch.
• The host filesystem had approximately 482 GiB free during the read-only investigation.

Platform

macOS

Version information

- macOS 26.5, build 25F71, Apple Silicon arm64
- Docker Desktop 4.84.0, build 234817
- Docker Desktop CLI plugin v0.4.3
- Docker CLI 29.6.2, client API 1.55
- Active context: `desktop-linux`

Diagnostics ID

4410FF3E-944C-424D-9D19-05B6D6938559/20260905093224