Actual behavior
For some reason docker containers started with port mappings that map to 127.0.0.1 specifically, e.g. -p 127.0.0.1:8020:8020 don't work inside the WSL2 (Ubuntu) environment. I've got a basic web server container started this way and any attempts to curl http://127.0.0.1:8020 from inside the WSL2 environment (not even from Windows!) fail with a "Connection refused".
It's as if the Docker container is blocking the connection because it thinks the connection that is coming from 127.0.0.1 actually isn't coming from 127.0.0.1, because if I just use a port mapping like -p 8020:8020 which maps the ports to 0.0.0.0 instead of 127.0.0.1 then it works and the connection to the web server isn't refused anymore.
I tried debugging this by making my web server respond by emitting the incoming request IP into the body and saw something strange. I ran the web server with -p 8020:8020 to make sure I can connect to it, did a curl http://127.0.0.1:8020 from inside WSL2 (not Windows!) and the remote address was outputted to be: 172.17.0.1.
Could that be the issue? The remote address should be 127.0.0.1, but it comes in as 172.17.0.1 so Docker doesn't allow connections from WSL2 if the ports are explicitly only mapped to 127.0.0.1


Expected behavior
WSL2 should be able to connect to any containers with port mappings that explicitly use 127.0.0.1 as the hostname instead of the very permissive 0.0.0.0.
Information
- Windows Version: Windows 11 Pro Version 10.0.22621 Build 22621
- Docker Desktop Version: See below
- WSL2 or Hyper-V backend? : WSL2 backend
- Are you running inside a virtualized Windows e.g. on a cloud server or a VM:
Output of & "C:\Program Files\Docker\Docker\resources\com.docker.diagnose.exe" check
C:\Users\fabis> "C:\Program Files\Docker\Docker\resources\com.docker.diagnose.exe" check
[2023-01-20T14:18:00.564405100Z][com.docker.diagnose.exe][I] set path configuration to OnHost
Starting diagnostics
[PASS] DD0027: is there available disk space on the host?
[PASS] DD0028: is there available VM disk space?
[PASS] DD0002: does the bootloader have virtualization enabled?
[SKIP] DD0018: does the host support virtualization?
[PASS] DD0001: is the application running?
[PASS] DD0022: is the Virtual Machine Platform Windows Feature enabled?
[PASS] DD0021: is the WSL 2 Windows Feature enabled?
[PASS] DD0024: is WSL installed?
[PASS] DD0025: are WSL distros installed?
[PASS] DD0026: is the WSL LxssManager service running?
[PASS] DD0029: is the WSL 2 Linux filesystem corrupt?
[PASS] DD0035: is the VM time synchronized?
[PASS] DD0017: can a VM be started?
[PASS] DD0016: is the LinuxKit VM running?
[PASS] DD0011: are the LinuxKit services running?
[PASS] DD0004: is the Docker engine running?
[PASS] DD0015: are the binary symlinks installed?
[PASS] DD0031: does the Docker API work?
[PASS] DD0013: is the $PATH ok?
[PASS] DD0003: is the Docker CLI working?
[PASS] DD0005: is the user in the docker-users group?
[PASS] DD0038: is the connection to Docker working?
[PASS] DD0014: are the backend processes running?
[PASS] DD0007: is the backend responding?
[PASS] DD0008: is the native API responding?
[PASS] DD0009: is the vpnkit API responding?
[PASS] DD0010: is the Docker API proxy responding?
[PASS] DD0006: is the Docker Desktop Service responding?
[SKIP] DD0030: is the image access management authorized?
[PASS] DD0033: does the host have Internet access?
[PASS] DD0002: does the bootloader have virtualization enabled?
[PASS] DD0018: does the host support virtualization?
[PASS] DD0001: is the application running?
[PASS] DD0022: is the Virtual Machine Platform Windows Feature enabled?
[PASS] DD0021: is the WSL 2 Windows Feature enabled?
[PASS] DD0024: is WSL installed?
[PASS] DD0025: are WSL distros installed?
[PASS] DD0026: is the WSL LxssManager service running?
[PASS] DD0029: is the WSL 2 Linux filesystem corrupt?
[PASS] DD0035: is the VM time synchronized?
[PASS] DD0017: can a VM be started?
[PASS] DD0016: is the LinuxKit VM running?
[PASS] DD0011: are the LinuxKit services running?
[PASS] DD0004: is the Docker engine running?
[PASS] DD0015: are the binary symlinks installed?
[PASS] DD0031: does the Docker API work?
[PASS] DD0032: do Docker networks overlap with host IPs?
No fatal errors detected.
Docker version
Client: Docker Engine - Community
Cloud integration: v1.0.29
Version: 20.10.22
API version: 1.41
Go version: go1.18.9
Git commit: 3a2c30b
Built: Thu Dec 15 22:28:22 2022
OS/Arch: linux/amd64
Context: default
Experimental: true
Server: Docker Desktop
Engine:
Version: 20.10.22
API version: 1.41 (minimum version 1.12)
Go version: go1.18.9
Git commit: 42c8b31
Built: Thu Dec 15 22:26:14 2022
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: 1.6.14
GitCommit: 9ba4b250366a5ddde94bb7c9d1def331423aa323
runc:
Version: 1.1.4
GitCommit: v1.1.4-0-g5fd4c4d
docker-init:
Version: 0.19.0
GitCommit: de40ad0
Reproduction
I don't think this can be reproduced because things worked fine yesterday and now they suddenly don't work. There were no updates to my system or anything so I have no idea what could've changed.
I would still really appreciate it if someone could offer some extra debugging/troubleshooting steps for me to try.
Actual behavior
For some reason docker containers started with port mappings that map to 127.0.0.1 specifically, e.g.
-p 127.0.0.1:8020:8020don't work inside the WSL2 (Ubuntu) environment. I've got a basic web server container started this way and any attempts tocurl http://127.0.0.1:8020from inside the WSL2 environment (not even from Windows!) fail with a "Connection refused".It's as if the Docker container is blocking the connection because it thinks the connection that is coming from 127.0.0.1 actually isn't coming from 127.0.0.1, because if I just use a port mapping like
-p 8020:8020which maps the ports to0.0.0.0instead of127.0.0.1then it works and the connection to the web server isn't refused anymore.I tried debugging this by making my web server respond by emitting the incoming request IP into the body and saw something strange. I ran the web server with
-p 8020:8020to make sure I can connect to it, did acurl http://127.0.0.1:8020from inside WSL2 (not Windows!) and the remote address was outputted to be: 172.17.0.1.Could that be the issue? The remote address should be 127.0.0.1, but it comes in as 172.17.0.1 so Docker doesn't allow connections from WSL2 if the ports are explicitly only mapped to 127.0.0.1
Expected behavior
WSL2 should be able to connect to any containers with port mappings that explicitly use
127.0.0.1as the hostname instead of the very permissive0.0.0.0.Information
Output of
& "C:\Program Files\Docker\Docker\resources\com.docker.diagnose.exe" checkDocker version
Client: Docker Engine - Community
Cloud integration: v1.0.29
Version: 20.10.22
API version: 1.41
Go version: go1.18.9
Git commit: 3a2c30b
Built: Thu Dec 15 22:28:22 2022
OS/Arch: linux/amd64
Context: default
Experimental: true
Server: Docker Desktop
Engine:
Version: 20.10.22
API version: 1.41 (minimum version 1.12)
Go version: go1.18.9
Git commit: 42c8b31
Built: Thu Dec 15 22:26:14 2022
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: 1.6.14
GitCommit: 9ba4b250366a5ddde94bb7c9d1def331423aa323
runc:
Version: 1.1.4
GitCommit: v1.1.4-0-g5fd4c4d
docker-init:
Version: 0.19.0
GitCommit: de40ad0
Reproduction
I don't think this can be reproduced because things worked fine yesterday and now they suddenly don't work. There were no updates to my system or anything so I have no idea what could've changed.
I would still really appreciate it if someone could offer some extra debugging/troubleshooting steps for me to try.