The Lead

In June 2021 Apple announced iCloud Private Relay at WWDC. By the time the feature shipped publicly in iOS 15.2 that December, every paying iCloud+ subscriber on Apple's billion-plus active iPhone install base had a one-tap VPN-shaped privacy layer turned on by default in Safari. Cloudflare's WARP had been around since 2019 as the consumer-facing wing of 1.1.1.1, and as of Cloudflare's 2024 disclosures the service moves traffic for tens of millions of devices.

Together these two products represent something that did not meaningfully exist in 2019: mass-market, default-on, IP-obscuring privacy traffic from real paying consumers. Your IP intelligence stack will see the egress as datacenter or cloud-tagged. Your fraud rules will likely flag it. Your country-level rules will mostly still work, but your city-level rules will stop working. And the share of your inbound traffic that originates from these systems is going up, not down.

This is a guide to what each system actually does, how to detect them accurately (with neither false-blocking real customers nor letting actual VPN evasion through under their cover), and how to fold the signals into a 2026 fraud-prevention stack.

TL;DR

• Private Relay and WARP are not VPNs, but they egress from datacenter ranges and will be tagged that way by naive detection.
• Apple publishes the [Private Relay egress IP CSV](https://mask-api.icloud.com/egress-ip-ranges.csv) daily, so high-accuracy detection is a feed-ingestion problem, not a heuristic-detection problem.
• WARP is harder to disambiguate because Cloudflare's edge IPs serve both WARP and millions of regular CDN-fronted websites — IP alone can't tell you which.
• Treat both as distinct signal categories, not as VPN. Risk-score them modestly, don't block, and downgrade city-level geolocation rules for affected sessions.
• Imperva's 2024 [Bad Bot Report](https://www.imperva.com/resources/resource-library/reports/bad-bot-report/) put residential-proxy bot traffic at 21% of bad-bot volume; a Private Relay or WARP user looks superficially similar to that, which is why the detection has to be precise rather than heuristic.

What Private Relay Actually Does

The architecture matters because the privacy guarantee, and therefore the appropriate trust posture, follows from the architecture. Apple's Private Relay technical overview describes a two-hop relay system. The user's iPhone sends every Safari request through:

1. An ingress proxy operated by Apple, which sees the real client IP and the (encrypted) ODoH-style DNS query, but cannot read the URL or destination.
2. An egress proxy operated by a third party — currently Cloudflare, Akamai, or Fastly under contract — which sees the destination URL but only a coarse-grained client IP attributable to the user's country and approximate region.

The two operators do not share data. Apple cannot construct destination logs. The egress partner cannot identify users. The two-hop model collapses to a privacy guarantee similar in shape to Tor's onion routing, except with named, contractually-bound operators and no resistance to government subpoena targeting either link.

Crucially, only Safari and DNS go through the relay. Native iOS app traffic, push notifications, App Store traffic, and traffic from third-party browsers (Chrome, Firefox, Brave on iOS) bypass it entirely. The signal you receive is therefore "this user is browsing the web from Safari with iCloud+ enabled," not "this user is on a VPN."

The egress IP behaviour is what determines what your stack sees. The egress proxy assigns a coarse geographic IP based on the user's real client IP — Apple's stated commitment is preserving country-level accuracy plus, for large countries, "general region" accuracy (one of a country's broad timezones). A San Francisco user might egress through a Sacramento IP. A London user might egress through a Manchester IP. The egress IP is shared across many users in the same region, so the per-IP volume looks like a small CDN node, not like a residential ISP.

What WARP Actually Does

Cloudflare's WARP is structurally simpler and was never marketed as a privacy product. It's a WireGuard-based encrypted tunnel from the user's device to Cloudflare's edge, primarily intended to improve performance via Cloudflare's Argo routing and to provide modern TLS where ISPs do not. The privacy benefit (your ISP can no longer see what sites you visit) is real but secondary; the connection between user IP and destination is preserved on Cloudflare's side, and Cloudflare logs aggregated metadata for abuse-prevention purposes per their WARP privacy policy.

What your stack sees: every WARP user's traffic egresses from Cloudflare's public IP ranges. These are the same ranges that front Cloudflare's millions of customer websites — there is no distinct "WARP-only" range published. So an IP intelligence system looking only at the IP cannot reliably distinguish "user on WARP" from "request from a user who happens to be behind a Cloudflare-fronted origin." This ambiguity is intentional on Cloudflare's part and is the single biggest reason WARP detection is fundamentally a probabilistic problem rather than a deterministic one.

The good news: most fraud signals do not need to disambiguate. If you're using Cloudflare in front of your own site, you'll see the WARP user's IP via the `CF-Connecting-IP` header, which gives you the egress IP that Cloudflare assigned to the WARP session. That IP is still a Cloudflare-range IP, and your downstream rules apply against that IP. The fact that the user happens to be on WARP rather than direct-via-Cloudflare is invisible to you — and for most fraud decisions, irrelevant.

Why This Matters: The Detection Problem

Both systems break a foundational assumption of pre-2022 fraud rules: that residential IPs identify residential humans, and datacenter IPs identify automation. With Private Relay and WARP, datacenter-range IPs now legitimately serve hundreds of millions of paying consumers running Safari or the WARP mobile app from their kitchens.

The first-order failure mode is the obvious one: a fraud rule that blocks "datacenter IPs" rejects every Private Relay user. The shape of the incident is always the same: a site tightens a "block datacenter" rule, iOS Safari conversion sags, and nobody connects the two — because the blocked visitors are silent, and the rule change and the conversion dip are weeks apart in different dashboards. (This silent-failure dynamic is the whole subject of our false-positives deep dive.)

The second-order failure mode is subtler. Many fraud systems fold "is_datacenter" into a composite risk score that also weights geolocation distance, ASN, and connection history. A Private Relay user trips the datacenter flag and the city-level geolocation mismatch flag simultaneously, because Apple's egress IP is provisioned by region, not by city. The composite score climbs into the action band even though no individual signal is wrong about the underlying behaviour. The user gets a step-up challenge, fails it because they don't see why they're being challenged, and abandons.

The third-order failure mode is what the rest of this post is about: once you know to identify Private Relay and WARP traffic specifically, the right action is almost never "block." Both populations skew heavily towards real customers — privacy-conscious users on iOS, mobile-first users who installed the WARP app for performance reasons, plus a long tail of journalists, activists, and users in jurisdictions where ISP-level browsing surveillance is a real concern. Treating them as adversarial is a mis-calibration with measurable conversion cost.

Detecting Private Relay: It's a CSV

Apple solved the detection problem for you by publishing a daily-updated CSV of every Private Relay egress IP at `https://mask-api.icloud.com/egress-ip-ranges.csv`. The format is four columns:

ip-prefix,country-code,region-code,city-code
17.140.0.0/16,US,CA,SFO
17.142.0.0/16,US,NY,NYC

Ingest the CSV daily, normalise the prefixes into your IP intelligence database with an is_private_relay boolean, and any inbound IP can be matched in O(1) against an interval tree or a Postgres GiST index over CIDR ranges. The country and region codes are usable for downstream geolocation logic — you can preserve country-level matching while explicitly downgrading city-level matching for these sessions only.

A minimal Python ingestor:

import csv, ipaddress, requests

def fetch_private_relay_ranges():
    r = requests.get(
        "https://mask-api.icloud.com/egress-ip-ranges.csv",
        timeout=30,
    )
    r.raise_for_status()
    rows = csv.reader(r.text.splitlines())
    out = []
    for row in rows:
        if len(row) < 2:
            continue
        prefix, country = row[0], row[1]
        try:
            net = ipaddress.ip_network(prefix, strict=False)
            out.append({
                "cidr": str(net),
                "country": country,
                "region": row[2] if len(row) > 2 else None,
                "city": row[3] if len(row) > 3 else None,
            })
        except ValueError:
            continue
    return out

Run that on a daily Celery beat schedule, write the result to a private_relay_ranges table, and join against it from your check pipeline. The CSV is small (a few thousand rows) and the operation is cheap.

What is_private_relay = true tells you in 2026: almost-certainly a paying iCloud+ subscriber browsing the public web in Safari. Apple doesn't disclose iCloud+ subscriber counts at granularity, but the qualifying population is anyone paying for iCloud storage — a mainstream consumer audience, not a fraud-tooling one. Reason about the base rate structurally: using Private Relay requires a real Apple device, a paid Apple account, and Safari — three things fraud automation avoids and ordinary customers have by default. Treating this population as VPN-class risk is a calibration error.

Detecting WARP: A Probabilistic Problem

WARP is harder. Cloudflare publishes their edge IP ranges (the IPv4 list and the IPv6 list, both hand-maintained and rarely changing), but those ranges are shared between WARP egresses and the millions of customer websites Cloudflare fronts as a CDN. There is no public flag distinguishing "this Cloudflare IP is currently being used as a WARP egress" from "this Cloudflare IP is a CDN cache for example.com."

Three approaches work in practice, in increasing order of accuracy:

1. Heuristic — Cloudflare ASN + originating-side patterns. AS13335 (Cloudflare) is the ASN for both. Inbound traffic on AS13335 with a `CF-Connecting-IP` header *and* the absence of standard browser-fronting headers suggests WARP rather than CDN. Standard browser HTTP/2 frame ordering and TLS fingerprint differs slightly between WARP-tunneled clients and direct-via-Cloudflare clients, though the differences are small enough that a rule based purely on this will have noisy false-positive rates.

2. Behavioural — connection-pattern profiling. WARP sessions persist longer than CDN cache hits and exhibit per-user request patterns (one user navigating across multiple domains over an hour). If you maintain session-level telemetry on your own site, the IP-plus-session-pattern combination is a useful WARP tell — but it's your application-layer data doing the work, not anything the IP alone reveals.

3. Range tagging, honestly labelled. Predax's is_warp flag is derived from Cloudflare's published ranges — it tells you "this IP is Cloudflare egress, consistent with WARP," not "this is definitely a WARP user." That coarseness is a property of the problem, not the implementation: Cloudflare has not published a dedicated WARP-only range, so no vendor can do better than range-plus-context, whatever their marketing implies. Treat the flag as exactly what it is — a reason to *not* punish the datacenter classification, rather than a positive identification.

For most operators the right posture is: ingest the Cloudflare IP ranges as a tag, accept that "this IP is in Cloudflare's network" is the determinable fact, and treat that fact as a coarse-grained signal — not as actionable fraud. If you have stronger needs (sanctions compliance, high-fraud verticals like crypto onramps), supplement with a vendor feed that exposes WARP detection as a confidence score rather than a boolean.

A Three-Tier Risk Posture

The right action for Private Relay and WARP traffic depends on what you're protecting and what your false-positive cost looks like. Rather than the binary block-or-allow most legacy fraud rules use, the operationally clean approach is a three-tier posture:

The downgrade in Tier 2 is the operative move. For a Private Relay session, treat the country code as authoritative (Apple commits to country-level accuracy) and skip the city-level mismatch check. Continue to apply velocity rules, device-fingerprint rules, and content-signal rules — none of those are weakened by the IP-layer obscuration. What you lose is city-level geolocation as a fraud signal for that session, and what you gain is not blocking real customers.

For WARP, the same downgrade applies but with the additional caveat that you cannot be as certain. We recommend treating Tier 2 as a soft category: if a WARP-flagged session also exhibits Tier-3 behaviours (impossible-velocity geo changes, mismatched device fingerprint), promote it to Tier 3. If it doesn't, leave it alone.

We previously covered the underlying ASN-based filter pattern in our ASN-based blocking explainer; the Private Relay / WARP work is a refinement of that pattern that recognises specific ASNs and ranges within "datacenter" deserve different treatment.

Code: Putting It Together with Predax

The core decision logic in a Python web handler:

import os, requests
from flask import request, abort

PREDAX_API_KEY = os.environ["PREDAX_API_KEY"]

def classify_ip(ip):
    r = requests.post(
        "https://predax.io/api/v1/check/ip",
        headers={"X-API-Key": PREDAX_API_KEY},
        json={"ip": ip},
        timeout=2,
    )
    return r.json()

def is_acceptable(ip, billing_country):
    info = classify_ip(ip)
    classification = info.get("classification", {})
    location = info.get("location", {})
    # Tier 2: Private Relay / WARP — pass with country-only geo check
    if classification.get("is_private_relay") or classification.get("is_warp"):
        return location.get("country_code") == billing_country
    # Tier 3: Datacenter / VPN / Tor without privacy-CDN tag — risk score
    if classification.get("risk_score", 0) >= 75:
        return False
    if classification.get("is_tor") or classification.get("is_proxy"):
        return False
    # Tier 1: Pass
    return True

@app.route("/checkout", methods=["POST"])
def checkout():
    ip = request.headers.get("CF-Connecting-IP") or request.remote_addr
    if not is_acceptable(ip, request.json["billing_country"]):
        abort(403)
    # ... normal processing ...

The two fields Predax returns — classification.is_private_relay (deterministic, derived from Apple's published egress CSV) and classification.is_warp (coarser, derived from Cloudflare's published ranges) — let you write the Tier-2 branch without per-vendor IP-list management on your side. The same fields appear in the response shape covered in our bot detection guide and the IP risk scoring explainer.

Compliance: GDPR, IP Logging, and the Privacy-Layer Trend

A worth-noting context for anyone making blocking decisions: under UK GDPR and the EU GDPR Article 4(1), an IP address is personal data when it can reasonably be combined with other data to identify an individual — which is essentially always for an operator with session logs. The lawful-basis stack for processing IP for fraud prevention is well-established (Article 6(1)(f) legitimate interest, balanced against the data subject's rights), and the ICO's guidance on cookies and similar technologies confirms that fraud-prevention IP processing is a permitted activity without consent.

But Private Relay and WARP exist precisely because users want to assert their right to obscure exactly the data your fraud system is processing. Blocking them disproportionately to their actual fraud risk transforms a legal-but-borderline activity into a measurable customer-experience cost, and increasingly into a customer-perception cost — privacy-conscious users are more likely to assume your aggressive block is malicious rather than a calibration error.

The pragmatic compliance stance is to document your treatment of Private Relay and WARP traffic explicitly in your fraud-prevention policy. State that you do not block these sessions categorically, state how you handle the geolocation downgrade, and retain the ability to explain a step-up challenge to a Private Relay user who asks. This is also good fraud-stack hygiene independent of compliance — opaque blocking decisions become harder to debug and harder to tune over time.

For operators new to the lawful-basis-vs-consent question generally, the ICO's data-protection self-assessment is a sensible starting point. We've also written previously on the account takeover prevention and chargeback prevention angles, both of which intersect with the privacy-CDN topic.

What's Coming Next

The privacy-CDN trend is not pausing. Apple has hinted at expanding Private Relay coverage beyond Safari to native iOS networking APIs — work signposted in the Network framework documentation over the past two release cycles. Cloudflare keeps shipping WARP product updates that move it closer to a default consumer privacy product. Mozilla has its own Mozilla VPN and a separate Firefox Relay that obscures email, with hints at IP-relay extension plans. Google's Android private DNS / IP Protection work, currently in limited rollout, is the same shape of feature for Chrome on Android.

In two to three years it is plausible that 30–50% of consumer mobile web traffic globally egresses through some form of consumer-facing privacy CDN. Fraud detection that depends on residential-vs-datacenter as the primary signal will degrade in that environment regardless of vendor quality. The teams that win in that world are the ones who treat the IP layer as one of several signals — not as the canonical signal — and who calibrate IP-derived rules per-traffic-class rather than globally.

We covered the broader bot-detection landscape, including this trend in passing, in our 2026 bot traffic detection guide. The conclusion there applies double here: layered, calibrated, observable, with explicit handling for the categories that didn't exist five years ago.

How Predax Helps

Every /api/v1/check/ip response from Predax includes `classification.is_private_relay` (boolean, derived from Apple's published egress CSV), `classification.is_warp` (boolean, derived from Cloudflare's published ranges — see the honesty note above about what that can and can't tell you), `classification.is_datacenter` (distinct from the two privacy-CDN flags), and the standard `risk_score` (0–100 composite). The four fields let you implement the three-tier posture above in fewer than 30 lines of server code — Tier 1 / Tier 2 / Tier 3 routing falls out of a single function.

For WordPress and WooCommerce operators, the Predax WordPress Security plugin and WooCommerce Fraud Guard never treat "datacenter" as an automatic block: datacenter blocking is an explicit opt-in toggle, the recommended presets monitor rather than block ambiguous categories, and verified crawlers are exempted before the datacenter rule ever runs. That structure is what protects Private Relay users in practice — the failure mode this post describes requires a blanket datacenter block, and the plugins are built to make that a deliberate choice rather than a default.

Both the Apple egress CSV and the Cloudflare range data are refreshed on a daily schedule. View pricing — the free tier includes the privacy-CDN flags, since miscategorising a meaningful slice of mobile Safari traffic shouldn't be a paywall feature.

Frequently Asked Questions

Is Apple Private Relay a VPN?

Technically no, and the distinction matters for risk decisions. A VPN routes all of a device's traffic through a single tunnel that the provider can correlate end-to-end. Private Relay uses two hops: Apple sees the user's real IP but not the destination, and a third-party CDN partner (Cloudflare, Akamai, or Fastly) sees the destination but only a coarse geographic IP attributable to the user's country and approximate region. Apple cannot read traffic, the CDN partner cannot identify the user, and the relay only carries unencrypted Safari traffic plus DNS — not all device traffic. The privacy guarantee is closer to Tor's onion-routing model than to a commercial VPN, but with a known operator (Apple) and no anonymity guarantees against subpoena. Functionally, your detection stack will see the egress IPs as 'cloud / CDN' and should treat them as low-risk Safari traffic from a real iCloud+ subscriber, not as VPN evasion.

Should I block Cloudflare WARP traffic?

Only if you have a concrete reason — and 'looks like a datacenter IP' isn't one. WARP egresses from Cloudflare's network, so naive datacenter-detection rules will flag it, but the underlying users are overwhelmingly mobile-app-installed humans on free or paid plans, not bots. A 2024 Cloudflare blog post stated WARP serves 'tens of millions' of devices, and observed mix of WARP traffic in payment-fraud benchmarks tracks closely with regular consumer mobile traffic. If you must restrict (e.g. a sanctions-compliance product where you legally cannot serve obscured-jurisdiction traffic), block at the highest tier of certainty rather than blanket-rejecting WARP — Cloudflare publishes WARP egress IP ranges, and many ASN feeds tag them. For everyone else, the right answer is 'flag, don't block': raise the risk score modestly, watch the conversion rate, and unflag if you see no fraud lift.

Can I tell Private Relay apart from a regular VPN by IP alone?

Mostly yes, with high accuracy. Apple publishes the Private Relay egress IP list as a CSV updated daily, mapping each egress IP to an approximate region (country + state-ish geohash). Any IP appearing in that list is, by definition, Private Relay traffic and not a generic VPN. Cloudflare similarly publishes WARP IP ranges (the same ranges used by their CDN, which complicates things — a WARP-egress IP can also be a regular Cloudflare-fronted website's origin). For both, the right approach is feed-driven: ingest the CSV daily, tag your IP intelligence pipeline with is_private_relay and is_warp booleans, and treat them as distinct categories from generic VPN traffic in your risk model. Predax tags both feeds automatically.

Does Private Relay break IP-based geolocation for fraud rules?

Partially. Apple deliberately preserves country-level geolocation accuracy — the CSV ranges include a region_code matching ISO 3166 country codes, and Apple commits to keeping the egress IP within the user's country (or one of the country's main timezones for very large countries like the US). But sub-country accuracy collapses: a New York user might egress through a New Jersey IP, a London user through a Manchester IP. If your fraud rules depend on city-level geolocation (matching billing-address city to IP-derived city), Private Relay traffic will look anomalous despite being legitimate. The fix is to detect Private Relay traffic explicitly and downgrade your geolocation requirement to country-level for those sessions only — full country mismatch remains a meaningful signal, sub-country mismatch on a Private Relay session is noise.