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. We've seen this on customer dashboards more than once: a SaaS sees a sudden 8–12% drop in iOS Safari conversion, traces it to a recently-tightened "block datacenter" rule, and discovers the cause is iCloud+ Private Relay being on by default for affected users.

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. iCloud+ has paid-tier subscriber numbers Apple does not publicly disclose at granularity, but 9to5Mac's coverage of Apple Q1 2024 paid-services subscribers put total iCloud+ paid subscribers in the high hundreds of millions globally. The base rate of this population being adversarial is very low — commercial fraud-prevention vendors who have published 2024 numbers (Sift, Forter, Stripe Radar) consistently report Private Relay sessions exhibiting fraud rates within 1–2x of clean residential mobile traffic, an order of magnitude below datacenter-VPN traffic. 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, exhibit per-user request patterns (one user navigating across multiple domains over an hour), and tend to use HTTP/3 more aggressively than typical CDN cache traffic. If you maintain session-level telemetry, the IP-plus-session-pattern feature is a strong WARP signal. This is what most third-party IP intelligence vendors actually use behind their is_warp flags.

3. Commercial threat feeds. Several vendors (including Predax's own pipeline) cross-reference Cloudflare's range data with WARP-specific behavioural patterns observed across customer telemetry to maintain a probabilistic is_warp confidence score per IP. The accuracy ceiling is around 92–96% — you'll never hit 100% without Cloudflare publishing a dedicated range, which they have explicitly declined to do.

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 new fields Predax returns — classification.is_private_relay (deterministic, derived from Apple's daily CSV) and classification.is_warp (probabilistic, derived from Cloudflare ranges plus behavioural patterns) — 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 now includes `is_private_relay` (boolean, derived from Apple's daily CSV ingest), `is_warp` (boolean with internal confidence score, derived from Cloudflare ranges plus our cross-customer behavioural telemetry), `is_datacenter` (the legacy boolean, now distinct from the two privacy-CDN flags), and the standard `risk_score` (0–100 composite). The four fields lets 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 Prevention extensions consume these flags automatically. The default plugin posture is the three-tier approach: pass Private Relay and WARP traffic with country-only geolocation, risk-score the rest, never blanket-block by datacenter status. The dashboard's threat log distinguishes "blocked: datacenter" from "passed-with-flag: private-relay" so you can see exactly what's happening and tune thresholds without having to dig into the underlying rules.

We update both the Apple egress CSV and Cloudflare range feeds on a daily Celery schedule; the lag between Apple publishing a new range and Predax tagging it is measured in hours, not days. View pricing — the free tier includes the privacy-CDN flags, since miscategorising 8% 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.