Budget about 45 minutes on an edge you already control. By the end, iCloud Private Relay traffic will be labelled in your logs, CDN geolocation for those requests will come from Apple's published egress IP feed instead of a commercial geo-IP database, and your per-IP rate limits will stop punishing the thousands of legitimate users sharing a single egress address. Private Relay decrypts nothing and changes no cache key. It changes exactly one input: the client IP your edge sees. Everything you quietly keyed on that IP is what actually breaks.
iCloud Private Relay, Apple's two-hop proxy shipped with iOS 15 in 2021, routes Safari browsing, DNS queries, and unencrypted app traffic through an Apple-operated ingress proxy and a partner-operated egress proxy, so your edge sees only the egress IP address. Apple publishes those egress ranges with country, region, and city assignments in a public CSV feed that is updated continuously; as of 2026 that feed, not a commercial geo-IP database, is the authoritative source for geolocating relayed clients.
The IP masking is deliberate but not total: by default the relay preserves the user's general location, so a client in Lyon egresses from an address Apple has tagged as Lyon, France. Users who switch to the broader setting get country-and-timezone accuracy only.
| Traffic type | Relayed? | What your edge sees |
|---|---|---|
| Safari page and asset requests on iOS, iPadOS, macOS | Yes | Egress proxy IP, no forwarded-for header from Apple |
| Native app traffic over HTTPS | No | Real client IP, normal geo-IP lookup applies |
| Plain HTTP app traffic | Yes | Egress proxy IP |
| DNS resolution for relayed requests | Yes | Resolution happens at the relay, so client subnet hints never reach your authoritative DNS |
The practical consequence: any product logic that assumes one IP equals one user, or that a geo-IP lookup equals the user's real location, is now wrong for a measurable slice of your Apple traffic.
Fetch Apple's egress IP range feed in your build pipeline and transform it into whatever prefix map your edge consumes. The feed carries an IP prefix, an ISO country code, a region code, a city name, and an internal identifier per row. Emit a boolean field named relay_client plus three fields for the feed's country, region, and city.
Why first: every later decision is a policy applied to this label. Ship the label alone, look at a day of logs, then change behaviour.
In your geolocation resolution order, put the relay feed above the commercial database for any request where relay_client is true. Commercial databases frequently map an egress prefix to the registrant's headquarters country, which is how a subscriber in Madrid ends up served the United States catalogue. Treat relay-derived city as low confidence and relay-derived country as high confidence.
Do the override at the edge rather than at origin: it keeps origin application logic untouched and works for cached responses too. Platforms differ in how much of this they expose, so check whether your provider supports custom prefix lists in the rules engine; flexible edge configuration for custom CDN geolocation rules is the feature class to look for during a vendor review.
Egress addresses aggregate large numbers of users, closer in behaviour to carrier-grade NAT than to a residential line. Raise per-IP thresholds by one to two orders of magnitude for prefixes in the feed, and move the real limit to a session token, an authenticated user ID, or a signed cookie. Keep a very high absolute per-IP ceiling as an origin-protection backstop, not as an abuse control.
Apply the same reasoning to bot scoring, geo-velocity checks, and any session that is pinned to a client IP. Pinning a session to an egress IP guarantees random logouts.
IP-based deduplication collapses many relayed users into one visitor, then splits one user across several egress addresses when their assignment rotates. Relay analytics therefore drift in both directions at once. Switch unique counting to a first-party identifier, exclude relay prefixes from IP-based dedup, and add a relay dimension to your geo dashboards so a step change in country mix is explainable rather than alarming.
Because name resolution happens at the relay, DNS-based steering and client-subnet hints reflect the egress proxy, not the user. Anycast still lands the connection on a nearby edge node, but "nearby" is now relative to the relay. Split your latency dashboards by relay_client and compare p50 and p95 separately; aggregate numbers will hide a systematically different path for that segment.
Put the geolocation override and the rate-limit exemption behind one flag each. Rolling back means flipping precedence to the geo-IP database and restoring the previous limit policy; no cache purge is needed because the label never enters the cache key. Leave the log fields in place. They are inert and you will want the history when you retry.
| Symptom | Cause | Fix |
|---|---|---|
| European users served the wrong catalogue or currency | Geo-IP database maps the egress prefix to a registrant country | Feed precedence for relay prefixes (Step 2) |
| Burst of 429s from Safari users in one metro | Shared egress IP exhausts a per-IP token bucket | Key limits on session or user ID, raise the per-IP ceiling |
| Random logouts reported only by Apple users | Session bound to client IP, egress assignment rotated | Drop IP binding, or exempt relay prefixes from it |
| Fraud engine flags impossible travel | Geo-velocity computed across two different egress locations | Suppress the rule when relay_client is true |
| Overnight geolocation regression across all relayed traffic | Feed fetch failed and the artifact published empty | Fail closed on the last good copy for up to 7 days, alert on row-count deltas above 20 percent |
Nearly every failure here traces back to one assumption, that a client IP identifies a single user in a single place, so fixing the assumption fixes the class rather than the incident.
Refresh the feed every 6 to 24 hours. More frequent polling buys little; going stale for a week produces silent misrouting for newly added prefixes.
The trade-off you are accepting is trust. You are replacing a database you license with a location Apple asserts. In exchange you get a signal derived from the device's real position rather than from registry data of unknown age, which for content targeting is usually the better input. For anything with legal exposure such as rights windows or tax jurisdiction, require a second signal instead of relying on relay-derived city.
The second trade-off is enforcement. Loosening per-IP controls on relay prefixes genuinely reduces your ability to shut down an abuser by address. Blocking the egress ranges outright is the alternative, and it blocks paying customers with no error message they can act on. Pick the first, and invest the saved effort in identity-based controls.
No. Private Relay preserves the user's general location by default, and Apple publishes the egress IP ranges with country, region, and city assignments so servers can geolocate correctly. Users who select the broader privacy setting are located at country and timezone level only. City-level precision should be treated as approximate for relayed clients.
Native app traffic sent over HTTPS is not relayed and reaches your edge with the real client IP. Private Relay covers Safari browsing, DNS queries, and app traffic sent over plain HTTP. That is why relayed share is much higher on web properties than on API endpoints serving a first-party mobile app.
Match the client IP against Apple's published egress IP range feed and set a log field from the result. There is no forwarded-for header and no distinguishing request header, so prefix matching is the only reliable method. Refresh the feed at least daily, because prefixes are added and retired frequently.
An origin can block the published egress ranges, but this blocks legitimate customers with no actionable error for them. Network operators have a supported path: preventing resolution of Apple's mask hostnames causes the device to show a clear notice that Private Relay is unavailable on that network. Blocking at the origin is not recommended for consumer-facing services.
Do Step 1 alone and stop. Add the relay_client field, let it run for seven days, then pull three numbers: relayed share of total requests, disagreement rate between the feed country and your geo-IP database, and the 429 rate on relay prefixes versus everything else. Those three numbers tell you whether the remaining steps are worth an afternoon or a sprint. If your disagreement rate is above a few percent, your geo-targeting has been wrong for Apple users for a while, and nobody filed a ticket about it.