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?
Solution 1:
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.
Solution 2:
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.
Solution 3:
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.
Solution 4:
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.