Apple's ‘Private Relay’ Is Exposing Users’ Real IP Addresses

A peer-reviewed disclosure reveals that Apple's iCloud Private Relay-a privacy feature used by millions-can leak your real IP address due to a series of overlooked protocol interactions and fallback bugs. Here's the technical deep-dive on what's broken and how to defend your stack.

As engineers, we often treat platform-level privacy features as black boxes that "just work. " When Apple launched iCloud Private Relay, it promised to separate user identity and browsing activity using a dual-hop proxy architecture-ingress proxies handled by Apple and egress proxies run by third-party CDN partners. The theory is elegant: no single party sees both who you're and where you're going. But a new wave of research-confirmed by 404 Media's verification-shows that the system has cracks wide enough to expose real client IP addresses. For anyone shipping software that relies on Private Relay's privacy guarantees, this is a fire drill, not a marketing footnote.

I've spent the last week tearing down the reported issues in our own staging environment, using tools like mitmproxy, Wireshark. And custom Swift packet-trace injections. What we found wasn't a single smoking gun but a constellation of protocol-level and implementation bugs-DNS flags that bypass the relay, WebRTC ICE candidates that phone home with the real address, QUIC connection migration quirks. And a series of silent fallback paths that drop protection without user notification. Worse still, many of these leaks are invisible to typical HTTPS inspection because they happen at layers below the app's HTTP stack, deep inside the OS network extension framework.

In this article, I'll walk through the architecture that was supposed to prevent this, catalog each identified leakage vector with concrete packet-level examples and share the methodology we used to audit our own iOS and macOS applications. The goal isn't to shame Apple but to equip developers with the technical understanding and tooling necessary to protect users when platform abstractions fail.

Private Relay's Architecture: A Quick Primer on Dual-Hop Proxies and Oblivious HTTP

Before we can dissect the leaks, we need a shared mental model of how Private Relay is architected. Apple's official Private Relay documentation describes a system that routes traffic through two separate proxy servers: an ingress proxy managed by Apple and an egress proxy operated by a third-party partner (like Cloudflare or Fastly). The ingress proxy knows the client's real IP but can't see the destination; the egress proxy sees the destination but receives source IP information that points back to the ingress, not the real client. This separation is enforced by encrypting the request URL and headers with a key that only the egress proxy can decrypt, wrapping the whole thing in a transport that uses Oblivious HTTP (OHTTP, draft-ietf-ohai-ohttp-10), a protocol designed precisely for this "mutual distrust" forwarding model.

From a network engineer's perspective, the design is similar to a two-layer onion: each hop adds a layer of encryption that only the next hop can peel. The client constructs an inner HTTP request, encrypts it with the egress proxy's public key (which it fetches via a key configuration endpoint), then wraps that in a binary HTTP "outer" request to the ingress proxy. The ingress unwraps the outer layer, forwards the encrypted inner blob to the egress. And the egress decrypts and sends the actual request to the destination. In theory, neither proxy can correlate client and target. In practice, life is messier because the internet is a tarpit of legacy protocols and edge cases.

What's often overlooked is that Private Relay isn't a VPN in the traditional sense-it doesn't create a virtual interface or capture all traffic. Instead, it's implemented as a network extension that intercepts specific traffic flows, primarily Safari browsing and apps that opt in via the NSURLSession API. This selective interception is the root of many leakage vectors: anything that doesn't pass through the NSURLSession proxies-like raw sockets, WebRTC. Or certain DNS lookups-may escape the relay entirely.

The Reported Issues: What Researchers Discovered About IP Leakage

The vulnerability disclosure-first reported by researchers and independently verified by 404 Media-outline a handful of specific scenarios where Private Relay fails to mask the real IP. The leaks aren't esoteric; they're reproducible in everyday browsing and app usage. One set of problems involves DNS: if a device falls back to an unencrypted DNS server (say, a manually configured resolver or a hotel Wi-Fi captive portal that hijacks DNS), those queries bypass the relay and expose the IP to both the DNS server and the eventual destination via the resolved connection. Another class centers on WebRTC. Where ICE candidates contain the device's local and public IP addresses even after the relay is supposed to be active.

During our verification, we added a third vector that got less press but is equally dangerous: QUIC connection migration. When a QUIC connection migrates from Wi-Fi to cellular, the server may learn the client's new IP address-and if Private Relay isn't re-established seamlessly, that IP can be the real one. We triggered this repeatedly by walking between office APs while running a Python script that forced QUIC transport through alt-svc headers. These aren't edge cases; they're normal mobile usage patterns.

What makes these leaks particularly insidious is that they're invisible to the user. The Safari "Private Relay" badge in the address bar remains visible even when a component of the connection has leaked the real IP. The trusted UI gives a false sense of security, which is arguably worse than having no protection at all. As engineers, we know that trust indicators are only as good as the weakest link in the chain-and the chain has several broken links.

Dissecting the DNS Leak: How Unencrypted Queries Slip Through the Relay

Private Relay's design includes an obligation to encrypt DNS traffic using DNS-over-HTTPS (DoH, RFC 8484) or DNS-over-TLS, routed through the proxy infrastructure. But iOS allows manual DNS configurations, and many corporate networks, hotels. And public Wi‑Fi services force a local resolver. When that happens, the OS can fall back to a traditional UDP-based DNS lookup that skips the relay entirely. In a controlled test, we connected an iPhone to a Wi‑Fi network with dnsmasq configured to block DoH and force port 53. Within seconds, the device started emitting AAAA and A queries that contained the real source IP in the IP header.

The leakage isn't just metadata; it's a full wire-level exposure. The resolver sees the client IP, and because the subsequent TCP/TLS connection often reuses the same IP, the destination server can correlate the query with the browsing session. We captured with tcpdump -i en0 udp port 53 on the gateway while navigating to a canary domain in Safari. The trace clearly showed UDP datagrams originating from the iPhone's real 192. And 168x. x address, completely outside the Private Relay tunnel.

Apple's mitigation for this is supposed to be a system-level DNS proxy that intercepts all name resolution and routes it through the encrypted tunnel. But the implementation appears to have gaps when apps use lower-level POSIX functions like getaddrinfo() that don't honor the system proxy settings. The takeaway for developers: never assume DNS privacy on iOS unless you explicitly bind your NWConnection or URLSession to require a secure DNS resolver. Even then, the OS fallback logic is opaque and may betray you.

WebRTC and STUN: The Perennial Culprit in IP Address Exposure

WebRTC is indispensable for real-time communication. But its ICE (Interactive Connectivity Establishment) process is infamous for leaking local and public IP addresses. When an iOS app or website uses the RTCPeerConnection API, the browser or app gathers candidates by contacting STUN/TURN servers. Which learn the client's real IP. Under normal circumstances, WebRTC traffic isn't automatically routed through Private Relay because it uses raw UDP sockets rather than an NSURLSession channel.

In our tests, we loaded a WebRTC-based video conferencing app with Private Relay active. The STUN binding requests sent to a public STUN server (Google's stun, and lgoogle com:19302) contained the device's public IPv4 address in the XOR-MAPPED-ADDRESS attribute. This happened even though Safari's Privacy Report claimed the connection was relayed. The fundamental conflict: Private Relay is designed for HTTP requests. But WebRTC is a multi-protocol framework that operates below that abstraction.

The fix from Apple's side would require deep integration between the network extension and the WebRTC stack-exactly the kind of cross-layer plumbing that's notoriously hard to get right. Until that ships, any iOS application that uses WebRTC should assume that the user's real IP is exposed. And adjust its privacy UX accordingly. For developers, always set iceTransport