After a recent Chrome update to v73, Chrome no longer uses my hosts file for IPv6 addresses. I have an entry like:

::1    some-project.test

Trying to go to https://some-project.test results in ERR_NAME_NOT_RESOLVED. If I change the entry to, the hostname resolves.

There's no problem with my hosts file entry. It's worked fine for months on previous versions of Chrome. I can ping some-project.test. Firefox works fine. I can even run a proxy like Fiddler and Chrome can access it that way. I just can't use Chrome directly.

Any suggestions for working around this?

Update: It seems dependent on the network I'm connected to. After moving from a public WiFi network back home, this is working again. I'm not sure how that's possible... shouldn't the hosts file override anything in DNS? And, shouldn't Chrome be using the system resolver anyway? Everything else on the system does and works fine.

Update 2: Back on home wired Ethernet... broken again. The problem is intermittent.

  • I can confirm Chrome 73 absolutely uses the hosts file on Windows. There is some other unidentified reason you are unable to navigate to the .test domain you have configured. – Ramhound Apr 4 '19 at 22:12
  • @Ramhound It's using the hosts file for me, but not for IPv6 entries. It only works for IPv4 entries in the hosts file. Can you confirm that IPv6 hosts file entries are working for you in Chrome v73? Thanks. – Brad Apr 4 '19 at 22:14
  • According to stackoverflow.com/questions/42636711/…, Chrome doesn't like .test for some uses of the Hosts file. Try some-project.local instead, just to rule that out. – Doug Deden Apr 4 '19 at 22:26
  • @Brad - Then as somebody as specified it's the name of the domain your using not the fact it IPv6. Chrome 73 absolutely still uses the hosts file for both IPv4 and IPv6. Related – Ramhound Apr 4 '19 at 22:29
  • @DougDeden Using something.local or even just something doesn't work. Additionally, something.test works just fine for IPv4 addresses. It also worked fine for IPv6 addresses yesterday. – Brad Apr 4 '19 at 22:37

There is a know bug in Chrome which might be responsible for your problem:
Issue 530482: Can't reach private IPv6 hosts on networks without global IPv6 connectivity.

The discussion in the bug report clarifies that Chrome launches an IPv6 probe to determine if there is IPv6 support, by checking with a remote address. If that IPv6 probe fails, Chrome will mask out any other IPv6 results, in effect disabling IPv6 and ignoring it forever.

The explanation is then that if IPv6 support is sketchy on the network, so that this single initial IPv6 probe done by Chrome fails, Chrome will just disable IPv6 resolving totally, including local IPv6 resolving from the hosts file.

A workaround mentioned is:

Add a network route to 2001:4860:4860::8888. Doesn't have to actually be functional (could just drop requests to it). As long as Chrome can connect a UDP socket to the address, it will pass the heuristic checking IPv6-connectivity and allow AAAA DNS queries and IPv6 resolve results.

Other more limited workarounds are mentioned at the end of the bug report.

The bug report dates from 2015, but was still alive in May 2019, so it may perhaps be currently in process.

| improve this answer | |
  • 1
    Awesome! Thanks for digging this up. I'm sure that's going to be it. I'm going to experiment with some of the workarounds and see. Will accept the answer later if this works out. – Brad Jun 24 '19 at 16:54
  • 3
    Yep, that worked. net sh, interface ipv6, add route 2001:4860:4860::8888/128 interface=1. – Brad Jun 24 '19 at 17:10
  • 1
    @Brad - Thanks so much for this. I've been banging my head against the desk trying to get Chrome to connect to hosts via my office's IPv6 VPN. I added that route and voila, it worked instantly. – oobayly Apr 2 at 14:19
  • For anyone else who finds this, the command is actually netsh, not net sh – user125355 Jun 3 at 19:27

Your hosts file should be consistent, eg; localhost is 127.0.01. Then some-project.test should also be available on, and since the IPv6 address ::1 typically, and traditionally also points to localhost, and the IPv4 address As not all systems are necessarily IPv6 capable -- yes, even in this day, and age. :)

The problem, like localhost is that test is a TLD (just like .com).

My suggested hosts file:

# following 2 entries are *optional*
::1    localhost    localhost

::1    test project.test    test project.test

See what I'm talking about? Some applications (and OSs) assume a localhost "host". So you may find you require an entry for it -- see; optional in the example above.

Lastly. Make sure your resolver flushes it's DNS cache. As to your system. It should see the change(s) immediately. But you should check first.

| improve this answer | |
  • My question has nothing to do with localhost. My system supports IPv6 just fine. All other applications on the system can resolve my hostnames just fine. Even Chrome works through a proxy on the same machine. And, there is absolutely nothing wrong with using .test... it's the prescribed way, as indicated by RFC2606. Also, yes, I've flushed DNS caches and the Chrome resolver cache. – Brad Jun 24 '19 at 1:41
  • StackExchange speaks to a broad audience. As such, I chose to make my answer as detailed as necessary to answer not only your specific question. But also to others with a similar question. I can not presume to know the depth of knowledge that either you, or others posses. I can only infer. Which is not a very reliable position to take. What you didn't address in your reply. Is to whether my proposed hosts file did, or didn't work. I will not make an assumption in this regard. As that has at best, a 50% chance of being correct, as being incorrect. – somebody Jun 24 '19 at 3:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.