iCloud Private Relay DNS & IP Leak (2026): How to Test Yours

Apple's iCloud Private Relay is often treated as "a VPN for Safari." In August 2026 that assumption took a hit: researchers Tommy Mysk and Talal Haj Bakry showed that a few WebKit features could send DNS lookups, or even a device's real IP, outside the relay. MacRumors and heise picked it up the next day.

This post walks through what was reported, what Private Relay actually covers, how to check your own Safari session in about two minutes with free browser tools on ipdet.app, and which mitigations still make sense.

What the August 2026 disclosure said

On 4 August 2026, Mysk published IP and DNS Leaks in WebKit Affecting Proxy Browsers and Apple iCloud Private Relay. They described three WebKit features that could send traffic outside the path configured via WKWebsiteDataStore.proxyConfigurations—the API iOS and macOS browsers use for application-level proxies:

• DNS prefetching (iOS 26.0 for this path): <link rel="dns-prefetch"> lookups used the device’s normal DNS path, so an authoritative server could see queries from the visitor’s real network rather than from a proxy or Private Relay.
• WebAuthn Related Origin Requests (since iOS 18.0): the OS credential service may fetch /.well-known/webauthn itself for related-origin passkey flows. That HTTPS request was reported to leave the Safari/Private Relay path and reveal the device IP—even without a visible passkey prompt.
• WebTransport (iOS 26.4): new WebTransport(url) could open a direct HTTP/3 connection that bypassed the configured proxy, again exposing the real IP.

Mysk wrote that the same bypasses affected iCloud Private Relay, because those requests sit outside WebKit’s ordinary page-loading traffic that Private Relay is meant to cover. They also stated that system-level VPNs are not affected the same way, because a VPN tunnels the device’s traffic as a whole.

MacRumors and heise covered the story the next day. In a follow-up on disclosure (25 August 2026), Mysk reported that on 17 August 2026 Apple shipped changes in iOS/iPadOS 26.6.1 and macOS Tahoe 26.6.2 that, in their testing, stopped those leaks from bypassing Private Relay—and that the fix was Private Relay–specific, not a blanket fix for third-party WebKit proxy browsers.

So if you are asking “does iCloud Private Relay leak?” in late 2026: it did on the paths Mysk documented before those OS updates. Keep devices updated, and still verify what Safari shows you.

What Private Relay protects—and what it does not

Apple’s own support documentation describes iCloud Private Relay as a privacy feature for iCloud+ subscribers that helps stop websites and network providers from building a detailed profile of your Safari browsing. Traffic leaves the device encrypted and passes through two separate internet relays, so that (by design) no single party—not even Apple—sees both who you are and which sites you visit.

That design is easy to confuse with a VPN:

• Scope: Private Relay targets Safari web browsing and related DNS, not every app on the device.
• Not a whole-device tunnel: Mysk’s point that VPNs were unaffected rests on system-level tunneling, not browser proxy configuration.
• Same WebKit bypasses before the fix: Private Relay was susceptible to the three paths above until Apple’s August updates; third-party proxy browsers may still need their own mitigations.
• Other browsers: On Mac you can leave Safari entirely. Private Relay remains an Apple iCloud+ / Safari-oriented feature, not “Chrome’s VPN.”

If your mental model is “Private Relay = my IP is always hidden everywhere,” that model was already too strong before August 2026.

How an “icloud private relay ip leak” shows up in practice

It helps to separate three different signals:

• Unexpected DNS resolvers (lookups leaving the path you intended): /dns-leak-test, /what-is-my-dns
• Unexpected public IP on ordinary HTTPS (the address sites see for normal page loads): /ip-lookup
• Extra WebRTC candidates (STUN/host candidates that may publish another address): /webrtc-leak-test, /webrtc-test

Mysk’s PoC site (leaks.psylo.app) targets the specific prefetch / WebAuthn / WebTransport behaviours. ipdet does not reproduce those exact pages; it shows the resolvers and addresses your current session exposes during ordinary diagnostics—what most people need after enabling Private Relay, updating iOS, or switching networks.

Step-by-step: test Private Relay with ipdet (about two minutes)

Use Safari on iPhone, iPad, or Mac. Confirm iCloud Private Relay is on (Settings → [your name] → iCloud → Private Relay, or the equivalent macOS path). Update to at least the versions Mysk reported as fixed for Private Relay if you can (iOS/iPadOS 26.6.1, macOS 26.6.2 or newer). Then:

1. Record the public IP Safari presents

Open the IP lookup page. Wait for IPv4 and IPv6 cards to settle. Note country/ASN/ISP across sources. With Private Relay working for ordinary browsing, you should not expect your access ISP’s residential label to look identical to a raw cellular or home WAN check with Private Relay off—Apple’s relay design is meant to hide your exact address from the sites you visit in Safari. Save a screenshot or short note: address(es), ASN, and whether IPv6 appeared. Multi-source disagreement on city is normal; a sudden return of your home ISP’s ASN with Private Relay supposedly on is the signal that matters.

Toggle Private Relay off, refresh, and compare. Toggle it back on and refresh again. The point is a baseline, not a courtroom proof. If nothing changes when you flip the setting, confirm you are in Safari (not an in-app browser) and that Private Relay is allowed on the current Wi-Fi or cellular network.

2. Run a DNS leak test

Open the DNS leak test. Connect to the network you care about, keep Private Relay on, and run the standard test first. Read which resolver networks answered.

How to interpret results in this context:

• Resolvers that clearly match your access ISP while you believed all Safari DNS went through Private Relay are the classic “DNS leak” smell.
• Resolvers that belong to large public or Apple-related infrastructure may still be intentional. A different resolver is not automatically a failure; an unexpected ISP resolver is the usual red flag. See also what is a DNS leak.
• If results look noisy, try the standard vs extended modes explainer and re-run. Anycast pools can show extra recursive nodes across rounds.
• Cross-check with what is my DNS for a quick view of which resolver the browser appears to be using right now.

Browser Secure DNS / DNS-over-HTTPS can change the picture. If you are diagnosing Private Relay itself, avoid stacking three DNS overrides at once. Change one variable, re-test.

3. Run the WebRTC leak test

Open the WebRTC leak test (or the live WebRTC test). Expand candidates if needed. Compare any public addresses with the IP lookup result.

WebRTC is a separate channel from the Mysk WebTransport finding, but it answers a related user question: “while I browse, what else can this browser publish?” Host candidates on a LAN are common. An unexpected public or IPv6 address beside your intended egress is worth investigating—especially on Mac with mixed VPN / relay / Wi-Fi setups.

4. Optional combined pass

The test VPN page bundles IP, DNS, and WebRTC-oriented checks. It is a convenient second pass after you change Private Relay, install an OS update, or enable a real VPN alongside Safari.

5. If you need the specialist PoC

For the exact WebAuthn / WebTransport / prefetch behaviours from the disclosure, use the researchers’ own test site linked from their post. Treat ipdet and that PoC as complementary, not substitutes.

How to read a “fail” without panicking

• One unexpected resolver once: flush DNS, disable browser Secure DNS temporarily, re-run standard then extended tests.
• Stable ISP DNS with Private Relay on (unpatched OS): update, then re-test—lookups may still be leaving the relayed path.
• IP lookup shows your raw carrier IP with Private Relay on: confirm the feature is enabled for that network (captive portals and some filters break it), then re-test on a patched OS.
• WebRTC shows an extra public IP while HTTPS looks relayed: fix WebRTC separately; that class of exposure predates the Mysk Private Relay story.

Mitigations that still help

• Update to the Private Relay fixes Mysk reported (iOS/iPadOS 26.6.1, macOS 26.6.2 or later) and verify on-device.
• Use a system-level VPN when you need whole-device tunneling, then confirm with /test-vpn.
• Lockdown Mode (for example Onion Browser’s “Silver” level) can disable WebTransport; it has real compatibility costs.
• On Mac, non-Safari browsers avoid Private Relay’s path entirely—a different tradeoff, not an upgrade to Private Relay.
• Third-party proxy browsers may still need app-level mitigations; Mysk said Apple’s change did not fix general WebKit proxy behaviour for those apps.
• Re-test after every change. The how to fix a DNS leak checklist still applies when a VPN or custom DNS is involved.

Most people who saw the headline just want a two-minute check. Measure first, then decide whether you need a full VPN, an OS update, or simply a clearer mental model of what Private Relay covers.

Next step: open Safari, confirm Private Relay, and run /ip-lookup → /dns-leak-test → /webrtc-leak-test.

Frequently asked questions

Does iCloud Private Relay leak DNS or IP addresses?

Researchers Tommy Mysk and Talal Haj Bakry reported in August 2026 that three WebKit paths—DNS prefetching, WebAuthn Related Origin Requests, and WebTransport—could bypass Private Relay and expose real DNS activity or the device IP. Apple later shipped Private Relay–specific fixes in iOS/iPadOS 26.6.1 and macOS 26.6.2. Keep the OS updated and re-test if you rely on Private Relay.

Does a VPN fix an iCloud Private Relay leak?

A system-level VPN tunnels device traffic as a whole, so the WebKit proxy bypasses described in the Mysk report do not apply the same way. Private Relay only covers Safari web traffic and DNS for iCloud+ subscribers; it is not a full-device VPN.

Does this affect Chrome on iOS?

On iOS outside the EU, browsers must use WebKit. The Mysk write-up focused on WebKit proxy configuration and Private Relay. Chrome on iOS does not use Private Relay; Private Relay is an Apple Safari (and related Apple browsing) feature. For everyday checks, compare DNS and public IP in the browser you actually use.

Is Private Relay the same as a VPN?

No. Apple documents Private Relay as a two-hop relay for Safari browsing so that no single party sees both who you are and which sites you visit. It does not encrypt or tunnel all apps on the device the way a VPN does.

How do I check for an iCloud Private Relay DNS leak with ipdet?

In Safari with Private Relay on, open the IP lookup, run the DNS leak test, then the WebRTC leak test. Compare resolvers and public addresses with what you expect from Private Relay. Specialized PoCs such as Mysk’s leaks.psylo.app target the exact WebAuthn and WebTransport paths; ipdet’s tools show the DNS exits and addresses your session exposes for ordinary browsing.

Sources

• Mysk — IP and DNS Leaks in WebKit Affecting Proxy Browsers and Apple iCloud Private Relay (2026-08-04)
• MacRumors — Apple’s iCloud Private Relay is Leaking Users’ Real IP Addresses (2026-08-05)
• heise online — iPhone browser Safari: DNS and IP leaks despite iCloud Private Relay (2026-08-05)
• Mysk — Thoughts on Responsible Disclosure (2026-08-25)
• Apple Support — About iCloud Private Relay

Originally published on ipdet.app.