How iCloud Private Relay Dual Proxy Works on iOS 15

Apple introduced iCloud Private Relay in iOS 15 as an advanced privacy feature designed to secure Safari browsing and unencrypted network activity. Built directly into the operating system, the service prevents websites, network operators, and even Apple from linking a user's identity to their browsing habits. It accomplishes this through an innovative dual-hop architecture that routes internet traffic through two separate, independent proxies, ensuring that no single entity holds both the user’s identity and their internet destination.

The Dual-Hop Proxy Architecture

Traditional Virtual Private Networks (VPNs) route traffic through a single intermediary. While this masks the user's IP address from websites, it requires the user to place complete trust in the VPN provider, which can see both who the user is and what sites they visit.

Private Relay eliminates this single point of trust by splitting network responsibilities between two distinct entities:

  1. The Ingress Proxy (Operated by Apple)
  2. The Egress Proxy (Operated by Third-Party Partners)

Traffic passing through this architecture is protected using standard cryptographic protocols, including TLS 1.3 and Oblivious DNS-over-HTTPS (ODoH), creating nested layers of encryption that only the intended hop can peel back.

Step 1: The Ingress Proxy (Apple)

When a user navigates to a website in Safari on iOS 15, the device encrypts the destination URL and DNS request so that only the second proxy can read it. The connection then establishes an encrypted tunnel to Apple’s Ingress Proxy.

  • What Apple sees: Apple sees the user's actual IP address and their device identity.
  • What Apple cannot see: Because the inner payload is encrypted for the second proxy, Apple cannot see the website the user wants to visit, the DNS query, or the data being transmitted.

Apple's server authenticates the user as an active iCloud+ subscriber, strips away the user's original IP address, and forwards the encrypted request to the second proxy.

Step 2: The Egress Proxy (Third-Party Partner)

To prevent Apple from controlling the entire routing pipeline, the second proxy is operated by major, independent content delivery networks (CDNs) and infrastructure providers, such as Cloudflare, Fastly, and Akamai.

  • What the partner sees: The egress proxy decrypts the destination request and sees the requested website domain or IP address.
  • What the partner cannot see: The egress proxy only sees the connection arriving from Apple's servers. It has no knowledge of the user's original IP address or identity.

The egress proxy assigns the user a temporary, generalized IP address that corresponds to their approximate geographic region (maintaining local search results and weather data without revealing exact coordinates). It then resolves the DNS request and establishes the connection with the destination server.

Returning the Response

When the target website sends data back, the process happens in reverse:

  1. The website responds to the egress proxy's temporary IP address.
  2. The egress proxy encrypts the data and forwards it to Apple’s ingress proxy.
  3. Apple forwards the encrypted data back to the user's iOS device.
  4. The device decrypts the payload locally.

Technical Scope in iOS 15

In iOS 15, Private Relay applies specifically to:

  • All browsing traffic within the Safari browser.
  • DNS resolution queries initiated across the system.
  • A small subset of insecure app traffic (such as unencrypted HTTP connections).

By separating authentication from routing, Private Relay ensures that Apple knows the user's identity but not their destination, while the proxy partner knows the destination but not the user's identity, effectively preventing end-to-end tracking.