Start Here: the Rule Is Probably Fine

A domain rule that appears to do nothing in Chrome is rarely a broken rule. In almost every case the rule is exactly where you left it and the lookup simply took a different path, so the block never got a chance to apply. The five causes below are ordered by how often they turn out to be the answer, and each one has a fix you can do in a couple of minutes.

1. Chrome Is Using Its Own Encrypted DNS

This is the answer most of the time. Chrome can send its name lookups over encrypted DNS, which it calls Secure DNS and which the standard calls DNS over HTTPS, or DoH. Those lookups go to a resolver Chrome is using rather than to the system resolver, so DNS-layer blocking on the Mac never sees the question and the site loads normally.

Nothing is malfunctioning when this happens. Encrypted DNS exists to keep lookups away from whoever runs the network you joined, which is a good thing on Wi-Fi you do not control. It just also keeps them away from filtering you set up yourself, and it does that to every DNS-layer blocker equally, Pi-hole and AdGuard Home included.

The fix: 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. You can also switch Secure DNS off inside Chrome's own settings, which fixes Chrome and only Chrome. The Chrome-specific guide linked at the end walks through both.

2. Chrome Was Already Connected

The second most common cause is not a cause at all, it is timing. When you add a rule or switch on Strict Mode, Chrome may already have an open connection to the site, and it keeps names it has looked up recently in its own cache. Either one can keep a domain reachable for a while after the rule is live.

The fix: quit Chrome completely and reopen it. Not just the window, the whole application. This is the step people skip, and it is the reason a fix that worked can look like it did not. Test again with a fresh tab afterwards.

3. The Name You Blocked Is Not the Name Chrome Is Using

Rules act on names, and large sites use more names than anyone expects. A rule on a hostname also covers everything underneath it, so a rule on example.com takes www.example.com, m.example.com, and the host their images come from as well. What it does not do is guess: a second, separate domain the same company owns is its own name and needs its own rule.

The fix: stop guessing and look. Open Activity, use the site in Chrome, and read what it actually looked up. Activity shows which app looked up which domain, so you can see the real name rather than the one on the address bar, and you can block it from there directly. That rule lands in Domain Rules with everything else, where Unblock removes it.

• •

  Typos and pasted extras: a rule with a stray character blocks a name nothing is asking for, and a rule on www.example.com does not cover example.com, because coverage runs downward from the name you entered

• •

  A full address instead of a hostname: rules work on names, so enter the hostname on its own without a path or a query attached

• •

  Sibling domains: a site that serves its content from a different domain than the one you typed keeps working until you add that one too

4. An Extension Is Carrying Chrome's Traffic Elsewhere

Plenty of people run a VPN or proxy extension inside Chrome without thinking of it as one, often something installed once for a single site and left switched on. An extension that tunnels Chrome's traffic somewhere else takes its lookups along with it, and a lookup that never reaches your Mac's system resolver is a lookup your rules cannot act on.

The fix: open Chrome's extensions page and look for anything doing VPN, proxy, or unblocking work. Turn it off, restart Chrome, and test the site again. If the block works with the extension off, you have found it, and you get to decide which of the two you actually want. This one is about extensions inside the browser rather than about routing in general: a domain rule applies whether an app's traffic goes out through a VPN or straight over your normal connection.

5. Something Is Pinning a Resolver by IP

This one is genuinely uncommon on a normal desktop, and it is last for that reason. Software can be built to send its lookups to one particular resolver by IP address, with no name involved anywhere in the process. A curated list of resolvers has nothing to act on there, so it stays out of reach. The same is true of a connection made straight to an IP address: no name is looked up, so there is no name for a domain rule to act on.

The fix, honestly, is a different tool. This is the ceiling of the DNS layer itself, and every DNS-layer blocker shares it. On this Mac, the neighboring instrument is the per-app block in the Apps panel, which cuts one app off from the network entirely rather than blocking a name everywhere. That is a bigger hammer, and for a well-behaved browser you will almost never need it.

Working Through It in Order

• •

  Turn on Block Encrypted DNS in the Strict Mode section of Settings

• •

  Quit Chrome completely and reopen it, then test in a fresh tab

• •

  Open Activity, use the site, and block the name Chrome actually looked up

• •

  Disable any VPN or proxy extension in Chrome and test again

• •

  If it still resolves, you are likely at the DNS layer's ceiling, where the per-app block is the remaining option

Nine times out of ten you stop at step two. The rule was doing its job the whole time, and the only thing that had changed was the path Chrome took to ask the question.