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 '19 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 '19 at 17:08
  • Default route is often simply "your usual gateway/router" which is why always works. It always means "me". – Tetsujin Aug 9 '19 at 17:12
  • So maybe the router is sending back "Blocked!!" ? – WGroleau Aug 9 '19 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). – Gordon Davisson Aug 9 '19 at 19:59

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 '19 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. – Gordon Davisson Aug 11 '19 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 '19 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 '19 at 8:30

You must log in to answer this question.

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