host.docker.internal not resolving from inside a container to Windows 10 host.

[anwiednn]

• [X] I have tried with the latest version of Docker Desktop
• [X] I have tried disabling enabled experimental features Never enabled in the first place
• [X] 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

1. Run command: docker run --rm -it alpine sh
2. Run command: apk add curl or wget
3. Run command wget http://host.docker.internal:80 (or 8080 in my case). See output below
4. Initial fails when using host.docker.internal or gateway.docker.internal.
5. Windows host was able to be reached using IP of 192.168.14.54
6. 10 minutes it worked using host.docker.internal

[anwiednn]

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.

[anwiednn]

After a period again host.docker.internal can be resolved again.

[gabrieloshiro]

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.

[anwiednn]

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.

[adrouard]

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.

[MetinSolmaz]

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?

[MetinSolmaz]

PS: It does 'come up' after it has been down for some while again; very strange.

[anwiednn]

@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.

[turpismaximus]

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.

[clemp6r]

Hi @anwiednn, I think this may be a duplicate of #8861, don't you think?

[anwiednn]

Hi @clemp6r,

Yes it does look like the same problem I have experienced.

Cheers

[jdang67]

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.

[kraljs]

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.

[jdang67]

@kraljs, thanks for your comment. I can use this technique to renew my host.docker.internal whenever I run into this problem.

[ShanaryS]

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.

[ivictbor]

Same issue, worked fine on WSL, now it is not resolvable at all

[omri-ratson]

I have the same issue now, running 4.15.0. Docker team is there any resolution for this? ETA for a fix?

[Edjevw12]

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

[lubowiecki]

same issue here, also wsl --shutdown doesnt 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,

1. --add-host=host.docker.internal:host-gateway
2. network_mode: host
3. extra_hosts:
   • "host.docker.internal:host-gateway"

All of them works on Windows 10 pro

[Edjevw12]

https://github.com/docker/for-win/issues/8861#issuecomment-1156664386

this works for me

C:\Users\blah\blah> tasklist | findstr vpnkit.exe
C:\Users\blah\blah> taskkill /F /pid <pid of vpnkit>

[enigmadrm]

This worked for me too! Thanks!

#8861 (comment)

this works for me

C:\Users\blah\blah> tasklist | findstr vpnkit.exe
C:\Users\blah\blah> taskkill /F /pid <pid of vpnkit>

[stuartqc]

#8861 (comment)

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

[RT-Tap]

#8861 (comment)

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 {$_}

[FunTimeCoding]

#8861 (comment)

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

[mthnakdag]

Same issue shown in v4.18.0 its not resolved, you can downgrade to 4.16.3. !!!

[mdeweerd]

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.

[artmotion]

Still a favorite

[zaiddabaeen]

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.

[irfan-firdaus]

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?

[mdeweerd]

@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.