host.docker.internal not resolving from inside a container to Windows 10 host.
anwiednn opened this issue ยท 35 comments
- I have tried with the latest version of Docker Desktop
- I have tried disabling enabled experimental features Never enabled in the first place
- I have uploaded Diagnostics
- Diagnostics ID: B3FF53CA-612F-458D-BE33-019C75CAB6BD/20220414120301 or B3FF53CA-612F-458D-BE33-019C75CAB6BD/20220414120739
Actual behavior
host.docker.internal not resolving from inside the docker container at times. However resolving at other times. Please see output in section Steps to reproduce the behavior
Expected behavior
host.docker.internal resolving from inside the docker container to Windows host.
Information
-
Windows Version:
-
Docker Desktop Version:
-
WSL2 or Hyper-V backend?
Hyper-V installed
-
Are you running inside a virtualized Windows e.g. on a cloud server or a VM:
No
Output of & "C:\Program Files\Docker\Docker\resources\com.docker.diagnose.exe" check
[PASS] DD0027: is there available disk space on the host?
[PASS] DD0028: is there available VM disk space?
[PASS] DD0031: does the Docker API work?
[PASS] DD0004: is the Docker engine running?
[PASS] DD0011: are the LinuxKit services running?
[PASS] DD0016: is the LinuxKit VM running?
[PASS] DD0001: is the application running?
[SKIP] DD0018: does the host support virtualization?
[FAIL] DD0002: does the bootloader have virtualization enabled? contacting Windows service: no hypervisorlaunchtype in bootloader:
Windows Boot Loader
-------------------
identifier {current}
device partition=C:
path \Windows\system32\winload.efi
description Windows 10
locale en-us
inherit {bootloadersettings}
isolatedcontext Yes
allowedinmemorysettings 0x15000075
osdevice partition=C:
systemroot \Windows
resumeobject {a8c34b56-8d8d-11ec-87fa-8b8568642776}
nx OptIn
bootmenupolicy Standard
[2022-04-14T11:45:25.592914500Z][com.docker.diagnose.exe][I] ipc.NewClient: 8e16e548-com.docker.diagnose -> \\.\pipe\dockerBackendV2 com.docker.service.exe
[win/backend/pkg/service.NewClientForPath(...)
[ win/backend/pkg/service/service.go:42
[win/backend/pkg/service.NewClient({0x15fdbdb, 0x13}, {0x0, 0x0, 0x0})
[ win/backend/pkg/service/service.go:31 +0xd0
[common/pkg/diagkit/gather/diagnose.runBootloaderHasVirtualizationEnabled()
[ common/pkg/diagkit/gather/diagnose/bootloader_windows.go:15 +0x30
[common/pkg/diagkit/gather/diagnose.(*test).GetResult(0x1b75180)
[ common/pkg/diagkit/gather/diagnose/test.go:46 +0x43
[common/pkg/diagkit/gather/diagnose.Run.func1(0x1b75180)
[ common/pkg/diagkit/gather/diagnose/run.go:17 +0x5a
[common/pkg/diagkit/gather/diagnose.walkOnce.func1(0x1462437?, 0x1b75180)
[ common/pkg/diagkit/gather/diagnose/run.go:140 +0x77
[common/pkg/diagkit/gather/diagnose.walkDepthFirst(0x7, 0x1b75180, 0xc000399738)
[ common/pkg/diagkit/gather/diagnose/run.go:146 +0x36
[common/pkg/diagkit/gather/diagnose.walkDepthFirst(0x6, 0x1b75280?, 0xc000399738)
[ common/pkg/diagkit/gather/diagnose/run.go:149 +0x73
[common/pkg/diagkit/gather/diagnose.walkDepthFirst(0x5, 0x1b75300?, 0xc000399738)
[ common/pkg/diagkit/gather/diagnose/run.go:149 +0x73
[common/pkg/diagkit/gather/diagnose.walkDepthFirst(0x4, 0x1b75480?, 0xc000399738)
[ common/pkg/diagkit/gather/diagnose/run.go:149 +0x73
[common/pkg/diagkit/gather/diagnose.walkDepthFirst(0x3, 0x1b75600?, 0xc000399738)
[ common/pkg/diagkit/gather/diagnose/run.go:149 +0x73
[common/pkg/diagkit/gather/diagnose.walkDepthFirst(0x2, 0x1b75680?, 0xc000399738)
[ common/pkg/diagkit/gather/diagnose/run.go:149 +0x73
[common/pkg/diagkit/gather/diagnose.walkDepthFirst(0x1, 0x1b75700?, 0xc000399738)
[ common/pkg/diagkit/gather/diagnose/run.go:149 +0x73
[common/pkg/diagkit/gather/diagnose.walkDepthFirst(0x0, 0xcb00000012?, 0xc000399738)
[ common/pkg/diagkit/gather/diagnose/run.go:149 +0x73
[common/pkg/diagkit/gather/diagnose.walkOnce(0x153de00?, 0xc00035f898)
[ common/pkg/diagkit/gather/diagnose/run.go:135 +0xcc
[common/pkg/diagkit/gather/diagnose.Run(0x1b75880, 0xc000030001?, {0xc00035fb20, 0x1, 0x1})
[ common/pkg/diagkit/gather/diagnose/run.go:16 +0x1cb
[main.checkCmd({0xc00006c3d0?, 0xc00006c3d0?, 0x4?}, {0x0, 0x0})
[ common/cmd/com.docker.diagnose/main.go:131 +0x105
[main.main()
[ common/cmd/com.docker.diagnose/main.go:97 +0x27f
[2022-04-14T11:45:25.593297200Z][com.docker.diagnose.exe][I] (448bb9a3) 8e16e548-com.docker.diagnose C->S com.docker.service.exe GET /hyperv/bootloader
[2022-04-14T11:45:26.238248600Z][com.docker.diagnose.exe][I] (448bb9a3) 8e16e548-com.docker.diagnose C<-S e3ae1e26-ServiceAPI GET /hyperv/bootloader (644.8753ms): 0xc0002dce30
[PASS] DD0017: can a VM be started?
[PASS] DD0024: is WSL installed?
[PASS] DD0021: is the WSL 2 Windows Feature enabled?
[PASS] DD0022: is the Virtual Machine Platform Windows Feature enabled?
[PASS] DD0025: are WSL distros installed?
[PASS] DD0026: is the WSL LxssManager service running?
[PASS] DD0029: is the WSL 2 Linux filesystem corrupt?
[PASS] DD0015: are the binary symlinks installed?
[PASS] DD0003: is the Docker CLI working?
[PASS] DD0013: is the $PATH ok?
[PASS] DD0005: is the user in the docker-users group?
[PASS] DD0007: is the backend responding?
[FAIL] DD0014: are the backend processes running? 1 error occurred:
* com.docker.wsl-distro-proxy.exe is not running
[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?
[FAIL] DD0012: is the VM networking working? network checks failed: failed to ping host: exit status 1
[2022-04-14T11:45:40.118283300Z][com.docker.diagnose.exe][I] ipc.NewClient: 47832156-diagnose-network -> \\.\pipe\dockerDiagnosticd diagnosticsd
[common/pkg/diagkit/gather/diagnose.runIsVMNetworkingOK()
[ common/pkg/diagkit/gather/diagnose/network.go:34 +0xdd
[common/pkg/diagkit/gather/diagnose.(*test).GetResult(0x1b75800)
[ common/pkg/diagkit/gather/diagnose/test.go:46 +0x43
[common/pkg/diagkit/gather/diagnose.Run.func1(0x1b75800)
[ common/pkg/diagkit/gather/diagnose/run.go:17 +0x5a
[common/pkg/diagkit/gather/diagnose.walkOnce.func1(0x2?, 0x1b75800)
[ common/pkg/diagkit/gather/diagnose/run.go:140 +0x77
[common/pkg/diagkit/gather/diagnose.walkDepthFirst(0x1, 0x1b75800, 0xc00051b738)
[ common/pkg/diagkit/gather/diagnose/run.go:146 +0x36
[common/pkg/diagkit/gather/diagnose.walkDepthFirst(0x0, 0xcb00000012?, 0xc00051b738)
[ common/pkg/diagkit/gather/diagnose/run.go:149 +0x73
[common/pkg/diagkit/gather/diagnose.walkOnce(0x153de00?, 0xc00035f898)
[ common/pkg/diagkit/gather/diagnose/run.go:135 +0xcc
[common/pkg/diagkit/gather/diagnose.Run(0x1b75880, 0xc000030001?, {0xc00035fb20, 0x1, 0x1})
[ common/pkg/diagkit/gather/diagnose/run.go:16 +0x1cb
[main.checkCmd({0xc00006c3d0?, 0xc00006c3d0?, 0x4?}, {0x0, 0x0})
[ common/cmd/com.docker.diagnose/main.go:131 +0x105
[main.main()
[ common/cmd/com.docker.diagnose/main.go:97 +0x27f
[2022-04-14T11:45:40.118283300Z][com.docker.diagnose.exe][I] (33a7f9ed) 47832156-diagnose-network C->S diagnosticsd POST /check-network-connectivity: {"ips":["192.168.14.54","172.25.112.1","172.17.16.1"]}
[2022-04-14T11:45:40.655110300Z][com.docker.diagnose.exe][E] (33a7f9ed) 47832156-diagnose-network C<-S 276d6635-diagnosticsd POST /check-network-connectivity (536.827ms): failed to ping host: exit status 1
[common/pkg/diagkit/gather/diagnose.runIsVMNetworkingOK()
[ common/pkg/diagkit/gather/diagnose/network.go:35 +0x15b
[common/pkg/diagkit/gather/diagnose.(*test).GetResult(0x1b75800)
[ common/pkg/diagkit/gather/diagnose/test.go:46 +0x43
[common/pkg/diagkit/gather/diagnose.Run.func1(0x1b75800)
[ common/pkg/diagkit/gather/diagnose/run.go:17 +0x5a
[common/pkg/diagkit/gather/diagnose.walkOnce.func1(0x2?, 0x1b75800)
[ common/pkg/diagkit/gather/diagnose/run.go:140 +0x77
[common/pkg/diagkit/gather/diagnose.walkDepthFirst(0x1, 0x1b75800, 0xc00051b738)
[ common/pkg/diagkit/gather/diagnose/run.go:146 +0x36
[common/pkg/diagkit/gather/diagnose.walkDepthFirst(0x0, 0xcb00000012?, 0xc00051b738)
[ common/pkg/diagkit/gather/diagnose/run.go:149 +0x73
[common/pkg/diagkit/gather/diagnose.walkOnce(0x153de00?, 0xc00035f898)
[ common/pkg/diagkit/gather/diagnose/run.go:135 +0xcc
[common/pkg/diagkit/gather/diagnose.Run(0x1b75880, 0xc000030001?, {0xc00035fb20, 0x1, 0x1})
[ common/pkg/diagkit/gather/diagnose/run.go:16 +0x1cb
[main.checkCmd({0xc00006c3d0?, 0xc00006c3d0?, 0x4?}, {0x0, 0x0})
[ common/cmd/com.docker.diagnose/main.go:131 +0x105
[main.main()
[ common/cmd/com.docker.diagnose/main.go:97 +0x27f
[FAIL] DD0032: do Docker networks overlap with host IPs? network bridge has subnet 172.17.0.0/16 which overlaps with host IP 172.17.16.1
[SKIP] DD0030: is the image access management authorized?
[PASS] DD0033: does the host have Internet access?
Please investigate the following 1 issue:
1 : The test: does the bootloader have virtualization enabled?
Failed with: contacting Windows service: no hypervisorlaunchtype in bootloader:
Windows Boot Loader
-------------------
identifier {current}
device partition=C:
path \Windows\system32\winload.efi
description Windows 10
locale en-us
inherit {bootloadersettings}
isolatedcontext Yes
allowedinmemorysettings 0x15000075
osdevice partition=C:
systemroot \Windows
resumeobject {a8c34b56-8d8d-11ec-87fa-8b8568642776}
nx OptIn
bootmenupolicy Standard
The Docker engine runs inside a Linux VM. Therefore Windows must boot with the Microsoft Hypervisor enabled.
Please run:
bcdedit /set hypervisorlaunchtype auto
Steps to reproduce the behavior
- Run command: docker run --rm -it alpine sh
- Run command: apk add curl or wget
- Run command wget http://host.docker.internal:80 (or 8080 in my case). See output below
- Initial fails when using
host.docker.internalorgateway.docker.internal. - Windows host was able to be reached using IP of
192.168.14.54 - 10 minutes it worked using
host.docker.internal
After a period of time the host.docker.internal can't be resolved anymore.
This is using the same container and shell from the previous output. I cancelled the wget command after a longer period.
After a period again host.docker.internal can be resolved again.
Hi @anwiednn I had the same issue and when I came here to report it, you've already done so. So I stopped updating Docker Desktop and I told everyone on my team to do the same. We rolled back to 4.5.1.
Today I bumped the version to 4.8.2 and it seems fixed.
Thanks @gabrieloshiro for your message. I was able to resolve the issue as well.
Instead of rolling back my docker version, I updated the usage of my various docker containers and integrated those into a docker-compose env, creating it's of network and therefore not requiring to usage of host.docker.internal anymore.
I just tried in version 4.9.1 and the bug is still present.
Note that the bug occurs after a period of inactivity of network requests.
I have the same problem in Docker Desktop 4.11.1 (84025). After some random while, the host.docker.internal stops responding inside containers.
Also, the IP of the host.docker.internal inside containers is different from the host IP for some reason.
Does anyone have a workaround, other than restarting the docker stack?
PS: It does 'come up' after it has been down for some while again; very strange.
@adrouard @MetinSolmaz I had the same experience, that after a period of inactivity it stopped working and at times came back alive again. Not really a work around, but I used docker-compose to setup my various containers in the same network and therefore was not reliant anymore on host.docker.internal.
I think I am seeing a similar behavior using my own hostname (on my dev machine I tend to do that since it is a laptop and I could be on wifi or I could be hardlined). Sometimes the deployed apis I have using my dev hostname resolve and sometimes they don't. It sounds exactly like the behavior you are describing wtih docker.host.internal and could be that docker's problem is not that one resolve but an internal dns problem in general.
Using docker-desktop 4.12, after rebooting the machine I can ping host.docker.internal for some time, and then it stops working. Look like the only option is rebooting the machine again. Any command I can run to fix this problem, rebooting is the last option.
Experiencing the same issue. Usually I solve it with wsl --shutdown, then wait for docker desktop to cry that WSL 2 backend stopped, and click restart button.
@kraljs, thanks for your comment. I can use this technique to renew my host.docker.internal whenever I run into this problem.
Still the same issue in 4.15.0. However I've found a workaround. If you have a static ip to the localhost server, you can create your own host name. Replace wherever you would use host.docker.internal. Just make sure the host name is all lowercase or some containers might not resolve it. Downside is that if the ip address change, you have to update the docker compose file.
Same issue, worked fine on WSL, now it is not resolvable at all
I have the same issue now, running 4.15.0.
Docker team is there any resolution for this? ETA for a fix?
same issue here, also wsl --shutdown doesnt do the trick either. running on windows 11 pro
also switched to hyper-v but that didnt do the trick either
same issue here, also
wsl --shutdowndoesnt do the trick either. running on windows 11 pro
Same here, but I'm quite sure that it was working before. I suspect that maybe windows update broke it, but I don't know how to confirm that.
At this moment this options don't work for me at Windows 11 pro,
- --add-host=host.docker.internal:host-gateway
- network_mode: host
- extra_hosts:
- "host.docker.internal:host-gateway"
All of them works on Windows 10 pro
this works for me
C:\Users\blah\blah> tasklist | findstr vpnkit.exe
C:\Users\blah\blah> taskkill /F /pid <pid of vpnkit>
This worked for me too! Thanks!
this works for me
C:\Users\blah\blah> tasklist | findstr vpnkit.exe C:\Users\blah\blah> taskkill /F /pid <pid of vpnkit>
this works for me
C:\Users\blah\blah> tasklist | findstr vpnkit.exe C:\Users\blah\blah> taskkill /F /pid <pid of vpnkit>
This works for me too. A bit of a pain - any idea of when this will be fixed ? Its the same on windows 11 prof and docker 4.17.0
this works for me
C:\Users\blah\blah> tasklist | findstr vpnkit.exe C:\Users\blah\blah> taskkill /F /pid <pid of vpnkit>
jesus fcking christ thank you I spent WAY more time than I'd like to admit combatting this issue
EDIT: the one liner powershell version: tasklist | findstr vpnkit.exe | %{($_ -split "\s+")[1]} | Stop-Process -Id {$_}
this works for me
C:\Users\blah\blah> tasklist | findstr vpnkit.exe C:\Users\blah\blah> taskkill /F /pid <pid of vpnkit>
Thank you so much
Same issue shown in v4.18.0 its not resolved, you can downgrade to 4.16.3. !!!
It's been a few months since I used host.docker.internal and I experiencing the issue in 4.22.1 (118664) on Win 11.
Still a favorite
I had this issue (not on Windows, but on Mac), when I specified DNS settings for Docker. After removing them, host.docker.internal was working again.
Hi @zaiddabaeen, I have the same issue as you right now. I got the following error when I run the "docker-compose up" Error response from daemon: invalid IP address in add-host: "host.docker.internal".
Could you show me what you did in detail how to solve this?
@zaiddabaeen, Great observation, finding and share!
On windows, I also found dns settings in %USERPROFILE%\.docker\daemon.json - I surely chose to set those myself.
Before removing them a ping to host.docker.internal in a container indicated "Name or service not known". After removing it and restarting docker, the ping succeeded.
tasklist | findstr vpnkit.exe
I'm facing this issue in MacBook Air m1. Can you please help. I just started learning docker
tasklist | findstr vpnkit.exe
I'm facing this issue in MacBook Air m1. Can you please help. I just started learning docker
I also came here from a Mac... host.docker.internal was working with my setup the day before, but stopped working now...
My issue turned out to be that I needed to run xauth + to disable security and let the docker image communicate with the host X server... Turns out you need to do this everytime you open a terminal (unless it's in your *rc file, which seems to be not recommended)
Maybe this helps someone else running into this down the line.
root@debian:~# docker version
Client: Docker Engine - Community
Version: 26.0.0
API version: 1.45
Go version: go1.21.8
Git commit: 2ae903e
Built: Wed Mar 20 15:18:12 2024
OS/Arch: linux/amd64
Context: default
Server: Docker Engine - Community
Engine:
Version: 26.0.0
API version: 1.45 (minimum version 1.24)
Go version: go1.21.8
Git commit: 8b79278
Built: Wed Mar 20 15:18:12 2024
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: 1.6.28
GitCommit: ae07eda36dd25f8a1b98dfbf587313b99c0190bb
runc:
Version: 1.1.12
GitCommit: v1.1.12-0-g51d5e94
docker-init:
Version: 0.19.0
GitCommit: de40ad0
DEBIAN
root@debian:~# docker run --rm -it alpine sh
/ # apk add curl
fetch https://dl-cdn.alpinelinux.org/alpine/v3.19/main/x86_64/APKINDEX.tar.gz
fetch https://dl-cdn.alpinelinux.org/alpine/v3.19/community/x86_64/APKINDEX.tar.gz
(1/8) Installing ca-certificates (20240226-r0)
(2/8) Installing brotli-libs (1.1.0-r1)
(3/8) Installing c-ares (1.27.0-r0)
(4/8) Installing libunistring (1.1-r2)
(5/8) Installing libidn2 (2.3.4-r4)
(6/8) Installing nghttp2-libs (1.58.0-r0)
(7/8) Installing libcurl (8.5.0-r0)
(8/8) Installing curl (8.5.0-r0)
Executing busybox-1.36.1-r15.trigger
Executing ca-certificates-20240226-r0.trigger
OK: 12 MiB in 23 packages
/ # curl http://host.docker.internal
curl: (6) Could not resolve host: host.docker.internal
/ #
root@debian:~# docker version Client: Docker Engine - Community Version: 26.0.0 API version: 1.45 Go version: go1.21.8 Git commit: 2ae903e Built: Wed Mar 20 15:18:12 2024 OS/Arch: linux/amd64 Context: default Server: Docker Engine - Community Engine: Version: 26.0.0 API version: 1.45 (minimum version 1.24) Go version: go1.21.8 Git commit: 8b79278 Built: Wed Mar 20 15:18:12 2024 OS/Arch: linux/amd64 Experimental: false containerd: Version: 1.6.28 GitCommit: ae07eda36dd25f8a1b98dfbf587313b99c0190bb runc: Version: 1.1.12 GitCommit: v1.1.12-0-g51d5e94 docker-init: Version: 0.19.0 GitCommit: de40ad0DEBIAN
root@debian:~# docker run --rm -it alpine sh / # apk add curl fetch https://dl-cdn.alpinelinux.org/alpine/v3.19/main/x86_64/APKINDEX.tar.gz fetch https://dl-cdn.alpinelinux.org/alpine/v3.19/community/x86_64/APKINDEX.tar.gz (1/8) Installing ca-certificates (20240226-r0) (2/8) Installing brotli-libs (1.1.0-r1) (3/8) Installing c-ares (1.27.0-r0) (4/8) Installing libunistring (1.1-r2) (5/8) Installing libidn2 (2.3.4-r4) (6/8) Installing nghttp2-libs (1.58.0-r0) (7/8) Installing libcurl (8.5.0-r0) (8/8) Installing curl (8.5.0-r0) Executing busybox-1.36.1-r15.trigger Executing ca-certificates-20240226-r0.trigger OK: 12 MiB in 23 packages / # curl http://host.docker.internal curl: (6) Could not resolve host: host.docker.internal / #
Same issue here, MacOS X 14.4.1
For Googlers coming here, the answer helps to resolve the issue - #12673 (comment)
I added the following to my docker-compose.yml file:
services:
my_service:
# ห
ห
ห
ห
ห
ห
ห
ห
ห
ห
ห
ห
ห
extra_hosts:
- "host.docker.internal:host-gateway"
# ^^^^^^^^^^^