iCloud Private Relay vs NextDNS on iPhone: Which DNS You Actually Keep

iCloud Private Relay and NextDNS can both sit on the same iPhone and both claim to “handle DNS.” They do not handle the same DNS. Relay takes Safari, a slice of Mail, and a few Apple paths, and resolves names inside a two-hop proxy you do not configure. NextDNS takes whatever the OS still sends to the resolver you installed — a profile, a Wi-Fi DNS row, or an app that did not bring its own DoH. If you opened NextDNS logs expecting every hostname your thumb touched, Safari is the first hole. If you opened Relay settings expecting the whole phone to disappear from your ISP, Chrome and the weather app are the second.

I run both. I keep Relay on because I do not want my ISP’s resolver seeing every article I open in Safari. I keep NextDNS on because I still want logs, blocklists, and a resolver I can name for everything that is not Safari. At home that resolver fight is usually Pi-hole versus AdGuard Home versus the router, not another iPhone toggle. The useful question is not which product is “more private.” It is which queries leave the phone on which path, on a Tuesday, with both toggles green.

What Private Relay actually intercepts

Private Relay is not a VPN profile. It does not create a utun you can list next to WireGuard. It is an Apple feature on iCloud+, aimed at Safari and at a short list of system clients. Traffic that qualifies is sent through two hops: an Apple ingress that can see your IP and not the site, and a partner egress that can see the site and not your IP. DNS for those flows is resolved in that path. Your NextDNS profile does not get a vote.

That last sentence is the whole article if you only remember one thing. Safari with Relay on does not use the encrypted DNS profile you paid NextDNS for. It does not use the DHCP DNS from the café either. Apple’s stack asks for names in a context the local resolver never sees. NextDNS’s query log goes quiet for browsing and noisy for everything else. People read that quiet as “NextDNS is broken.” It is working. Safari left.

Mail’s “Protect Mail Activity” and “Hide My Email” are cousins, not the same switch. Limit IP Address Tracking on a Wi-Fi network is another cousin: it can engage Relay-like behavior for some traffic on that SSID. I treat each toggle as its own intercept. I do not assume that enabling Relay in iCloud settings means every socket on the phone now uses Apple’s hops. Settings → Safari → Hide IP Address has its own menu. Settings → Wi-Fi → the “i” → Limit IP Address Tracking is per network. You can have Relay “on” globally and still have a network where it is off because the captive portal broke it, or because you turned tracking limits off so a bank app would load.

What NextDNS actually intercepts

NextDNS on iPhone is usually a configuration profile that points encrypted DNS at their anycast. Sometimes it is the NextDNS app’s own profile. Sometimes it is a manual DoH/DoT row. The OS then sends eligible queries there: apps that use the system resolver. That is a lot of apps. It is not all of them.

Chrome can use its own secure DNS and never ask the system. Firefox on iOS is more constrained than on desktop, but any app that hardcodes 8.8.8.8 or ships a DNS-over-HTTPS stub will skip you. Games do this. Some CDNs do this. A surprising number of “smart” vendor apps do this so their telemetry still works when you block their domains at NextDNS. You will see the block in a desktop browser and never see the query from the phone app. The app did not use your resolver.

When Relay is off, Safari is one of the well-behaved clients. It uses the system DNS. NextDNS logs fill with every hostname you typed. That is the setup people blog about when they say “I put NextDNS on my iPhone and now I can see everything.” They had Relay off, or they were not using Safari, or they looked at a weekend when they only opened Instagram. Instagram is not Safari. Instagram may still bypass you.

NextDNS also does things Relay will not: blocklists, analytics, CNAME uncloaking, a log you can export, per-profile rules for a kid’s phone versus yours. Relay will not block a tracker hostname. It will hide your IP from the site and hide the site from your ISP for the traffic it carries. Different job. If you wanted both — hide Safari from the ISP and block ads in Safari — Relay wins the first and loses the second unless you also run something that can see Safari’s names. On iPhone, that something is not NextDNS while Relay is on. Content blockers in Safari can still hide page elements. They are not DNS.

The split you actually live with

My working model on a daily driver:

Safari, Relay on: names and IPs for those page loads go through Apple’s hops. NextDNS does not log them. My ISP does not see the names. The site sees a partner egress IP, not mine. Blocklists I maintain at NextDNS do not apply to those loads. Safari content blockers still apply.

Mail with Protect Mail Activity: remote images and some prefetch go through Apple’s privacy proxy. That is not NextDNS either. If you were using pixel-blocking via DNS, Mail already had a different plan.

Everything else that uses the system resolver: NextDNS. That includes a lot of apps, Spotlight, many system fetches, and Safari if you turn Relay off. It includes Wi-Fi captive detection after Relay gives up. It includes the NextDNS test hostname if you are checking the profile.

Apps with their own DNS: nobody you installed. You find these when a domain is blocked on the desktop and still loads on the phone, or when NextDNS shows nothing while the app is clearly talking to a CDN. Packet captures on a Mac with the iPhone as a USB gateway will show you. Most people will not do that. They will assume NextDNS “missed” it.

When the network fights Relay

Hotels, airlines, and some office Wi-Fi break Private Relay. Captive portals want to see a clear HTTP request from the phone’s real IP. Relay looks like a VPN to a bored firewall. iOS will often disable Relay on that network, sometimes quietly. Limit IP Address Tracking turns off. Safari falls back to system DNS. Suddenly NextDNS logs explode with news sites you “always use Relay for.” You did. The hotel turned it off.

I treat that as a feature when I am debugging. If I need NextDNS to see Safari for an hour, I turn Relay off on purpose instead of flying to a hotel. If I need the hotel portal to complete, I let iOS disable Relay and I do not panic when NextDNS starts showing cnn.com. The profile was always there. Safari came home.

Cellular is cleaner than hotel Wi-Fi and messier than home. Some carriers have been reported to interfere with Relay. Some do not care. I have had Relay stay up on LTE and die on a “Wi-Fi calling” SSID that was actually a work network with TLS inspection fantasies. Per-network Limit IP Address Tracking is the control you actually have. The iCloud master switch is not a guarantee that this SSID is using it.

VPN, Relay, and who wins the socket

A full tunnel VPN — Tailscale, WireGuard, a commercial app — usually takes the default route and the DNS the VPN profile pushed. Relay is not supposed to fight a VPN the way it fights the ISP. In practice I have seen three outcomes: VPN wins and Relay idles; Relay and VPN coexist and Safari still does something Apple-shaped; the VPN’s leak-protection setting and Relay both try to own DNS and a site fails in a way that looks like “NextDNS blocked it.” The NextDNS log is empty. The VPN log is empty. Safari is in a mood.

My rule: one privacy path for Safari at a time when I am testing. VPN on, Relay off, NextDNS either inside the tunnel or as the VPN’s DNS. Or Relay on, no VPN, NextDNS for the leftovers. Stacking all three is how you get a two-hour ticket about a bank app that only fails on LTE.

NextDNS can be configured as the DNS the VPN uses. That is a different install than the iOS encrypted-DNS profile. If the VPN overrides DNS, your iPhone profile may not see those queries either — they happen from the VPN egress, or from the VPN app’s own stub. Check the NextDNS analytics source. “This device” on the iPhone profile is not the same as “this WireGuard hop in another country.”

What you keep, in one table I will not draw

You keep NextDNS for: apps on the system resolver, Safari when Relay is off or broken, any hostname you want to block or log on those paths, parental rules, the comfort of a query log that is yours.

You keep Relay for: Safari (and related Apple paths) hiding from the local network and the ISP, an egress IP that is not your house, the ability to say you are not sending those names to NextDNS or to the café.

You keep neither for: apps that do their own DNS, sites you open in a browser that is not Safari if that browser uses DoH, and any traffic a VPN stole before either of them saw it.

If the goal is “I want one log of every name this phone resolved,” Private Relay is the enemy of that goal. Turn it off. Accept that the ISP or the VPN can see Safari. If the goal is “I do not want the café to see what I read,” Relay is the feature, and NextDNS is the leftover filter for the rest of the OS. If the goal is “block ads in Safari with DNS,” Relay will disappoint you; use content blockers or turn Relay off.

How I set a phone I have to live with

iCloud+ on. Private Relay on. NextDNS profile installed, logs on, blocklists I actually maintain. Safari content blockers for the cosmetic junk Relay will not stop. Limit IP Address Tracking on at home and on cellular, off on the one office SSID that breaks SAML if the IP keeps changing. Chrome installed only when I need a second browser, with its secure DNS pointed at NextDNS so I do not invent a third resolver. I still do not trust Chrome to stay pointed there after an update.

I do not use NextDNS as a parental control on a phone that also has Relay unless I have turned Relay off on that phone. A teenager’s Safari will not hit the blocklist. That is not a NextDNS bug. That is the product you enabled so the ISP would not see the names. You cannot have the log and the hide for the same query.

For a homelab angle: if you also run NextDNS linked to a home router or a Pi-hole-shaped rewrite, the iPhone will not honor that path for Relay traffic. Hairpin rules and local DNS names — ha.internal, a *.home.arpa zone — fail in Safari while Relay is on because Apple is not asking your Unbound. I keep a bookmark in a non-Safari browser, or I disable Relay on the home SSID, or I use Tailscale MagicDNS which is yet another resolver story. Local names and Relay are a bad marriage. I stopped being surprised when router.lan timed out in Safari and loaded in the NextDNS-using app.

The close

Private Relay keeps Safari’s DNS. NextDNS keeps the system resolver’s DNS. They can share a phone. They do not share a log. If you wanted one answer to “which DNS do I actually keep,” look at the app, then at Relay’s state on that network, then at whether a VPN already took the route. The toggle that is green is not the path that ran.