36

I'm using OS X 10.8.5 and Chrome 30.

I added 127.0.0.1 youtube.com to my /etc/hosts file such that it now contains this:

# Host Database
#
# localhost is used to configure the loopback interface
# when the system is booting.  Do not change this entry.
##
127.0.0.1       localhost
255.255.255.255 broadcasthost
::1             localhost
fe80::1%lo0     localhost

127.0.0.1       youtube.com

When I run the command traceroute youtube.com I receive the expected results (youtube.com is resolved to 127.0.0.1):

traceroute to youtube.com (127.0.0.1), 64 hops max, 52 byte packets
1  localhost (127.0.0.1)  0.272 ms  0.118 ms  0.063 ms

However, when I type youtube.com in Chrome, my browser doesn't establish a connection with 127.0.0.1 but instead with the "normal" IP address for YouTube. I would have expected Chrome to resolve youtube.com to 127.0.0.1.

I have Chrome configured to use my system's proxy settings. In OS X, when I go to System Preferences > Network > "Advanced..." > Proxies, I have selected "Auto Proxy Discovery".

Why is Chrome seemingly ignoring my /etc/hosts file?

5
  • 4
    Are you certain it's trying to resolve youtube.com and not www.youtube.com? It could also be that youtube.com has a 301 redirect which is cached by the browser so that it does not even attempt to contact youtube.com (not on my computer to check). – user2313067 Sep 20 '13 at 17:47
  • @user2313067 Thank you! I revised /etc/hosts to also have a line for www.youtube.com resolving to 127.0.0.1 and that did the trick. – Jonathan Sep 20 '13 at 18:48
  • @user2313067 You may want to post your comment as an answer. – Blacklight Shining Sep 21 '13 at 3:27
  • 2
    Possible duplicate of Why is Chromium bypassing /etc/hosts and dnsmasq? – Scott Apr 12 '18 at 6:37
  • 1
    you are probably using a VPN or a chrome extension that ALTERS your connection in someway – user1735921 Dec 16 '19 at 8:40
12

Try adding www.youtube.com to your hosts file. youtube.com is redirected permanently to www.youtube.com, so as long as you have visited youtube.com once, your browser caches this response and redirects you to www.youtube.com. This address isn't in your hosts file, so chrome logically resolves it correctly.

3
  • 1
    Do this to clear your redirects superuser.com/questions/304589/… or just use incognito mode for development – james.c.funk Mar 24 '16 at 17:19
  • 1
    Adding www does not work for me. Even after clearing all my browser data and flushing my DNS. Perhaps this a anti-phishing measure baked into Chrome? – f1lt3r Aug 29 '16 at 15:11
  • adding both naked and www. versions in the hosts file worked for me. I also disabled chrome://flags/#enable-new-preconnect in Chrome – LyK May 8 '18 at 23:12
11

Google Chrome ignores your hosts file and does actual DNS lookups (despite what others may think, /etc/hosts is not part of DNS, it is what was used prior to DNS). While Google Chrome should be honoring those hosts file entries it does not. The hosts file, being an alternative to DNS, will be read when no DNS server is available (like if you disabled your network connection).

You can test this by adding "127.0.0.1 foobar.dev" to your hosts file, then enabling wireshark and watching on your network interface. Open up Chrome and put http://foobar.dev/ in your address bar and go. You'll see a DNS query in Wireshark, something like:

2   1.668727000 192.168.32.104  8.8.8.8 DNS 75  Standard query 0x663a  A foobar.dev

FWIW, Google DNS returns 127.0.53.53 for foobar.dev.

3   1.706484000 8.8.8.8 192.168.32.104  DNS 91  Standard query response 0x663a  A 127.0.53.53

A workaround would be to use HostAdmin which is an older Chrome extension that makes Chrome use the hosts. However, newer versions of Chrome (>38, apprently) no longer support it.

8
  • Chrome is actually not ignoring /etc/hosts file on OS X. At least not Chrome v43 on OS X 10.10.3. – Petr Peller Apr 12 '15 at 11:24
  • Wireshark tells a different story. – Karl Wilbur May 1 '15 at 4:27
  • 1
    The fact that Chrome also queries the Google DNS might not mean /etc/hosts is ignored. This can be simply for optimization/logging/spying purposes. I use /etc/hosts file very often on OS X and have no problems with Chrome. – Petr Peller May 1 '15 at 14:56
  • 3
    When my host file has '127.0.0.1 foo.dev' and Chrome magically resolves foo.dev to 127.0.53.53, it is IGNORING my hosts file. – Karl Wilbur May 1 '15 at 19:52
  • 1
    Yes, but with wifi on, Chrome should use the hosts file first before doing a DNS lookup. It does not. That is the problem. – Karl Wilbur Jun 15 '16 at 0:00
7

I fixed this problem by: Turn OFF "Protect you and your device from dangerous sites" in Chrome's Advanced Preferences.

Chrome's built in "protection" includes checking a domain against their own DNS directly and bypassing certain types of host entries it deems "suspicious" or entries for sites that exist that are being overridden, which means most custom host entries are ignored. Especially *.dev and *.local entries used for development.

Turning this off has resolved the issue 100% of the time for me. This was driving me mad for months when doing local development and i couldn't find the answer listed anywhere, everyone just kept saying it couldn't be happening. Turns out it was a simple toggle in advanced settings. Hope this helps you as well, cheers.

2
  • Thanks, I knew it worked last week, I changed chrome options to default some days ago and it didn't work anymore. It worked! – 98percentmonkey Jul 31 '19 at 19:11
  • 1
    Thanks, I knew it worked last week, I changed chrome options to default some days ago and it didn't work anymore. It worked! It's called "Safe Browsing" in newer versions – 98percentmonkey Jul 31 '19 at 19:26
2

I stumbled upon this question by thinking that the hosts file didn't work on Chrome for macOS for the .dev fake domains I use for development.

Actually it does work, at least on Chrome 77.

The issue is not that the domain is not found, but that all .dev are now automatically redirected to https:

This site can't be reached - Chrome

If you double-click on the domain name, you can see the culprit:

https

Now that Google broke our .dev, as a solution, the link above suggests to move to another TLD for development, like .test or .localhost.

1
  • thanks man. I spend half of day trying to resolve it. – Arthur Sult Nov 14 '20 at 13:15
0

Localhost is a convention for 127.0.0.1 address that is an internal address for tcp/ip, however, Chrome is not using the /etc/hosts to solve the address, it is using a DNS server, therefore any address does not come from your /etc/hosts, but from a DNS server, if it were using the /etc/hosts, it will have to hold the entire www hostnames to solve any address.

Hope this helps.

2
  • 1
    -1. /etc/hosts overrides any DNS servers. Yes, if you are using only /etc/hosts, it would have to contain all the domain names, but most setups also include DNS servers. If Chrome simply asks the OS to resolve the domain name, like it should, /etc/hosts will be checked first, and if it doesn't contain an entry, then a DNS query will be sent out. – Blacklight Shining Sep 21 '13 at 3:25
  • /etc/hosts should override and DNS request but this is not the case with Google Chrome. It preforms its own DNS lookups despite what may in the hosts file. This is easily demonstrable. This is specifically an issue for local development using the .dev TLD. – Karl Wilbur Aug 21 '15 at 23:34

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.