WSL mirrored networking + Podman can make a free Windows localhost port fail to bind after container traffic to host.containers.internal

Description

On Windows with WSL mirrored networking enabled, a Podman container that repeatedly connects to a host service via host.containers.internal:<port> can make a Windows process fail to bind to the same otherwise-free localhost port.

The bind failure is order-dependent:

• If the Windows server starts first, then the container: works.
• If the container starts first, then the Windows server: bind can fail with Only one usage of each socket address (protocol/network address/port) is normally permitted or WinError 10013.

Environment

• Windows 11
• WSL2
• .wslconfig:
  • networkingMode=Mirrored
  • hostAddressLoopback=true
• Podman machine running on WSL
• Podman container network: podman

Minimal reproduction

1. Start a Windows HTTP server on a free port:

python -m http.server 12345 --bind 0.0.0.0

1. Start a Podman container that loops on the host endpoint:

podman run -d --name curlprobe --network podman docker.io/curlimages/curl:8.10.1 sh -c "while true; do curl -fsS --max-time 1 http://host.containers.internal:12345/ >/dev/null 2>&1; sleep 1; done"

1. Start the Windows server after the container is already running.

Expected: bind should succeed because the port is free. Actual: bind can fail with socket-address-in-use / permission denied style errors.

Controls

• The same behavior does not reproduce in WSL alone, without Podman/container.
• The same behavior does not reproduce inside the Podman VM alone, without the container layer.
• The issue appears to require the container layer plus host.containers.internal.

Notes

• I also reproduced it on a different free port (12345), so it is not specific to a particular port number.
• Reverse order works reliably:
  • Windows server first, then container: OK

Likely area

This looks like a WSL mirrored networking / host loopback / Podman host.containers.internal interaction rather than an application bug.