How iCloud Private Relay changes what servers see
Apple’s iCloud Private Relay, available with iOS 15, iPadOS 15, and macOS Monterey on devices with an iCloud+ subscription, routes Safari traffic through two separate proxy hops. The goal is to ensure that no single party handling the connection can see both who the user is and which sites they are visiting.
Without Private Relay, connection metadata is visible as shown here:
Cloudflare’s infrastructure and the second relay role
Cloudflare operates the second relay in the Private Relay system. The company’s global network is one of the largest and fastest available, and it was built using the same protocols that Private Relay depends on: TLS 1.3, QUIC, and MASQUE. Cloudflare’s implementation relies on its existing network, 1.1.1.1, Cloudflare Workers, and quiche—its open-source QUIC and MASQUE protocol library, which now includes proxy support.What website operators need to know
For most sites, Private Relay traffic should behave like any other traffic. But there are a few areas that deserve attention.Geolocation and the “local pizza test”
Private Relay is designed to preserve rough geographic accuracy while preventing tracking and fingerprinting. That matters for users who expect locally relevant search results or need to access region-restricted content like live sports broadcasts. The mechanism works as follows: - Apple’s relays geolocate the user’s IP address and translate it into a geohash—a compact representation of latitude and longitude. The system includes anti-spoofing protections and uses reduced precision to protect privacy. User IP addresses are not forwarded. - Cloudflare maintains a pool of egress IP addresses, registered with geolocation database providers, that correspond to specific cities. When a user connects with a geohash, Cloudflare selects the closest matching IP address. - Destination servers see an IP address that reflects the user’s general region without revealing their specific identity. By default, Private Relay supports city-level geolocation in most parts of the world. Users can choose coarser location granularity—country and timezone—in their settings. If your site relies on IP-based geolocation, keep your geolocation database up to date. Apple and Cloudflare work with all major IP-to-geolocation providers to keep mappings accurate, but the mappings can change. Using the latest database version ensures correct results. Greater precision is possible with IPv6. Private Relay egress nodes prefer IPv6 whenever AAAA records exist, and IPv6 egress IPs are geolocated more precisely than IPv4 counterparts. That means you can serve more relevant content without compromising user privacy. For Cloudflare customers proxying their sites, no action is needed. Cloudflare’s geolocation feeds already include the necessary information for Private Relay users.Performance impact
Adding network hops can sometimes improve performance rather than degrade it, provided those hops are well-connected and optimized. The networks behind Private Relay are aggressively tuned for speed. In some cases, clients using Private Relay see measurably lower page load times than those connecting directly—meaning increased privacy does not come with a performance penalty.Fraud and bot management systems
Private Relay concentrates many users behind a limited set of IP addresses, similar to enterprise web gateways or carrier-grade NAT. Systems that rely on IP as an identity signal will need to accommodate that. Apple’s documentation notes that Private Relay only accepts connections from valid Apple devices and accounts in good standing. That means connections through Private Relay have already been validated at the device and account level. Site operators may want to consider allowlisting Private Relay egress IPs, which are published in CSV form athttps://mask-api.icloud.com/egress-ip-ranges.csv.
For managing shared-address traffic, consider building rules around user-level identifiers such as cookies and geography. Cloudflare customers can use rate limiting and bot management features designed for shared IPs. Cloudflare automatically detects multi-user IP addresses and adjusts its machine learning and security heuristics, and its WAF includes rules for managing traffic from shared IPs.
Traffic flows and billing
IP addresses used by Private Relay are specific to the service. However, server operators may notice large amounts of traffic arriving from Cloudflare’s network, AS13335. That traffic includes Private Relay, enterprise web gateway products, and WARP, Cloudflare’s consumer VPN. For Cloudflare customers, traffic that traverses Cloudflare’s network to reach a proxied property is included in usage and billing metrics, just like traffic from any other Internet user.Notes for corporate and school networks
Most enterprise networks do not need to take action to support Private Relay. The end-to-end encrypted nature of the system may create compliance challenges, and local networks can block Private Relay for connected devices if needed. Apple’s “Prepare Your Network or Web Server for iCloud Private Relay” document covers network operator scenarios in detail. For Cloudflare One customers, name resolution blocks needed to disable Private Relay can be enforced through the DNS filtering dashboard. Cloudflare One includes Gateway, which is built on the same network and codebase that powers iCloud Private Relay.How iCloud Private Relay preserves privacy
iCloud Private Relay is designed to give iCloud+ subscribers a more private browsing experience. Unlike a traditional VPN, which routes all traffic through a single encrypted tunnel, Private Relay separates the user’s IP address from their browsing activity using two separate proxy hops: one operated by Apple and one operated by a trusted third-party content provider, such as Cloudflare.
The architecture works like this: when a user with Private Relay enabled makes a request in Safari, the traffic is first sent through Apple’s ingress proxy, which can see the user’s IP address but not the destination website. From there, the request is forwarded to the egress proxy operated by the content provider, which resolves the domain name and connects to the destination — but never sees the user’s real IP address. This split means that neither Apple nor the content provider can easily correlate a specific user with a specific website.
For Cloudflare customers operating behind Private Relay traffic, the key detail is that the egress proxy uses dedicated IP addresses. This is deliberate. Because the egress IP is shared across many users, it cannot be used to identify an individual, but it is stable and consistent for a given region. That means your infrastructure and security tooling—such as rate limiting, bot detection, geo-location, or allowlisting—will continue to work as expected, provided you evaluate these requests based on the egress IP rather than the user’s real IP.
What Cloudflare customers need to check and configure
There are a few practical takeaways if you operate a Cloudflare-proxied origin or service and you want to handle Private Relay traffic correctly:
- Use Cloudflare’s managed challenge or a firewall rule to handle the traffic. Cloudflare can treat Private Relay requests just like any other browser traffic. If you currently block by IP reputation, ensure your rules do not inadvertently block the known Cloudflare egress IP ranges.
- Be careful with geo-targeting. Since the egress proxy is region-based, a request may appear to originate from a nearby Cloudflare data center rather than the user’s actual location. For content that is legally or geographically restricted, do not rely solely on the IP address seen by Cloudflare. Instead, use a privacy-preserving alternative, such as
CF-IPCountryheaders or your own application-level checks. - Watch for header manipulation. Private Relay sends certain HTTP headers to signal its use, including
X-Forwarded-Forand a specificuser-agenttoken. Do not treat these as spoofable signals for authentication or fraud checks. Validation should happen over TLS and at the application layer, not by trusting client-supplied headers. - Evaluate impact on bot management and analytics. The first-party IP address is not visible to the destination origin when Private Relay is active. If your analytics or security dashboards rely on IP to segment visitors, you will see them aggregated under the egress proxy’s IP instead. Leverage Cloudflare’s Bot Management or other behavioral signals if you need finer-grained visibility.
Adopting Private Relay support with Cloudflare
Cloudflare does not require any special configuration to let Private Relay traffic through—but you should review existing firewall rules, WAF custom rules, and rate limiter configurations that assume a one-to-one mapping between an IP and a user. Since a large number of users can share the same egress IP, aggressive per-IP rate limits may affect legitimate Private Relay users who happen to fall within the same proxy range.
If your use case demands more certainty about the user’s identity or location, plan for a user-facing authentication step (for example, a managed challenge) rather than relying on the IP layer. This ensures that legitimate Safari users on iCloud+ can reach your site without a degraded experience, while you retain the ability to enforce your own policies.
In short, Private Relay is not a fundamental break from how Cloudflare handles traffic, but it does require updating your assumptions about what an IP address means. With the right configurations, you can offer a fast, private, and protected experience to iCloud+ users without compromising your security posture.
