iOS 27: Safari ads bypass Wi-Fi ad blocker via cellular Connectivity Assist

Update: iPhone 18 Pro Connectivity Assist and Pi-hole DNS bypass

I wanted to share an update on the DNS bypass issue I previously reported with my iPhone 18 Pro.

I disabled Connectivity Assist both globally and for my specific Wi-Fi network. Since then, my iPhone has consistently respected my Pi-hole DNS filtering, and I haven’t observed the previous bypass behavior.

However, I understand that some users are still experiencing this issue even after disabling Connectivity Assist.

One other possibility worth investigating is IPv6 configuration.

If your router advertises an IPv6 DNS server that bypasses Pi-hole, iOS may use that server even when your IPv4 DNS is correctly configured to point to Pi-hole.

For anyone still experiencing the problem, I would suggest checking whether:

• Your router is advertising IPv6 DNS servers.
• Those IPv6 DNS addresses point to Pi-hole or another intended filtering resolver.
• Your iPhone is receiving additional DNS servers through IPv6.

I wouldn’t necessarily recommend disabling IPv6 entirely. The better approach is to ensure both IPv4 and IPv6 DNS configurations are consistent.

In my case, disabling Connectivity Assist globally and at the individual Wi-Fi level has resolved the issue so far.

I still believe Apple should provide clearer controls and documentation around how connectivity optimization interacts with user-configured DNS infrastructure.

I discovered something interesting with my new iPhone. I run Pi-hole with Unbound on a raspberry pi5, and despite having a stable 1 Gbps connection with 6 ms latency, my iPhone was consistently loading blocked websites and ads.

Pi-hole was receiving DNS queries, both iPhones had identical DNS settings, and my other iPhone blocked everything correctly. Even Safari and Chrome behaved the same way.

The culprit? Apple’s Connectivity Assist. The moment I disabled it, Pi-hole blocking started working correctly.

My suspicion is that iOS may be silently bypassing my configured DNS filtering, potentially treating intentionally blocked domains as connectivity failures and using an alternative path.

I find it hard to believe this is simply about unreliable Wi-Fi when the connection is consistently fast and stable. It almost feels like deliberate behavior that undermines DNS-based ad blocking.

I can’t prove Apple’s intent, but the behavior is concerning. If I configure my own DNS server, my device should respect that choice instead of silently working around it.

Update: Another potential bug with Connectivity Assist on iOS 27

I discovered another concerning behavior on my iPhone 18 Pro.

After manually disabling Connectivity Assist for my Wi-Fi network, turning Wi-Fi off and back on appears to automatically re-enable the feature, even when reconnecting to the exact same network.

This raises a separate concern beyond bypassing Pi-hole DNS filtering: iOS doesn’t appear to consistently preserve the user’s explicit network preference.

My Wi-Fi connection is performing at over 1 Gbps with 6 ms idle latency and 0% packet loss, so poor network performance is not an obvious explanation.

If a user explicitly disables Connectivity Assist, that preference should persist across Wi-Fi reconnections.

I’ll also check whether disabling Connectivity Assist in both the global Wi-Fi settings and individual network settings prevents it from re-enabling.

Has anyone else reproduced this behavior on iOS 27?

I disabled connectivity assist globally and on specific SSID (ridiculous it’s in two places), disabled private WiFi address, disabled cellular, I don’t have iCloud relay, and ads are still showing. I migrated from pi-hole to UniFi built-in ad blocker a few years ago as it has been solid up to this point. Very frustrated about losing control of network behavior.

This may bypass parental controls on a WiFi network.

Please giveback internet