I'm using OS X 10.8.5 and Chrome 30.

I added 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.
##       localhost broadcasthost
::1             localhost
fe80::1%lo0     localhost       youtube.com

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

traceroute to youtube.com (, 64 hops max, 52 byte packets
1  localhost (  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 but instead with the "normal" IP address for YouTube. I would have expected Chrome to resolve youtube.com to

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?

  • 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). Sep 20, 2013 at 17:47
  • @user2313067 Thank you! I revised /etc/hosts to also have a line for www.youtube.com resolving to and that did the trick.
    – Jonathan
    Sep 20, 2013 at 18:48
  • @user2313067 You may want to post your comment as an answer. Sep 21, 2013 at 3:27
  • 2
  • 1
    you are probably using a VPN or a chrome extension that ALTERS your connection in someway Dec 16, 2019 at 8:40

5 Answers 5


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.

  • 1
    Do this to clear your redirects superuser.com/questions/304589/… or just use incognito mode for development 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

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 " 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 DNS 75  Standard query 0x663a  A foobar.dev

FWIW, Google DNS returns for foobar.dev.

3   1.706484000  DNS 91  Standard query response 0x663a  A

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.

  • Chrome is actually not ignoring /etc/hosts file on OS X. At least not Chrome v43 on OS X 10.10.3. 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. May 1, 2015 at 14:56
  • 4
    When my host file has ' foo.dev' and Chrome magically resolves foo.dev to, it is IGNORING my hosts file. 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. 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. Jun 15, 2016 at 0:00

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.

  • Thanks, I knew it worked last week, I changed chrome options to default some days ago and it didn't work anymore. It worked! 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 Jul 31, 2019 at 19:26

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:


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

  • thanks man. I spend half of day trying to resolve it. Nov 14, 2020 at 13:15

Localhost is a convention for 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.

  • 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. 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. 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 .