iCloud Private Relay, browser relays and corporate egress: when a proxy address belongs to a legitimate user
A proxy signal fires on a customer who is doing nothing unusual, or on an employee sitting in an office. Neither is a false positive exactly: the traffic really did arrive through a relay. It is just that a whole class of relays carries ordinary people by default, switched on by a phone setting or by a corporate security deployment nobody told you about. Here is what those operators publish about their own egress space, what the published files can and cannot settle, and how to treat the signal without either ignoring it or acting on it alone.
The exception class
Separating VPN, proxy and Tor space is the parent problem; this is the corner of it that catches good customers. Two populations sit here. The first is platform relays: privacy features built into an operating system or a browser, on for anyone who ticked a box, carrying browsing that is otherwise entirely ordinary. The second is corporate egress: employees behind a secure web gateway, where the traffic the deployment steers leaves through the vendor's cloud rather than the office's own address. In both cases the person had no intent to conceal anything and often does not know it is happening. The signal is still real, which is the trap: the traffic did arrive through third-party infrastructure, so a detector that says proxy is not wrong, it is just answering a different question from the one your fraud rule is asking.
What Apple publishes
iCloud Private Relay is the best documented example, and the only platform relay here that publishes its egress space at all; neither Apple nor Cloudflare published a figure for its share of traffic on the pages we checked on 23 August 2026, so treat any circulating percentage as unsourced. Apple lists it as an iCloud+ subscription feature requiring iOS 15, iPadOS 15, macOS 12.0.1 or visionOS 1 or later, so it dates from the 2021 iOS 15 generation, with visionOS added later. Its scope is narrower than people assume: Apple states it protects users' web browsing in Safari, DNS resolution queries and insecure HTTP app traffic, so it is not a device-wide tunnel and ordinary HTTPS traffic from other apps takes the normal path. The design is two hops through relays run by different entities, which Apple's security documentation describes as an ingress proxy managed by Apple and an egress proxy managed by a content provider, without naming any partner; the partners have named themselves, with Cloudflare writing that it works with Apple to operate portions of the infrastructure and Akamai describing the egress proxy service it built. That split matters for a defender, because the address you see belongs to the egress operator: sampling Apple's published file on 23 August 2026 and resolving the prefixes put them in space registered to Akamai, Cloudflare and Fastly rather than to Apple. Apple publishes the egress addresses as a plain CSV, which on that date carried 287,807 rows in exactly the five-field layout RFC 8805 defines, prefix, country, region, city and postal code, with the postal code left empty in every row, though the Apple pages we read that day do not cite the RFC. Two numbers from that fetch are worth carrying with their date: the file was overwhelmingly IPv6, about 245,858 IPv6 rows against 41,949 IPv4 ones, so a list built from the IPv4 side covers a small minority of the rows in the file, which is a statement about the file and not about how much traffic arrives over either protocol. And Apple's own advice to server operators is the sanest sentence in this whole area: it tells them to consider treating these addresses like larger carrier-grade NAT or enterprise IP addresses, since many Private Relay users may be assigned to a single relay IP address.
Corporate egress and browser relays
The corporate case has the same shape with worse documentation. Secure web gateway and SASE vendors route the customer traffic they are configured to steer through their own egress ranges, so coverage is a deployment choice rather than a given, and publication practice is a per-vendor fact to check and date. Zscaler publishes its egress ranges openly along with a geofeed CSV, which when we read it on 23 August 2026 carried a last-modified date of three days earlier, and advertises it from its registry objects in the way RFC 9632 describes, which covers both a dedicated attribute and the comment form some registries use. Netskope, on the pages we read on 23 August 2026, publishes a small set of ranges openly and states that its consolidated list is accessible only to authorised customer contacts via login. Registry data will not rescue you here either, since a published corporate egress prefix can be a reassignment held by an upstream carrier rather than a block registered to the security vendor at all. Browser and platform relays are a moving roster and should always be dated. Chrome's IP Protection is documented as a two-hop design where the first proxy sees the user's address and the second, run by an external CDN, sees only the destination domain, assigning addresses that represent the user's coarse location including country, with a staged regional rollout. It runs in Incognito mode and only for third-party requests to domains on Google's published Masked Domain List, never in a first-party context, so it shapes what third-party embeds see rather than what your own login endpoint sees and no announced general availability on the page as last updated 27 October 2025 and read on 23 August 2026. Edge's secure network, on the page we read on 23 August 2026, offers a monthly data allowance to signed-in users and describes replacing the user's geolocation with a similar regional address. Others have gone the other way: searching support.google.com, blog.google and one.google.com on 23 August 2026 we found no Google-published page confirming the widely reported 2024 shutdown of its consumer VPN, and the plans page listed no VPN benefit on any tier, which is the honest way to state a disappearance. Treat that whole paragraph as perishable.
What the published lists cannot settle
If you are going to consume these files, four limits belong in the same commit as the parser. Rows are not addresses and not people: a single IPv6 row can cover an enormous range, and none of these counts says anything about traffic volume. Presence is a statement about published egress space at a moment, and absence proves nothing, since these files change and Apple's egress list, when we fetched it on 23 August 2026, was served without a last-modified header at all. Every location value in a geofeed is the operator's own declaration, which is the entire premise of RFC 8805, so a city in a row is a claim about where the egress sits, not evidence of where a person is beyond the coarse country or region these relays are designed to preserve, and never a city-level or per-person fix. And the trust model is simply that the publisher said so: RFC 9632, which since August 2024 defines how geofeed data is found from registry records, says a consumer should fetch and process the data themselves rather than importing a third party's processed set, and treats cryptographic authentication of that data as optional. One more caution against over-reading registry metadata: a block whose netname advertises one product can appear in another product's published egress file, so a name in a record is not a product boundary.
Triaging the signal
The practical rule is that a relay address changes the weight of the evidence rather than the verdict. Because the address is shared, nothing about it is per-user: it cannot corroborate a location more precisely than the coarse region the relay is designed to preserve, it cannot be pinned to one customer, and a velocity rule keyed to the address will fire on strangers sitting behind the same egress. Sizing matters as much as weight. These operators publish prefixes rather than addresses, so a rule written at prefix or ASN width reaches every uninvolved person behind it, and one corporate egress address can front an entire workforce, which turns an address-level ban into a company-level outage. If you decide to act on a range anyway, size the block to the evidence you actually have. That cuts both ways, which is the part defenders forget: a relay address is not clean either, because everyone behind it shares it, so treating it as trusted is the mirror-image mistake. So use it as context and move the decision to signals that belong to the account rather than the network, and where the population is knowable, handle it by policy: allowlist the egress addresses your own deployment actually leaves from, and where those turn out to be a vendor's shared cloud ranges carrying other tenants, pair the address with a device or account signal rather than trusting it on its own, so employee traffic stops tripping consumer rules without handing the same pass to every other customer of that vendor, and decide deliberately what a platform relay should mean in your risk model rather than inheriting a vendor default. If your own network genuinely must not carry a relay, Apple documents a DNS-based method for a network operator to signal that, with a warning that timing out or silently dropping the traffic instead can lead to delays on client devices; that is a decision about your own network and about every device on it, guests and personal phones included, not about a customer. Finally, keep the categories separate when you write the rule: a platform relay, a corporate gateway, a commercial VPN and a residential proxy service are four different populations with four different risk profiles, and the same word on a dashboard covers all of them.
When a proxy signal fires, look the address up on the front page before you act on it: who holds the space and what the registry says, which network announces it, and any confirmed tags, which usually sit on the announcing network or a covering block rather than on the address itself. Most networks carry none, no tag marks a platform relay or a corporate gateway as such, and absence of a tag is not a finding of innocence. Even so, a shared egress address run by a large infrastructure operator reads very differently from a residential proxy exit, and the difference is in the record rather than in the word proxy.