The Symptom Is Very Specific

You added a domain rule. Safari respects it. The desktop app that kept contacting the same place respects it. Chrome loads the site as though you had never touched anything. That pattern, one browser out of step with the rest of the machine, points almost every time at the same cause, and it is not a bug in the rule.

Chrome can send its name lookups over encrypted DNS, which it calls Secure DNS and which the standard calls DNS over HTTPS, or DoH. When it does, the lookup goes to a resolver Chrome is using rather than to the system resolver, so DNS-layer blocking on the Mac never sees the question. The site resolves, the page loads, and your rule was never consulted.

This is worth knowing before you compare products: the same thing happens with a Pi-hole, with AdGuard Home, and with a filtering resolver on your router. Chrome bypasses all of them identically, because the bypass belongs to the DNS layer rather than to any one blocker.

Fix One: Turn Secure DNS Off Inside Chrome

The setting is Chrome's own, it is not hidden, and changing it takes about fifteen seconds. Chrome's default behavior is to upgrade to encrypted DNS automatically when the provider it is already using supports it, and you can also point it at a named provider yourself. Either way, once it engages, your blocking is out of the picture.

Now the honest part. This fix is real, and it is also narrow, in three ways worth planning for.

• •

  It covers Chrome and nothing else. Firefox, Edge, Arc, and any app with its own encrypted-DNS setting are each a separate visit to a separate settings screen

• •

  It is attached to the profile. A second Chrome profile, a work profile, or a fresh install starts from Chrome's defaults again, and a profile that syncs settings between machines can carry the old value back

• •

  It is a setting, so it can move. A Chrome update that changes defaults, a reset, or someone else on the machine flipping it back all put you where you started, quietly

If you use one browser, one profile, and you are the only person on the Mac, this may genuinely be all you need. Most people are not in that situation for long.

Fix Two: Answer It Once, for the Whole Mac

The other approach is to stop chasing the setting from browser to browser. Turn on Block Encrypted DNS in the Strict Mode section of Settings. Strict Mode blocks known encrypted-DNS (DoH) resolvers, so software falls back to the system resolver, where your rules apply. It works from a curated list of resolvers, not a promise about every one that exists: software that pins its own resolver by IP address stays out of reach.

The practical difference is scope. You are not asking Chrome to cooperate, and you are not repeating the exercise for the next browser, the next profile, or the chat app that quietly does the same thing. It applies to the machine, and it keeps applying after a reboot without you thinking about it.

Test It So You Are Not Guessing

Verifying this takes a minute and settles the question properly, which beats deciding by vibe the next time a site loads when you thought it should not.

Two details make the result trustworthy. Test with a domain you have never opened in this browser session, so nothing cached is standing in for a real lookup, and do the whole test after the restart rather than around it. If the test domain is blocked and the site you actually care about is not, the problem is the name rather than the setting, which is a different fix.

What Neither Fix Reaches

• •

  Software that pins its own resolver by IP address: nothing about it depends on a name, so a curated list of resolvers has nothing to act on

• •

  Connections made straight to an IP address: no name is looked up, so there is no name for a domain rule to act on

• •

  A VPN or proxy extension inside Chrome: an extension that carries Chrome's traffic elsewhere takes its lookups along with it

• •

  A different name than the one you blocked: a rule covers anything underneath the hostname you entered, but a separate domain the site also uses is its own rule

The first two are shared by every DNS-layer blocker, and they are the price of working on names instead of inside each application. They are also rare in normal desktop software. Encrypted DNS in a mainstream browser is the common case by a wide margin, and that is the one both fixes above actually solve.

Which One Should You Use

Use both if you want the tidy answer. Strict Mode is the durable half, because it does not depend on any single browser's settings staying where you left them, and it covers the software you never think to check. Switching Secure DNS off inside Chrome is the explicit half, and it means Chrome is not quietly reaching for a resolver in the first place.

One caveat worth carrying with you. On a network you do not trust, encrypted DNS is protecting your lookups from whoever runs that network. Strict Mode is a switch, so on hotel or conference Wi-Fi where you are not filtering anything, turning it off is a perfectly reasonable choice until you are home.