A cutaway home showing normal device traffic through a router and one private route bypassing it

When a domain is blocked on the router but still opens on one phone, the router may not be broken. That device may be asking a different resolver—or sending its browsing traffic through a privacy service.

Short answer: router-level domain blocking usually depends on the router seeing DNS requests. Browser Secure DNS, Android Private DNS, VPN apps and Apple iCloud Private Relay can change or encrypt that path, so the router’s DNS rule may not see the same request.

What router-level blocking can actually see

Many parental-control and filtering systems work by controlling DNS: the lookup that turns a name such as example.com into an IP address. If a device uses the DNS server supplied by the router, the router or filtering service can apply its rule.

If the device sends the lookup elsewhere through an encrypted connection, a DNS-only rule loses its decision point. The router still carries the packets, but it may no longer see the domain lookup in a form the filter can use.

The common bypass paths

Browser Secure DNS

Modern browsers can use DNS over HTTPS. The DNS request travels inside encrypted web traffic to a resolver selected by the browser, potentially bypassing the DNS setting distributed by the router.

Android Private DNS

Android Private DNS can use encrypted DNS at the operating-system level. A provider hostname set there can apply beyond one browser.

A VPN app

A device-level VPN commonly sends DNS and web traffic through its own tunnel. From the home router’s perspective, the destination may be the VPN server rather than the requested website. This is one reason router and device VPN setups can behave differently.

iCloud Private Relay

For supported Safari traffic, iCloud Private Relay hides the browsing destination from the network provider and encrypts DNS records. Apple notes that this can affect networks that require auditing, filtering or parental controls.

A five-minute diagnosis

  1. Confirm the device is on home Wi-Fi, not cellular data.
  2. Try the same blocked domain on two devices. If only one bypasses the rule, inspect that device first.
  3. Temporarily disable the browser’s Secure DNS setting and retest.
  4. On Android, inspect Settings → Network & internet → Private DNS.
  5. Pause device-level VPN, security and privacy-relay features one at a time, then retest.
  6. Reconnect Wi-Fi or clear the browser’s DNS cache so an old answer does not distort the result.
Change one variable at a time. Turning off four privacy settings at once may make the block work, but it will not tell you which path caused the exception.

Privacy and household policy are different goals

Encrypted DNS and privacy relays are not inherently malicious; they are designed to reduce observation and profiling. Network filtering is also not inherently invasive; families and organizations use it for safety, focus and device policy. The conflict appears when a device’s privacy control overrides a network rule without anyone realizing it.

Decide which requirement wins for each device. An adult’s personal phone may keep privacy features enabled. A child’s managed tablet may need device-level controls that cannot be changed from the browser. A work laptop may be governed by its employer.

Why blocking IP addresses is not a simple fix

Large services share infrastructure, change addresses and use content-delivery networks. Blocking an IP can break unrelated sites and still miss the target later. DNS filtering is useful, but it is not a complete enforcement layer against encrypted alternate paths.

Build policy in layers

  • Use router-level DNS policy for broad coverage and simple devices.
  • Use managed device controls where the rule must survive alternate DNS.
  • Separate trusted, guest and IoT devices when their requirements differ.
  • Document exceptions so a future “mystery bypass” has an explanation.

Bottom line

If router blocking misses one browser or phone, trace the DNS and traffic path before changing the block list. The exception is often Secure DNS, Private DNS, a VPN or Private Relay—not a random router failure.