41

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?

Improve this question
6
  • 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, 2013 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, 2013 at 18:48
  • @user2313067 You may want to post your comment as an answer.
    – Blacklight Shining
    Sep 21, 2013 at 3:27
  • 2
    Possible duplicate of Why is Chromium bypassing /etc/hosts and dnsmasq?
    – Scott - Слава Україні
    Apr 12, 2018 at 6:37
  • 1
    you are probably using a VPN or a chrome extension that ALTERS your connection in someway
    – user1735921
    Dec 16, 2019 at 8:40

5 Answers 5

Reset to default
16

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.

Improve this answer
3
  • 1
    Do this to clear your redirects superuser.com/questions/304589/… or just use incognito mode for development
    – james.c.funk
    Mar 24, 2016 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, 2016 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, 2018 at 23:12
14

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.

Improve this answer
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, 2015 at 11:24
  • 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, 2015 at 14:56
  • 4
    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, 2015 at 19:52
  • 1
    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
    May 5, 2015 at 9:51
  • 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, 2016 at 0:00
9

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.

Improve this answer
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, 2019 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, 2019 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.

Improve this answer
1
  • thanks man. I spend half of day trying to resolve it.
    – Arthur Sult
    Nov 14, 2020 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.

Improve this answer
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, 2013 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, 2015 at 23:34

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .