for-mac docker ps shows wrong port when disconnecting and reconnecting a container.

Description

I am observing strange behavior in the following situation:

create a network
run 2 containers n1 and n2 in that network
disconnect n2
disconnect n1
reconnect n2
when checking connectivity, connectivity to n2 is not restored but to n1 it is restored.

Reproduce

Create a network with default options

$ docker network create test
6ee2fc93a499e22342ede7b2c693ee4e9af123fc24f4e13c8e19e2ba6dcb8ebf

Start 2 containers connected to that network

$ docker run --rm -d -p 80 --name n1 --network test nginx
2ec11c9aeb10b23dab10d89df3b829d975204f126084b69eed88f6372baf9148
$ docker run --rm -d -p 80 --name n2 --network test nginx
f4099db850f6e35fa1b411812db92d2536ec56f8ba0975eeb1bf4c4d61bb7b09
$ docker ps
CONTAINER ID   IMAGE     COMMAND                  CREATED          STATUS          PORTS                                       NAMES
f4099db850f6   nginx     "/docker-entrypoint.…"   23 seconds ago   Up 23 seconds   0.0.0.0:52193->80/tcp, [::]:52193->80/tcp   n2
2ec11c9aeb10   nginx     "/docker-entrypoint.…"   28 seconds ago   Up 28 seconds   0.0.0.0:52191->80/tcp, [::]:52191->80/tcp   n1

Check connectivity

$ curl localhost:52193
<!DOCTYPE html>
<html> (...)
$ curl localhost:52191
<!DOCTYPE html>
<html>

Disconnect the 2nd container from the network $ docker network disconnect test n2
Verify connectivity

$ curl localhost:52193
^C // dead as expected
$ curl localhost:52191
<!DOCTYPE html>
<html>
(...)  // alive as expected

Disconnect n1 and verify connectivity

$ docker network disconnect test n1
$ curl localhost:52193
curl: (56) Recv failure: Connection reset by peer // as expected
$ curl localhost:52191
curl: (56) Recv failure: Connection reset by peer // as expected

(Re)connect n2

$ docker network connect test n2
$ docker network inspect test
[
    {
        "Name": "test",
        "Id": "6ee2fc93a499e22342ede7b2c693ee4e9af123fc24f4e13c8e19e2ba6dcb8ebf",
        "Created": "2025-10-27T13:47:32.852200342Z",
        "Scope": "local",
        "Driver": "bridge",
        "EnableIPv4": true,
        "EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Options": {},
            "Config": [
                {
                    "Subnet": "172.16.1.0/24",
                    "Gateway": "172.16.1.1"
                }
            ]
        },
        "Internal": false,
        "Attachable": false,
        "Ingress": false,
        "ConfigFrom": {
            "Network": ""
        },
        "ConfigOnly": false,
        "Containers": {
            "f4099db850f6e35fa1b411812db92d2536ec56f8ba0975eeb1bf4c4d61bb7b09": {
                "Name": "n2",
                "EndpointID": "a2c2b1e4d0dea3c5dd04d5d343c498508f59e0b2ec7954b1ea5bdc073ba02a8a",
                "MacAddress": "86:ff:4c:de:63:4d",
                "IPv4Address": "172.16.1.2/24",
                "IPv6Address": ""
            }
        },
        "Options": {
            "com.docker.network.enable_ipv4": "true",
            "com.docker.network.enable_ipv6": "false"
        },
        "Labels": {}
    }
]

It says that network n2 is connected.

Check connectivity via curl

$ curl localhost:52193
curl: (56) Recv failure: Connection reset by peer
// Wait, what?? Port 52193 is associated with n2 that was reconnected.
$ curl localhost:52191
<!DOCTYPE html>
<html> (...)
// Now, wait again.... n1 is now connected although we did not change its state?

Expected behavior

I was expecting a result for this command: $ curl localhost:52193

(...)

and a connection error for this command: $ curl localhost:52191 curl: (56) Recv failure: Connection reset by peer

docker version

% docker version
Client:
 Version:           28.5.1
 API version:       1.51
 Go version:        go1.24.8
 Git commit:        e180ab8
 Built:             Wed Oct  8 12:16:17 2025
 OS/Arch:           darwin/arm64
 Context:           desktop-linux

Server: Docker Desktop 4.49.0 (208700)
 Engine:
  Version:          28.5.1
  API version:      1.51 (minimum version 1.24)
  Go version:       go1.24.8
  Git commit:       f8215cc
  Built:            Wed Oct  8 12:18:25 2025
  OS/Arch:          linux/arm64
  Experimental:     false
 containerd:
  Version:          1.7.27
  GitCommit:        05044ec0a9a75232cad458027ca83437aae3f4da
 runc:
  Version:          1.2.5
  GitCommit:        v1.2.5-0-g59923ef
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

docker info

% docker info
Client:
 Version:    28.5.1
 Context:    desktop-linux
 Debug Mode: false
 Plugins:
  ai: Docker AI Agent - Ask Gordon (Docker Inc.)
    Version:  v1.9.11
    Path:     /Users/rr26ua/.docker/cli-plugins/docker-ai
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.29.1-desktop.1
    Path:     /Users/rr26ua/.docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  v2.40.2-desktop.1
    Path:     /Users/rr26ua/.docker/cli-plugins/docker-compose
  debug: Get a shell into any image or container (Docker Inc.)
    Version:  0.0.45
    Path:     /Users/rr26ua/.docker/cli-plugins/docker-debug
  desktop: Docker Desktop commands (Docker Inc.)
    Version:  v0.2.0
    Path:     /Users/rr26ua/.docker/cli-plugins/docker-desktop
  extension: Manages Docker extensions (Docker Inc.)
    Version:  v0.2.31
    Path:     /Users/rr26ua/.docker/cli-plugins/docker-extension
  init: Creates Docker-related starter files for your project (Docker Inc.)
    Version:  v1.4.0
    Path:     /Users/rr26ua/.docker/cli-plugins/docker-init
  mcp: Docker MCP Plugin (Docker Inc.)
    Version:  v0.24.0
    Path:     /Users/rr26ua/.docker/cli-plugins/docker-mcp
  model: Docker Model Runner (Docker Inc.)
    Version:  v0.1.45
    Path:     /Users/rr26ua/.docker/cli-plugins/docker-model
  offload: Docker Offload (Docker Inc.)
    Version:  v0.5.1
    Path:     /Users/rr26ua/.docker/cli-plugins/docker-offload
  sandbox: Docker Sandbox (Docker Inc.)
    Version:  v0.3.1
    Path:     /Users/rr26ua/.docker/cli-plugins/docker-sandbox
  sbom: View the packaged-based Software Bill Of Materials (SBOM) for an image (Anchore Inc.)
    Version:  0.6.0
    Path:     /Users/rr26ua/.docker/cli-plugins/docker-sbom
  scout: Docker Scout (Docker Inc.)
    Version:  v1.18.3
    Path:     /Users/rr26ua/.docker/cli-plugins/docker-scout

Server:
 Containers: 0
  Running: 0
  Paused: 0
  Stopped: 0
 Images: 42
 Server Version: 28.5.1
 Storage Driver: overlayfs
  driver-type: io.containerd.snapshotter.v1
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
 CDI spec directories:
  /etc/cdi
  /var/run/cdi
 Discovered Devices:
  cdi: docker.com/gpu=webgpu
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 05044ec0a9a75232cad458027ca83437aae3f4da
 runc version: v1.2.5-0-g59923ef
 init version: de40ad0
 Security Options:
  seccomp
   Profile: builtin
  cgroupns
 Kernel Version: 6.10.14-linuxkit
 Operating System: Docker Desktop
 OSType: linux
 Architecture: aarch64
 CPUs: 12
 Total Memory: 17.54GiB
 Name: docker-desktop
 ID: 16f9601d-bfa4-451a-b70a-dee4df4530e5
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 HTTP Proxy: http.docker.internal:3128
 HTTPS Proxy: http.docker.internal:3128
 No Proxy: hubproxy.docker.internal
 Labels:
  com.docker.desktop.address=unix:///Users/rr26ua/Library/Containers/com.docker.docker/Data/docker-cli.sock
 Experimental: false
 Insecure Registries:
  hubproxy.docker.internal:5555
  ::1/128
  127.0.0.0/8
 Live Restore Enabled: false
 Default Address Pools:
   Base: 172.16.0.0/12, Size: 24

Diagnostics ID

2FE4CEFD-2D82-4B13-AE58-4D612D05FC79/20251027135322

Additional Info

No response

Oct 27 '25 13:10 ArnoSen

Also worth noting that when you do the exact same reproducing steps but you change step 7 into reconnecting n1 instead of n2, everything works as expected.

Oct 27 '25 14:10 ArnoSen

I tried this running on a Linux machine and noticed that when you disconnect a container from a network, the ports information is empty for that particular container. When you reconnect, you get assigned a new port.

With this is mind I came to the conclusion that on Mac after reconnecting you also get a new port assigned. However, that new port is not reflected in the output of 'docker ps' .

So to conclude the bug is caused by 'docker ps' not showing the correct status after disconnecting from a network.

I was able to find out by doing this:

$ docker network create test
$ docker run --rm -d -p 80 --name n1 --network test -v $PWD/n1:/usr/share/nginx/html:ro  nginx
$ docker run --rm -d -p 80 --name n2 --network test -v $PWD/n2:/usr/share/nginx/html:ro nginx
$ docker ps
CONTAINER ID   IMAGE     COMMAND                  CREATED         STATUS         PORTS                                       NAMES
fe6f0caa1a33   nginx     "/docker-entrypoint.…"   3 seconds ago   Up 3 seconds   0.0.0.0:54873->80/tcp, [::]:54873->80/tcp   n2
f464bdfbb908   nginx     "/docker-entrypoint.…"   3 seconds ago   Up 3 seconds   0.0.0.0:54872->80/tcp, [::]:54872->80/tcp   n1
$ curl localhost:54873
n2
$ curl localhost:54872
n1
$ docker network disconnect test n1
$ docker network disconnect test n2
$ docker network connect test n2
$ docker ps
CONTAINER ID   IMAGE     COMMAND                  CREATED         STATUS         PORTS                                       NAMES
fe6f0caa1a33   nginx     "/docker-entrypoint.…"   2 minutes ago   Up 2 minutes   0.0.0.0:54873->80/tcp, [::]:54873->80/tcp   n2
f464bdfbb908   nginx     "/docker-entrypoint.…"   2 minutes ago   Up 2 minutes   0.0.0.0:54872->80/tcp, [::]:54872->80/tcp   n1
$ curl localhost:54873
curl: (56) Recv failure: Connection reset by peer // according to docker ps this is the port for n2 but that is wrong
$ curl localhost:54872
n2

So the correct container has been been reconnected and it got assigned the first free port that was previously in use by n1. This shows that docker ps is not showing the correct port after disconnecting and reconnecting.

Oct 29 '25 09:10 ArnoSen

I re-tested this with Docker Desktop 4.54.0 (212467) and the behavior is the same.

What is the status of this issue? It looks serious to me that the cli is reporting incorrect data. How am I supposed to find the port to use when I want to connect to a reconnected container?

We are using containers to simulated how application react to services like databases going down and if the application deals well with that. These tests are currently "standing on one leg".

Dec 11 '25 15:12 ArnoSen