I have a lot of bad guys in /etc/hosts pointing to

If I use host to check the domain name, I get an actual IP address instead of

What I expected the resolver to give me is the same thing that is in the hosts file. What I expected from any other access is a failure (timeout).

But when the resolver provides the real IP, I would expect a browser to show the bad guy's website. Instead, both Safari and Firefox show "Blocked!!" with the same font, font size, positioning, etc. The HTML is identical: <html><body><h1>Blocked!!</h1></body></html> suggesting that it comes from somewhere/something else. Where does this HTML come from? What would happen if the Mac tried to go there on some other (non-http/https) port?

This is the latest MacOS update on a 2012 MacBook.

  • Did you try instead of - the latter has different meanings depending on where you use it. At consumer-level it often means "use default route" it doesn't mean "route to me" like does.
    – Tetsujin
    Aug 9, 2019 at 17:02
  • I've done loopback in the past, but as I now run Apache for internal purposes (no access from the outside), I prefer to have these guys just fail rather than (possibly) return my internal default web page. What is the "default route"?
    – WGroleau
    Aug 9, 2019 at 17:08
  • Default route is often simply "your usual gateway/router" which is why always works. It always means "me".
    – Tetsujin
    Aug 9, 2019 at 17:12
  • So maybe the router is sending back "Blocked!!" ?
    – WGroleau
    Aug 9, 2019 at 18:16
  • 1
    host is misleading here because it bypasses the system resolver, and does a raw DNS lookup instead. If you want to test the system resolver instead, use dscacheutil (for example dscacheutil -q host -a name www.apple.com). Aug 9, 2019 at 19:59

1 Answer 1


As I said in a comment, host is misleading because it bypasses the system resolver (and /etc/hosts) and queries DNS directly. The entries are probably working normally.

From my tests it appears connections to actually connect to localhost (specifically, so that <html><body><h1>Blocked!!</h1></body></html> message must be coming from a web server running on your own Mac.

You can confirm this by running sudo tcpdump -Aqns0 -ilo0 port 80 to watch the raw connection. Note that it'll ask for your admin password, but will not echo anything as you type. Also, you'll have to use Control-C to exit it. In the output, you'll see traffic back & forth between two different ports on (ports 80 and whatever your browser is using), but in the request you'll see a "Host:" header indicating the site name the browser is trying to reach.

So... why is a web server running on your Mac, and why is it serving a "Blocked!" message? I have no idea, do you?

  • I run Apache because I have local copies of a couple of websites. But I don't recall doing anything to configure that … checking … (sheepish grin) … sure enough, that is the contents of index.html.en with a rather old mod date on it! Don't know why I did that, as I've disabled http(s) connections from outside. So, in order to keep links to those domains from using Apache CPU time, I have to firewall that IP, or use one that can't do anything. Maybe a block A address, since everything here is 168.x.x.x?
    – WGroleau
    Aug 11, 2019 at 4:50
  • @WGroleau Having Apache serve mostly-empty 404 messages shouldn't be much load, and will prevent the browser pausing waiting for timeouts. If you do firewall it, make sure it sends some sort of reject packet to cause an immediate connection failure, rather than just dropping the connection and letting it time out. Aug 11, 2019 at 6:07
  • Yeah, I guess just removing that file and doing a 404 (or 500, in case the firewall leaks) would be good enough.
    – WGroleau
    Aug 11, 2019 at 7:02
  • launchd can be configured to act as a super server and it could be the program the requests are being routed to.
    – CyberSkull
    Aug 11, 2019 at 8:30

You must log in to answer this question.

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