iCloud Private Relay Explained: What It Does and Doesn't Do
Abhay khant
Jan 1, 1970 • 11 min read
iCloud Private Relay explained in one line: it is a proxy for Safari traffic, not a VPN for your whole device.
TL;DR iCloud Private Relay is a paid iCloud+ feature (June 2021) that routes Safari traffic through a dual-hop proxy, Apple ingress then a Cloudflare or Fastly egress, so no single party sees both your identity and your destination. It is not a VPN: no exit-country choice, Safari only, and the August 2026 WebKit disclosure showed three vectors leak past it anyway. Apple launched the feature in June 2021 as part of paid iCloud+, and it routes browsing through two separate hops so no single party, Apple included, ever sees both your IP address and the sites you visit (Wikipedia's iCloud Private Relay entry). The design is genuinely clever. It also has sharp limits, and the summer of 2026 made those limits impossible to ignore.
This guide explains what Private Relay does, where its coverage ends, and how to test your actual setup instead of trusting a toggle. The August 2026 WebKit disclosure is why this topic needs revisiting now, and it gets a full section below.
iCloud Private Relay Explained: What It Is and How It Works
iCloud Private Relay is a two-hop proxy built into Safari on iOS 15 and macOS Monterey or later, included with every paid iCloud+ plan (Wikipedia). It strips your real IP address from outbound browsing and substitutes one assigned by Apple's infrastructure. Websites see an egress address shared with thousands of other subscribers. Your network sees a single connection to Apple. Neither side holds both your identity and your destination.
The two-hop architecture
The first hop runs from your device to Apple's ingress servers. Apple sees your real IP but receives only encrypted requests bound for its egress partners. The second hop passes traffic to Cloudflare or Fastly, which resolve DNS, fetch the pages, and hand responses back. Those egress servers see the destination but never your real address. Because no single hop holds both data points, the privacy guarantee rests on a genuine cryptographic split rather than a corporate promise.
This is a different design from the tunnel a VPN gives you. A VPN encrypts packets at the network layer and moves them through one controlled endpoint. Private Relay operates higher in the stack as an application-layer proxy that rewrites what Safari sends. That difference in layer explains why its protections apply only where WebKit handles the traffic, a distinction that matters again later in this post.
MASQUE and ODoH
The transport stack matters as much as the proxy design. Private Relay runs on MASQUE, a protocol family built on QUIC and HTTP/3, the same modern transport generation that includes WebTransport (MDN's WebTransport reference). DNS lookups ride on Oblivious DoH, which encrypts each query twice and relays it through an intermediate server so the final resolver cannot tie the query to your IP (RFC 9230).
Practically, your ISP cannot see which domains Safari resolves while the relay is active. That differs from standard DNS over HTTPS, which hides queries from eavesdroppers on the path but not from the resolver you choose (Wikipedia's DNS over HTTPS entry). ODoH adds a proxy layer that blinds the resolver itself, and that extra hop is the meaningful upgrade here.
What it covers
Coverage is the limit most people miss. Private Relay applies only to Safari and apps built on WebKit's networking stack. Mail, system-level lookups, and third-party browsers sit outside it. Any app that opens its own connection, from a chat client to a video player, never touches the proxy. This scope difference is why Apple carefully avoids the word VPN in its own documentation.
You can see the coverage boundary yourself. Open a page in Safari, then open the same page in a third-party browser like Chrome for iOS. The two behave differently under Private Relay because the second one does not route through the proxy at all. That single test teaches more about the feature than any settings screen.
iCloud Private Relay vs VPN: It Is Not a VPN
iCloud Private Relay is not a VPN, and treating it like one produces a false sense of protection. A VPN opens a system-wide encrypted tunnel that carries every packet to an endpoint you choose. Private Relay proxies Safari traffic through Apple's infrastructure, offers no exit location choice, and does nothing for non-Safari apps (Wikipedia). If a tool's job is to protect apps you never named, this is not that tool.
| Capability | iCloud Private Relay | VPN |
|---|---|---|
| Traffic covered | Safari and WebKit apps only | All device traffic |
| Exit location | Automatic, Apple/Cloudflare/Fastly | You choose the country |
| DNS handling | ODoH for Safari lookups | Tunnel resolver, if configured |
| Non-browser apps | Bypassed | Tunneled |
| Cost | Included with iCloud+ | Separate subscription |
| Leak surface | Browser-level vectors | OS-level DNS and WebRTC |
The gaps to remember
Three gaps separate Private Relay from a real VPN. First, no exit control: you cannot pick a country, and Apple does not offer the service in 11 countries at all (Wikipedia). Second, no app coverage: a DNS lookup made by a non-Safari app goes straight to your ISP's resolver, which is exactly how the classic DNS leak happens. Third, no kill switch: if the relay drops, Safari falls back to a direct connection without warning you.
That last gap deserves emphasis. A VPN with a kill switch refuses to send traffic outside the tunnel. Private Relay has no equivalent behavior, so a momentary relay failure silently downgrades you to a plain connection. Your ISP, your router, and any network observer suddenly see everything Safari sends. This is the most common way people believe they are protected and are not.
DNS behavior compared
A VPN also changes your DNS path. With the tunnel active, your resolver queries should follow the tunnel to the provider's DNS or to one you configure, rather than leaking to your ISP. Private Relay achieves something similar for Safari lookups via ODoH, but only for Safari lookups. The asymmetry is where every misunderstanding starts.
When it is enough
For everyday browsing, Private Relay is a solid defense against IP-based tracking and ISP-side profiling. Sites cannot fingerprint you by address when you share an egress IP with thousands of subscribers. For research, journalism, or sensitive logins, it is not enough, because the browser-level leaks below can surface your identity at exactly the moments that matter most.
The honest decision rule: use Private Relay for convenience privacy, add a VPN when your threat model includes persistent tracking, and test both. For most people, the two together, validated against the DNS leak test guide workflow, is the strongest practical setup available.
The August 2026 WebKit Leaks: What Was Exposed?
On August 4, 2026, Mysk disclosed that three WebKit features can hand your real IP address to websites even while iCloud Private Relay is active (Mysk disclosure). AppleInsider's August 5 report confirmed the findings and added a telling detail: Onion Browser with Lockdown Mode was the only configuration in testing that avoided all three vectors (AppleInsider). The researchers also noted that VPN users were unaffected by these particular vectors.
How to test for these leaks
Detecting these vectors takes a different test than the network-level one. Run a DNS leak test first, because it is fast and catches the classic class. Then open a site that exercises the browser APIs, or use a dedicated browser-level probe. If the probe reports your real IP while the relay is on, the bypass is live. Document the result and re-run after every OS update.
Vector one: dns-prefetch
Browsers use dns-prefetch to resolve a page's linked domains before you interact with them, shaving latency off navigation (MDN's dns-prefetch reference). Those speculative lookups can skip the Private Relay proxy and reach your real DNS resolver. Each skipped lookup is a small identity beacon, invisible during normal browsing but perfectly legible to the network that serves you.
Vector two: WebAuthn
Web authentication flows sometimes bypass the proxy to reach the relying party directly. Mysk found that during WebAuthn, Safari can reveal your real IP to the site even with the relay on. Authentication is precisely when sites are most likely to log and link your identity, which makes this the most personally damaging of the three vectors. If you lean on Private Relay specifically during sign-ins, this vector targets you.
Vector three: WebTransport
WebTransport is an HTTP/3-based API for low-latency, bidirectional communication that reached Baseline in March 2026 (MDN). In the current WebKit implementation it is also a proxy bypass. Any site that opens a WebTransport connection can learn your real address, and adoption is climbing now that the API works across major browsers without flags.
Why proxies fail and tunnels hold
The distinction between a proxy and a tunnel is the whole story. Private Relay lives inside the browser's networking stack, so browser-level features can route around it. A VPN tunnel sits below the browser at the system network layer, so those same features have no direct path to the internet. That is why Mysk's disclosure named Private Relay and not VPNs.
The mirror image is also true. VPNs leak through their own channels, most famously DNS. Google's issue tracker confirmed Android can leak DNS outside the VPN tunnel, and Mullvad documented the same behavior with CVE-2024-34446, advising users to re-test after every OS update (Google Issue Tracker, Mullvad). The lesson is symmetrical: every privacy tool has a leak surface, and the only defense is testing.
The practical takeaway is boring and correct: test what you run. ToolSura's DNS leak test guide covers network-level checks, and a WebRTC leak test closes the other classic hole. If Private Relay is in your stack, add browser-level checks on top, because the two leak classes barely overlap.
How to Enable or Disable iCloud Private Relay
Enabling or disabling the relay takes about thirty seconds, once you know which menu hides it. On iPhone or iPad, open Settings, tap your name, then iCloud, then Private Relay. On a Mac, the toggle lives in System Settings under Apple ID, then iCloud, then Private Relay (Wikipedia). The relay activates only for Safari, so nothing else in your app library changes behavior.
Turn it on
- Open Settings on iPhone or iPad, or System Settings on a Mac.
- Tap your name, then iCloud, then Private Relay.
- Flip the switch on. Safari starts using the relay immediately.
- If the toggle is missing, your region is among the 11 countries where Apple does not offer the service (Wikipedia).
- Re-test within the hour. DNS lookups should route through Oblivious DoH instead of your ISP's resolver.
Turn it off per site
You do not need to disable the whole feature for one site. In Safari, tap the aA button in the address bar and choose Turn Off for This Website. The relay stays active everywhere else. Use this when a site blocks relay traffic or when you deliberately want a login to see your real IP, which some banking and streaming services require.
Turn it off entirely
Disabling the relay globally is the same switch, flipped off. Safari falls back to your normal connection, which means your ISP sees your DNS queries in plaintext unless you run a separate DNS over HTTPS setup. Re-test after every change. Each toggle resets the leak surface, and the August 2026 findings mean browser-level vectors deserve the same attention as DNS.
What the toggle does not change
One more expectation to set: flipping the toggle does not change your Mac's or iPhone's other traffic. App Store downloads, Mail sync, and iMessage keep their existing paths. The relay is scoped to Safari by design. That is why enabling it feels invisible and why its privacy claims are so narrow. Scope is the feature's strength and its ceiling.
Related Tools & Further Reading
Private Relay answers one question well: stopping websites from fingerprinting you by IP. It does not answer the harder question, which is how leak-proof the whole setup is. Start with the full DNS leak testing guide to map every vector, then work through the sibling guides for the two holes that bite most often.
- WebRTC leak test: why your VPN shows your real IP covers the STUN-based hole that survives even correctly configured tunnels.
- What is DNS over HTTPS explains the protocol that keeps resolver queries encrypted end to end.
- The DNS leak test guide is the hub that ties these vectors into one repeatable checklist.
