iCloud Private Relay in Fraud Rules: Treating Relay Users Fairly

A rule like “challenge every request from a proxy or hosting IP” looks sensible until you notice how many of the challenged users are on iPhones and Macs running Safari. Many of them are not hiding anything. They pay for iCloud+, and Private Relay is part of it.

This post explains what Private Relay traffic looks like to your servers, how to recognize it reliably, why blocking it backfires, and how to build rules that stay fair to relay users while still catching abuse.

What Private Relay does

Private Relay sends Safari traffic, and some other traffic from the device, through two hops. The first relay, run by Apple, sees the user’s IP address but not the destination. The second relay, run by partner network providers, sees the destination but not the user’s IP. Your site sees a connection from the second relay’s egress address.

Two details matter for fraud rules:

• Location is coarse, not hidden. Users choose between keeping a general location or sharing only country and time zone. The egress IP maps to that approximate area, so IP geolocation still works at country level and often at region level.
• The egress addresses live on large network providers. To an IP-reputation or ASN lookup, they can look like hosting or proxy infrastructure, because in a technical sense they are.

Private Relay is not available in every country, and networks and users can turn it off. Where a user has it on, it covers their Safari browsing, and Safari is a large share of mobile browsing.

Why blocking it backfires

Most IP-based fraud rules rest on one assumption: that a hosting or proxy IP means someone made an effort to hide. For commercial VPNs, residential proxy pools and datacenter servers running scripts, that assumption is often reasonable. For Private Relay it is not. The user did not choose a proxy for your site; they turned on a privacy feature once, for everything.

Treating them like proxy users means:

• False positives on paying customers. Apple users, often on premium devices, get challenged or refused.
• Inconsistent experiences. The same person gets through on mobile data in one browser and is blocked in Safari a minute later.
• Bad training data. If those refusals feed back into your models as “fraud,” your rules learn to distrust a whole population.

Our post on reducing false positives covers why these errors compound.

Recognizing relay traffic

Apple publishes the Private Relay egress IP ranges as a CSV file, with each range’s country, region and city. Load it periodically and match request IPs against it in your own service:

import ipaddr from 'ipaddr.js';

let ranges = [];
export async function loadRelayRanges() {
  const csv = await (await fetch('https://mask-api.icloud.com/egress-ip-ranges.csv')).text();
  ranges = csv.trim().split('\n').map((line) => {
    const [cidr, country] = line.split(',');
    return { range: ipaddr.parseCIDR(cidr), country };
  });
}

export function isPrivateRelay(ip) {
  const addr = ipaddr.parse(ip);
  return ranges.some(({ range: [net, bits] }) => addr.kind() === net.kind() && addr.match(net, bits));
}

The list is large, so in production index it by address family and prefix, or load it into a radix tree, rather than scanning it linearly. Refresh it on a schedule; the ranges change.

Then combine it with the device event for the request:

const ev = await prynt.getEvent(requestId);     // @prynt/node
const relay = ev.ip && isPrivateRelay(ev.ip);

If your deployment truncates or drops stored IPs, match the address your own server saw on the form submission instead; a Safari user on the relay reaches your backend through the same egress.

Fair rules for relay traffic

Once you can recognize relay traffic, adjust how network signals count for it:

1. Do not block or challenge on network type alone. A VPN, proxy or datacenter flag on a relay IP is expected. Treat it as context.
2. Keep country-level checks. Relay egress preserves approximate location. A user claiming to be in Germany whose relay egress maps to Germany is consistent. Mismatches between the device’s timezone, locale and the egress country still mean something.
3. Let device identity and behavior decide. Relay users are still identified by device, not IP. The visitorId is built from the browser and device and does not change when the IP does, so account limits, velocity and history keep working.
4. Look for what relay does not explain. Automation (BOT, TLS_AUTOMATION), tampering, virtual machines and many accounts on one device are all independent of the network path.

Prynt’s default scoring already avoids one common trap: VPN, proxy and datacenter signals usually describe the same fact, so they count once rather than stacking. A single anonymized IP does not push an otherwise clean request to block. Your own rules should follow the same logic. If you have written custom rules in the console that block on vpn or asnType, consider moving them to challenge or tag, and apply any hard block in your own code only after checking that the request is not a relay IP. Do not put relay ranges on an allow-list: that would wave through everything else arriving on those addresses, abuse included.

The deeper lesson: IP is a weak identity

Private Relay is one instance of a broader shift. Between relays, carrier-grade NAT, mobile networks, corporate egress gateways and consumer VPNs, the IP address is a weaker identifier every year. Rules that treat an IP as a person break in both directions: many people share one address, and one person moves across many.

Device identity holds up better. The same Safari on the same iPhone produces the same visitorId whether the request arrives through the relay, a home connection or mobile data. That is why device-based controls such as accounts per device, device velocity and reputation of a specific device give stable answers where IP-based ones wobble.

Our guides on proxy detection and VPN detection explain the network signals in detail, and the VPN and proxy detection page shows what Prynt reports for each.

Checklist

• Load and refresh Apple’s egress list; tag relay requests in your logs.
• Audit existing rules that block or challenge on proxy, VPN, datacenter or hosting ASN, and measure how many relay users they hit.
• Move those rules from block to challenge or tag for relay traffic.
• Keep device-based limits unchanged; they are what still works.

Run the audit first. Seeing how many of last week’s challenges landed on relay users is usually enough to justify the change.