Like the title says, running os x 10.10.1. if i have an entry in my hosts file and do a dig or nslookup it still shows a different IP than what is in my hosts file even after trying to flush various caches.

I have tried the following..

  1. flush mdns and udns caches by running:
    1. sudo discoveryutil mdnsflushcache;
    2. sudo discoveryutil udnsflushcaches;
  2. flush cache using dscacheutil -flushcache
  3. reload the discoveryd.plist file
    1. sudo launchctl unload -w /System/Library/LaunchDaemons/
    2. sudo launchctl load -w /System/Library/LaunchDaemons/

my hosts file looks like this..

% cat /private/etc/hosts
# 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
  • 3
    It seems Yosemite isn't using hosts in the same way as before; it doesn't flush caches the same way either, & mDNS has taken a back seat - This has a whole bunch of chatter on the subject - Edit ahh... I guess you've already got as far as… – Tetsujin Nov 25 '14 at 20:05
  • thanks, yeah I read that already.. if this is how os x is going to be.. its crummy :\ – gorelative Nov 25 '14 at 20:07
  • 1
    I'm glad I don't have to rely on hosts on Mac, tbh; I tend to always be playing in Win when I need to do that - though that's not the only thing keeping me away from Yosemite right now :( – Tetsujin Nov 25 '14 at 20:08
  • Yeah my rmbp is the primary dev machine that I use for web development/sysadmin unfortunately and I need to get this figured out otherwise i'll be rolling back to mavericks. – gorelative Nov 25 '14 at 20:09
  • Others may want to just disable ipv6 on their workstations, I found this which explains the key: - However, even after disabling ipv6 on my nic, the problem persisted. – James T Snell Mar 10 '17 at 20:50
up vote 54 down vote accepted

/private/etc/hosts seems to be working normally for me in Yosemite (version 10.10.1). It's not necessary to flush the cache or reset discoveryd (the DNS resolver in Yosemite); sudo fs_usage | grep private/etc/hosts shows discoveryd reading the file immediately after I save changes to it.

However, dig, nslookup, and host will not see entries in it because they bypass the system's resolver and do raw DNS lookups. They've always done this, so this is not new in Yosemite. The "official" way to do a lookup through the system resolver in OS X is to use dscacheutil:

dscacheutil -q host -a name

...but since that's painfully verbose, I tend to just use ping instead (and then look at the first line, where it lists what IP it's pinging). Starting in 10.9, you can also use Network Utility's Lookup tab (before that it used dig, and therefore bypassed the system lookup policy).

BTW, please pay no attention to the macrumors thread that Tetsujin linked; it's full of people who don't quite know what they're doing and are misunderstanding the results of their own mistakes.

  • thanks Gordon, yeah I realized after I posted this that dig, nslookup, and host don't use local dns resolution. That being said /etc/hosts works as expected.. – gorelative Dec 3 '14 at 17:19
  • If I update my /etc/hosts file or my /private/etc/hosts file, then it doesn't reflect at all with dscacheutil -q host -a name or any other command.. – Trip Sep 30 '15 at 14:51
  • 2
    @Trip make sure the entries you added are properly formatted: IP address followed by a space or tab, followed by the name, then a linefeed at the end of the line. Try printing the hosts file with cat -vet /etc/hosts to make normally invisible characters visible. Each line should look like "^$" (the "^I" is a tab, and the "$" is the linefeed) or "$". If you see a "^M" (carriage return) just before the "$", you have DOS/Windows formatted text and you need to remove the carriage return(s). – Gordon Davisson Sep 30 '15 at 16:24
  • Ah wow thanks so much for the help. I followed your lead on ensuring it's a tab or space. My line reads exactly : M127.0.0.1^^M^M , I then performed dscacheutil -flushcache; sudo killall -HUP mDNSResponder and when navigating to it still brings up youtube and not localhost. – Trip Sep 30 '15 at 16:33
  • @Trip There are a number of ways of cleaning up invisible characters like those at the command line, but I'll recommend the GUI editor TextWrangler -- use View menu > Text Display > Show Invisibles to see (and edit out) things like those carriage returns. Also, it's free, and has options to show/open invisible files and folders (like /etc), and to use admin rights to edit system files. – Gordon Davisson Oct 1 '15 at 23:46

I have discovered another wrinkle with this issue.

In order to fix the problem I was having, I had to ADD IPv6 style hosts file entries.

It seems that Safari will overlook IPv4 entries IF you have an IPv6 network configuration setup.

You must add duplicate entries that resolve to IPv6 localhost address in /etc/hosts.

IPv4 entry

e.g. IPv6 entry fe80::1%lo0


  • 1
    Note that I successfully got this one to work using the shortest IP addresses: and ::1 – Ben Morrow May 30 '16 at 11:13
  • thanks, worked for me as well. was scratching my head after restoring my vhosts/apache configs after upgrading. appreciated. – Gavin Nov 11 '16 at 22:45
  • Yep this fixed it for me too. – advert2013 Mar 3 '17 at 13:46

My hosts file kept on being ignored after I edited in text edit. I tried several ways to fix the line endings, added IPv6 entries to the existing IPv4 entries with no success following JB Smiths answer above. I suspect his answer would work if my company supports IPv6 which I found out after my attempts.

The only solution that worked for me is using this free GUI plugin to edit hosts file.

I found this article because Yosemite 10.10.5 was not picking up my hosts file changes, and nothing I could do was fixing it. (I rebooted, tried flushing caches, followed every bit of advice I could find on the internet etc etc).

The answer was so simple it is embarrassing, actually, but I thought I'd share. I used textedit to edit the hosts file, and it took the liberty of saving the file as hosts.txt. Normally I would notice something like this, but I am using a fresh install of Yosemite and hadn't yet turned on "show all file extensions" so it didn't look like the file name had changed when I viewed it on my desktop.

So it's kinda obvious, and most people reading this post have probably already done this, but be sure to check that your hosts file is actually there and hasn't been replaced by hosts.txt.

To turn on displaying filename extensions go to Finder > Preferences > Show all filename extensions

To stop TextEdit from adding .txt extension to files, open a file in Text edit and choose File > Save As (If you don't see the Save As menu item, hold down the option key after you click File, and Save As should appear in the menu). Look for the option If no extension is provided, use ".txt" and deselect it.

I believe Apple will recognize this as a bug (I submitted one today). I did notice that new entries in /etc/hosts are picked up but, changes to existing entries are ignored. So.... changing an entries' hostname (e.g. web1 to web1a) provided a workaround for me.

OLD /etc/hosts entry: web1

NEW /etc/hosts entry: web1a

  • sudo dscacheutil -flushcache - will flush the directory service cache. – Kevin Buchs Aug 11 '17 at 20:41

In my case I'd set up a .ssh/config

#Host *
  User jumpy
  ProxyCommand ssh -W %h:%p
  • Would you mind explaining what the config file does and how this is related to the question? – klanomath Apr 21 '16 at 20:47
  • 1
    The question was why was an entry in a local /etc/hosts file being ignored. In my case, it was being ignored because I'd instructed to tunnel all traffic to a set of machines (* through a proxy box ( SSH obediently proxied the connection, such that it ended up being the proxy's /etc/hosts file being used to resolved the address rather than my local /etc/hosts file. – Martin Cleaver May 22 '16 at 0:31

I had a very similar issue in which i received via mail two rows to be added to my /etc/hosts

The domain contained a - like

The problem turned out to be the sender's email client - no matter to say, MS Outlook - that converted the ascii - in the long - character that Microsoft loves so much to use its embedded automatic correction to substitute the - with their -.

The hosts file did look perfect and it was hard to find this issue. When i deleted the rows and wrote it back manually, they started working.

It was so difficult to understand this, that i went deeply inside why the MacOS client should ignore the hosts file and skip directly to name resolution.

Just had this problem. It was caused by making copy/paste from hipchat instead of writing the address.

The copy process added some bad characters instead of spaces and caused the problem.

Rewriting the row solved the problem.

Your Answer


By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.