Hi there,
First off, this isn’t a question, I just want to share something that fixed my issue.
TLDR
I’m using a personal DNS with the iOS profile they provide and I have iCloud Private Relay enabled. Even though the logs show domains getting blocked, I can still resolve and access them. If you’re running into the same issue, my fix was to create my own iOS profile. I’ll share the one I use below, you just need to swap in your own DNS-over-HTTPS domain. It might work for you too.
Long version
There are quite a few blog posts and forum threads where people complain that Private Relay simply ignores custom DNS settings. For example, this Apple Discussions thread has a bunch of similar reports:
https://discussions.apple.com/thread/255172210?sortBy=rank
I’m currently on AdGuard’s private DNS with their official iOS configuration profile. I’ve always used the one AdGuard provides, but I noticed that when I block a domain and try to load it in Safari (with iCloud Private Relay enabled), the site still opens. Apple’s own docs on Private Relay say it should respect the DNS server specified in the profile.
Control D’s documentation even calls this out directly:
Inconsistent blocking behavior, things you blocked may randomly resolve as you’re essentially using 2 different DNS resolvers at the same time (one from Apple and another from Control D)
https://docs.controld.com/docs/icloud-private-relay
After digging in, I realized it’s not an Apple bug, it’s the way the provider profiles are configured.
The AdGuard profile includes this section:
<key>Action</key>
<string>EvaluateConnection</string>
<key>DomainAction</key>
<string>NeverConnect</string>
<key>Domains</key>
<array><string>*.local</string> <string>fritz.box</string> …</array>
What fixed it for me was removing that entire block. Now domains stay blocked and Private Relay no longer bypasses them. I grabbed the iOS profile from Control D, tweaked it a bit and installed it. Apple will warn you that the profile isn’t signed, but you can safely ignore that.
I’m not an Apple developer, but stripping out that section did the trick. If you’re seeing the same problem, give it a shot. All you need to do is save the file with a .mobileconfig extension (e.g., myDevice.mobileconfig) and replace the DNS-over-HTTPS endpoint with yours. You can also rename the display name that shows up on your device (it defaults to something like “Adguard - Mac”).
Here’s the XML I use, let me know if it works for you too (works also for iOS 26):
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>PayloadDisplayName</key>
<string>Adguard - Mac</string>
<key>PayloadDescription</key>
<string>Your personal encrypted DNS resolver</string>
<key>PayloadIdentifier</key>
<string>com.controld.pw23uvw5xr</string>
<key>PayloadType</key>
<string>Configuration</string>
<key>PayloadUUID</key>
<string>872D50B1-9B4B-480C-A06E-A4C5EE779662</string>
<key>PayloadVersion</key>
<integer>1</integer>
<key>PayloadScope</key>
<string>System</string>
<key>PayloadContent</key>
<array>
<dict>
<key>DNSSettings</key>
<dict>
<key>DNSProtocol</key>
<string>HTTPS</string>
<key>ServerURL</key>
<string>https://d.adguard-dns.com/dns-query/xxxxxxx</string>
</dict>
<key>PayloadType</key>
<string>com.apple.dnsSettings.managed</string>
<key>PayloadIdentifier</key>
<string>com.apple.dnsSettings.managed.872D50B1-9B4B-480C-A06E-A4C5EE779662</string>
<key>PayloadUUID</key>
<string>872D50B1-9B4B-480C-A06E-A4C5EE779662.1763287612</string>
<key>PayloadDisplayName</key>
<string>Adguard - Mac</string>
<key>PayloadOrganization</key>
<string>Adguard</string>
<key>PayloadVersion</key>
<integer>1</integer>
</dict>
</array>
</dict>
</plist>