Why is Chrome ignoring /etc/hosts on OS X?

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?

Jonathan

Posted 2013-09-20T17:09:42.553

Reputation: 273

Possible duplicate of Why is Chromium bypassing /etc/hosts and dnsmasq?

– Scott – 2018-04-12T06:37:43.670

you are probably using a VPN or a chrome extension that ALTERS your connection in someway – user1735921 – 2019-12-16T08:40:12.903

4Are 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 – 2013-09-20T17:47:00.327

@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 – 2013-09-20T18:48:57.710

@user2313067 You may want to post your comment as an answer. – Blacklight Shining – 2013-09-21T03:27:06.293

Answers

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.

user2313067

Posted 2013-09-20T17:09:42.553

Reputation: 2 160

Do this to clear your redirects http://superuser.com/questions/304589/how-can-i-make-chrome-stop-caching-redirects or just use incognito mode for development

– james.c.funk – 2016-03-24T17:19:53.513

1Adding 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 – 2016-08-29T15:11:31.223

adding both naked and www. versions in the hosts file worked for me. I also disabled chrome://flags/#enable-new-preconnect in Chrome – LyK – 2018-05-08T23:12:02.520

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.

Karl Wilbur

Posted 2013-09-20T17:09:42.553

Reputation: 337

Chrome is actually not ignoring /etc/hosts file on OS X. At least not Chrome v43 on OS X 10.10.3. – Petr Peller – 2015-04-12T11:24:43.650

Wireshark tells a different story. – Karl Wilbur – 2015-05-01T04:27:36.280

1The 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 – 2015-05-01T14:56:05.423

This is a known issue with Chrome and there is a ticket open with Chromium to fix it. Despite how you may feel about it, it is a thing and it needs to be fixed. https://code.google.com/p/chromium/issues/detail?id=117655

– Karl Wilbur – 2015-05-01T19:48:46.727

3When 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 – 2015-05-01T19:52:07.233

As I said. I have no problems with custom /etc/hosts entries. The bug report you linked suggests the problem is somewhere in nsswitch.conf instead but the default behaviour seems to use the hosts file anyway so your issue might not be related to this anyway. – Petr Peller – 2015-05-05T09:51:34.297

I turned off my network (wifi) and Chrome/Firefox then went to the host file. – Jerinaw – 2016-06-14T17:06:00.093

1Yes, 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 – 2016-06-15T00:00:26.917

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.

Joshua Jarman

Posted 2013-09-20T17:09:42.553

Reputation: 61

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 – 2019-07-31T19:11:36.453

1Thanks, 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 – 2019-07-31T19:26:52.933

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:

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

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

Benjamin

Posted 2013-09-20T17:09:42.553

Reputation: 629

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.

Moises Najar

Posted 2013-09-20T17:09:42.553

Reputation: 67

/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 – 2015-08-21T23:34:50.460

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 – 2013-09-21T03:25:02.730