com.docker.backend consumes 15k+ TCP ports, leading to host network outbound exhaustion

Description

Expected behavior

Docker Desktop should manage backend connections efficiently. The com.docker.backend process should not exhaust the host system's ephemeral port range.

Actual behavior

The com.docker.backend process is consuming an excessive number of TCP ports (currently 15,335 ports). This results in "Port Exhaustion" on the Windows host, making it impossible to initiate any new outbound network connections (e.g., browsing the web), while the machine remains reachable from the outside.

Information

Diagnostic ID: E37FF459-103D-41D1-A568-2408CA9249A3/20260131152828
Windows Version: Windows 11 25H2
Docker Desktop Version: 4.57.0
Backend: WSL2

Steps to reproduce the behavior

Start Docker Desktop (Version 4.57.0).
Run standard container workloads or leave the engine running for a period of time.
Monitor port usage via PowerShell.
Observe that com.docker.backend consumes nearly the entire ephemeral port pool (~15,000 ports).

Evidence / Logs

Direct PowerShell output from the affected system:

Windows_Version: 25H2
Docker_Version:  4.57.0
Backend_PID:     20752, 24852
Port_Count:      15335

wslconfig

[wsl2]
networkingMode=mirrored
firewall=false
dnsTunneling=true
memory=42GB
swap=100GB
processors=14
autoProxy=false
[experimental]
autoMemoryReclaim=dropcache
sparseVhd=true

Reproduce

Steps to reproduce the behavior

Start Docker Desktop (Version 4.57.0) on Windows 11 (25H2).
Deploy and run a set of standard services including:
- Web/Proxy: Nginx, OneAPI, MCSM
- Databases/AI: MySQL, ChromaDB, ComfyUI
Keep these services running for an extended period.
Trigger heavy network I/O within a container, specifically downloading large models from Hugging Face (e.g., using huggingface-cli or transformers library).
Monitor the TCP connection count for the com.docker.backend process using:
Get-NetTCPConnection -OwningProcess (Get-Process -Name "com.docker.backend").Id | Measure-Object
Observe that the port count climbs rapidly and fails to release, eventually hitting the ~15,000 limit and causing host-wide network exhaustion.

Expected behavior

Proper Connection Lifecycle Management: The com.docker.backend process should promptly release TCP ports once connections are closed or become idle, preventing "TIME_WAIT" or "BOUND" states from accumulating indefinitely.
Resource Throttling/Limiting: There should be a built-in mechanism or configurable limit to prevent Docker backend processes from monopolizing the host's entire ephemeral port pool.
Robustness under High Concurrency: The networking stack should remain stable during high-concurrency tasks (such as multi-threaded model downloads from Hugging Face) without causing host-wide network exhaustion.

docker version

Client:
 Version:           29.1.3
 API version:       1.52
 Go version:        go1.25.5
 Git commit:        f52814d
 Built:             Fri Dec 12 14:51:52 2025
 OS/Arch:           windows/amd64
 Context:           desktop-linux

Server: Docker Desktop 4.57.0 (215387)
 Engine:
  Version:          29.1.3
  API version:      1.52 (minimum version 1.44)
  Go version:       go1.25.5
  Git commit:       fbf3ed2
  Built:            Fri Dec 12 14:49:51 2025
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          v2.2.1
  GitCommit:        dea7da592f5d1d2b7755e3a161be07f43fad8f75
 runc:
  Version:          1.3.4
  GitCommit:        v1.3.4-0-gd6d73eb8
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

docker info

Client:
 Version:    29.1.3
 Context:    desktop-linux
 Debug Mode: false
 Plugins:
  ai: Docker AI Agent - Ask Gordon (Docker Inc.)
    Version:  v1.17.1
    Path:     C:\Program Files\Docker\cli-plugins\docker-ai.exe
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.30.1-desktop.1
    Path:     C:\Program Files\Docker\cli-plugins\docker-buildx.exe
  compose: Docker Compose (Docker Inc.)
    Version:  v5.0.1
    Path:     C:\Program Files\Docker\cli-plugins\docker-compose.exe
  debug: Get a shell into any image or container (Docker Inc.)
    Version:  0.0.47
    Path:     C:\Program Files\Docker\cli-plugins\docker-debug.exe
  desktop: Docker Desktop commands (Docker Inc.)
    Version:  v0.2.0
    Path:     C:\Program Files\Docker\cli-plugins\docker-desktop.exe
  extension: Manages Docker extensions (Docker Inc.)
    Version:  v0.2.31
    Path:     C:\Program Files\Docker\cli-plugins\docker-extension.exe
  init: Creates Docker-related starter files for your project (Docker Inc.)
    Version:  v1.4.0
    Path:     C:\Program Files\Docker\cli-plugins\docker-init.exe
  mcp: Docker MCP Plugin (Docker Inc.)
    Version:  v0.35.0
    Path:     C:\Program Files\Docker\cli-plugins\docker-mcp.exe
  model: Docker Model Runner (Docker Inc.)
    Version:  v1.0.6
    Path:     C:\Program Files\Docker\cli-plugins\docker-model.exe
  offload: Docker Offload (Docker Inc.)
    Version:  v0.5.40
    Path:     C:\Program Files\Docker\cli-plugins\docker-offload.exe
  pass: Docker Pass Secrets Manager Plugin (beta) (Docker Inc.)
    Version:  v0.0.22
    Path:     C:\Program Files\Docker\cli-plugins\docker-pass.exe
  sandbox: Docker Sandbox (Docker Inc.)
    Version:  v0.6.0
    Path:     C:\Program Files\Docker\cli-plugins\docker-sandbox.exe
  sbom: View the packaged-based Software Bill Of Materials (SBOM) for an image (Anchore Inc.)
    Version:  0.6.0
    Path:     C:\Program Files\Docker\cli-plugins\docker-sbom.exe
  scout: Docker Scout (Docker Inc.)
    Version:  v1.19.0
    Path:     C:\Program Files\Docker\cli-plugins\docker-scout.exe

Server:
 Containers: 27
  Running: 0
  Paused: 0
  Stopped: 27
 Images: 44
 Server Version: 29.1.3
 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 nvidia runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: dea7da592f5d1d2b7755e3a161be07f43fad8f75
 runc version: v1.3.4-0-gd6d73eb8
 init version: de40ad0
 Security Options:
  seccomp
   Profile: builtin
  cgroupns
 Kernel Version: 6.6.87.2-microsoft-standard-WSL2
 Operating System: Docker Desktop
 OSType: linux
 Architecture: x86_64
 CPUs: 14
 Total Memory: 41.14GiB
 Name: docker-desktop
 ID: a18c9dff-eae9-494e-8703-53105ab723f3
 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=npipe://\\.\pipe\docker_cli
 Experimental: false
 Insecure Registries:
  hubproxy.docker.internal:5555
  ::1/128
  127.0.0.0/8
 Live Restore Enabled: false
 Firewall Backend: iptables

Diagnostics ID

E37FF459-103D-41D1-A568-2408CA9249A3/20260131152828

Additional Info

Powershell

PS C:\Users\74498> Get-NetTCPConnection | Where-Object {$_.State -eq "Bound"} | Group-Object OwningProcess | Select-Object Name, Count | Sort-Object Count -Descending

Name  Count
----  -----
24852 15331
22364    41
39728    14
22484     4
28552     3
8556      3
8908      2
28984     1
5408      1
14020     1
31736     1
6592      1
21488     1
5200      1
21356     1
22664     1
17972     1
6032      1
5392      1
39636     1
44360     1


PS C:\Users\74498> ($tcp = Get-NetTCPConnection).Count
15526
PS C:\Users\74498> Get-Process -Id 24852

Handles  NPM(K)    PM(K)      WS(K)     CPU(s)     Id  SI ProcessName
-------  ------    -----      -----     ------     --  -- -----------
  16741   11600  1018396     480284  59,795.63  24852   1 com.docker.backend

same

0.0.0.0                             58490     0.0.0.0                             0          Bound
0.0.0.0                             58489     0.0.0.0                             0          Bound
0.0.0.0                             58488     0.0.0.0                             0          Bound
0.0.0.0                             58487     0.0.0.0                             0          Bound
0.0.0.0                             58486     0.0.0.0                             0          Bound
0.0.0.0                             58485     0.0.0.0                             0          Bound
0.0.0.0                             58484     0.0.0.0                             0          Bound
0.0.0.0                             58483     0.0.0.0                             0          Bound
0.0.0.0                             58482     0.0.0.0                             0          Bound
0.0.0.0                             58481     0.0.0.0                             0          Bound
0.0.0.0                             58480     0.0.0.0                             0          Bound
0.0.0.0                             58479     0.0.0.0                             0          Bound
0.0.0.0                             58478     0.0.0.0                             0          Bound
0.0.0.0                             58477     0.0.0.0                             0          Bound
0.0.0.0                             58476     0.0.0.0                             0          Bound

Also seeing this on Docker Desktop 4.93.0, so it's still present. Here are measurements from a host where it happens steadily, in case they help reproduce it.

Environment

Docker Desktop 4.93.0, Engine 29.8.1, Compose 5.5.1
Windows 11 Pro 10.0.26200, WSL 2.6.3.0, WSL kernel 6.6.87.2-1
WSL2 backend, default networking mode (not mirrored); two com.docker.backend processes running
128 GB RAM, 20 logical CPUs
Workload: a Compose stack of ~24 containers. Container egress is HTTPS polling of several REST APIs (AWS/Akamai-hosted), plus frequent HTTP requests from a container to a service running on the Windows host via host.docker.internal.

Symptom

com.docker.backend accumulates TCP sockets in the Bound state, all on 0.0.0.0 with local ports spread across the ephemeral range (49158–65533) and no remote address.
Growth is steady and linear: ~18/hour (~400–450/day), at the same rate overnight as during busy hours.
At ~3,800 leaked sockets (~4,000 TCP sockets host-wide), new sockets anywhere on the host started failing with WinError 10055 ("An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full"). Python and curl clients on the host were both affected.
Restarting Docker Desktop releases them all: the count went from ~3,800 to 0.

Measurements

Most closed connections pass through Bound and are released ~10 minutes later. In a 20-minute window, 153 new Bound sockets appeared and 141 were released, with a median lifetime of ~620 s.
A small fraction is never released. Of the 2,061 Bound sockets present at the start of that window, only 6 were released. About 7.6/min enter Bound and the net growth is ~0.3/min, so roughly 4% are never released.
Before entering Bound, these sockets were proxying container egress. I sampled the backend's connections every 1.5 s. The ports that turned Bound had last been established to remote :443 endpoints, or to 127.0.0.1:<port> of the host service behind host.docker.internal.
The permanent leak does not scale with the number of new connections. Raising the containers' HTTP client keep-alive from 5 s to 120 s (far fewer new connections) left the growth rate unchanged: ~490/day before (2.5 h sample) vs ~450/day after (19 h sample).
Simple patterns I generated did not leak. I counted after each burst, once it had settled. All were net ±2:
- 100× container → host.docker.internal connect/close
- 100× host → published port connect/close
- 30× container → internet :443 connect/close
- 100× container → container
- 50× container → closed host port (immediate ENETUNREACH)
- 30× container → unroutable IP with a 2 s connect timeout

So the leak seems tied to something in long-running real traffic, for example how a connection ends (remote close or RST, TLS or keep-alive teardown), rather than to plain connect/close.

How I'm measuring

$ids = (Get-Process com.docker.backend).Id
(Get-NetTCPConnection -OwningProcess $ids -State Bound).Count

Bound now: ~2,500, about 6 days after the last restart.

Workaround

A scheduled weekly docker desktop restart, plus a task that pushes the count above to a dashboard every minute and alerts at 3,000.

Diagnostics ID: 435B2559-066B-4202-8BFE-A3F6E000570D/20261007174426

Navigation Menu

Repository navigation

com.docker.backend consumes 15k+ TCP ports, leading to host network outbound exhaustion #781

Description

Expected behavior

Actual behavior

Information

Steps to reproduce the behavior

Evidence / Logs

Reproduce

Steps to reproduce the behavior

Expected behavior

Expected behavior

docker version

docker info

Diagnostics ID

Additional Info

Powershell

same

Environment

Symptom

Measurements

How I'm measuring

Workaround

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

com.docker.backend consumes 15k+ TCP ports, leading to host network outbound exhaustion #781

Description

Description

Expected behavior

Actual behavior

Information

Steps to reproduce the behavior

Evidence / Logs

Reproduce

Steps to reproduce the behavior

Expected behavior

Expected behavior

docker version

docker info

Diagnostics ID

Additional Info

Powershell

same

Activity

DreadPir8Rob425 commented on Oct 7, 2026

Environment

Symptom

Measurements

How I'm measuring

Workaround

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions