Renseignement IPDétecter iCloud Private Relay et Cloudflare WARP, puis les laisser passer
Détectez iCloud Private Relay grâce à la liste de sortie d'Apple (285 091 lignes) et à des requêtes API en direct, découvrez pourquoi Cloudflare WARP n'a pas de liste publique, et laissez passer les utilisateurs de relais.
Nous avons téléchargé la liste d'Apple à 09 h 40 UTC le 12 octobre 2026. Elle contenait 285 091 préfixes, 41 734 en IPv4 et 243 357 en IPv6, répartis sur 235 codes pays. Dans le bloc 104.28.0.0/16 de Cloudflare, 19 723 des 65 536 adresses y figurent. Les 45 813 autres non : une règle écrite pour ce bloc, ou pour tout le réseau de Cloudflare, ne peut donc pas distinguer un utilisateur de Private Relay de n'importe quel autre trafic acheminé par là.
Nous analysons ci-dessous le fichier d'Apple et fournissons un script de correspondance Python testé pour IPv4 et IPv6. Nous expliquons ce que l'on peut et ne peut pas savoir sur WARP, et montrons de vraies requêtes sur des adresses de relais, dont deux cas où notre propre géolocalisation contredit celle d'Apple. L'article se termine par un tableau de politique. Pour l'ensemble des signaux d'anonymisation, commencez par le fonctionnement de la détection de VPN et de proxy.
Comment détecter iCloud Private Relay : utiliser la liste d'Apple elle-même
Apple publie tous les préfixes de sortie de Private Relay dans un seul fichier CSV : une correspondance exacte vous indique donc qu'une IP est une sortie de relais. Le guide d'Apple destiné aux opérateurs de réseaux et de serveurs renvoie les serveurs vers cette liste, ou vers un indicateur fourni par un prestataire :
« Your server can recognize traffic from Private Relay by using the above list of Private Relay IP addresses or by checking how it's categorized by your geo IP database provider. » (Votre serveur peut reconnaître le trafic de Private Relay en utilisant la liste d'adresses IP de Private Relay ci-dessus, ou en vérifiant comment il est classé par votre fournisseur de base de données de géolocalisation IP.)
La même page cite les champs à rechercher : « Other relevant fields may include: 'is_relay', 'is_hosting', 'privacy_service', or 'privacy_proxy'. » (D'autres champs pertinents peuvent inclure…) Autrement dit, Apple s'attend à ce que vous utilisiez soit sa liste, soit un champ comme celui que renvoie notre API.
Cette liste est aussi propre d'une manière que la plupart des listes d'IP ne le sont pas. La présentation de Private Relay publiée par Apple en décembre 2021 précise que les adresses IP des relais « ne sont utilisées ni partagées à aucune autre fin que la fourniture du service Private Relay ». Une correspondance exacte n'a donc aucun dommage collatéral. Le trafic de personne d'autre ne sort par ces adresses.
Ce que contient le CSV de sortie d'Apple
Le fichier se trouve à l'adresse https://mask-api.icloud.com/egress-ip-ranges.csv. Nous l'avons téléchargé et avons analysé chaque ligne avec le module ipaddress de Python.
| Mesure | Valeur (récupérée le 12/10/2026, 09 h 40 UTC) |
|---|---|
| Lignes (préfixes) | 285 091 |
| Préfixes IPv4 | 41 734 |
| Préfixes IPv6 | 243 357 |
| Adresses IPv4 couvertes | 105 647 |
| Codes pays distincts | 235 |
| Colonnes | 5 : préfixe, pays, région, ville et un dernier champ vide |
| Taille du fichier | 12 047 231 octets |
| Préfixes qui se chevauchent | Aucun |
Chaque ligne est une ligne de geofeed. Voici deux vraies lignes du fichier :
172.224.226.0/27,GB,GB-EN,London,
104.28.46.99/32,ZM,,Lusaka,
La deuxième ligne a une région vide : votre analyseur doit donc accepter les champs vides. Un piège de comptage : wc -l affiche 285 090, soit une de moins, parce que le fichier ne se termine pas par un saut de ligne. Comptez plutôt les lignes analysées.
Interroger régulièrement le fichier ne coûte presque rien. Le serveur a renvoyé un ETag, "6acc40fb-b7d37f", et a répondu à notre requête conditionnelle par 304 Not Modified. Apple ne dit pas à quelle fréquence la liste est mise à jour, nous ne ferons donc pas de supposition. Choisissez la fréquence d'actualisation qui vous convient.
Pourquoi une règle par ASN ou par /16 ne suffit pas
Les sorties de relais partagent des réseaux avec d'autres trafics. Dans 104.28.0.0/16, 19 723 des 65 536 adresses figurent sur la liste d'Apple, et les autres non. La présentation d'Apple indique que le second relais « est exploité par des partenaires tiers qui comptent parmi les plus grands réseaux de diffusion de contenu (CDN) au monde ». Les trois relais que nous avons échantillonnés se trouvent sur deux d'entre eux, Cloudflare (AS13335) et Akamai (AS36183).
Bloquer AS13335 touche bien plus que les utilisateurs de relais. L'autoriser en bloc laisse passer bien plus que des relais. La correspondance par préfixe est l'outil précis, et vous pouvez vérifier n'importe quelle IP pour VPN ou relais pour voir comment une adresse donnée est classée.
Pourquoi une IP de relais n'est pas une IP de VPN
Private Relay masque l'IP de l'utilisateur au site, mais le maintient dans sa région réelle, ne couvre qu'une partie du trafic et est réservé aux appareils Apple validés sur des comptes payants. C'est pourquoi il ne doit pas être évalué comme un VPN.
La conception répartit les connaissances entre deux relais exploités par des entreprises différentes. Apple exploite le premier, qui voit l'adresse de l'utilisateur mais pas le site. Un partenaire exploite le second, qui voit le site mais pas l'utilisateur. La page d'Apple destinée aux opérateurs explique qu'ainsi, aucune partie, Apple compris, ne peut voir le détail de la navigation d'un utilisateur.
| Saut | Voit l'IP de l'utilisateur | Voit le site visité |
|---|---|---|
| iPhone, iPad ou Mac de l'utilisateur | Oui | Oui |
| Premier relais (Apple) | Oui | Non |
| Second relais (un réseau partenaire, par ex. Cloudflare ou Akamai) | Non | Oui |
| Votre serveur | Non, seulement l'IP du relais | C'est le site |
Quatre phrases de la page d'Apple destinée aux opérateurs changent la façon dont vous devez traiter ces adresses :
- Périmètre. « Private Relay protects users' web browsing in Safari, DNS resolution queries, and insecure http app traffic. » (Private Relay protège la navigation web dans Safari, les requêtes de résolution DNS et le trafic http non sécurisé des applications.) Une IP de relais ne signifie pas une session Safari. Une application qui envoie des requêtes http en clair arrive de la même façon.
- Région. « Private Relay preserves the region the user is in, so your server can trust the region assigned to the IP address it sees. » (Private Relay conserve la région de l'utilisateur, votre serveur peut donc se fier à la région attribuée à l'adresse IP qu'il voit.) La présentation de 2021 ajoute qu'il « ne permet pas aux utilisateurs de se présenter comme se connectant depuis un autre pays ou une autre région ».
- Validation. « All connections that use Private Relay validate that the client is an iPhone, iPad, or Mac and that the customer has a valid iCloud+ subscription. » (Toutes les connexions qui utilisent Private Relay vérifient que le client est un iPhone, un iPad ou un Mac et que l'utilisateur dispose d'un abonnement iCloud+ valide.)
- Stabilité. « The relay IP address will remain stable during a browsing session while a user is interacting with your website. » (L'adresse IP du relais reste stable pendant une session de navigation, tant que l'utilisateur interagit avec votre site.)
Un VPN permet à l'utilisateur de choisir n'importe quel pays et couvre tout l'appareil. Cloudflare est franc à propos de son propre produit : « Technically, WARP is a VPN » (techniquement, WARP est un VPN), écrivait l'entreprise lors du lancement de WARP. Nous revenons sur WARP plus bas.
Un piège pratique : certaines sorties de relais se trouvent dans des centres de données, si bien que des indicateurs d'hébergement peuvent se déclencher. Notre requête sur 172.224.226.1, un relais présent sur la liste d'Apple, renvoie is_hosting: true. C'est pourquoi des relais apparaissent comme des IP de centre de données, et pourquoi un blocage global de l'hébergement touche des clients d'Apple.
Comparer une IP à la liste d'Apple en Python
Chargez le CSV dans des plages d'entiers triées, une liste par version d'IP, et effectuez une recherche dichotomique. Actualisez avec une requête conditionnelle, et conservez la dernière copie valide si un téléchargement échoue ou paraît incorrect.
Voici le script exact que nous avons exécuté le 12 octobre 2026, sous Python 3.9.6. Il n'utilise que la bibliothèque standard.
"""Match an IP against Apple's iCloud Private Relay egress list. Standard library only."""
import bisect, csv, ipaddress, os, tempfile, time, urllib.error, urllib.request
URL = "https://mask-api.icloud.com/egress-ip-ranges.csv"
CSV_PATH, ETAG_PATH, MIN_ROWS = "egress.csv", "egress.etag", 100_000
def load(path):
"""Parse the CSV into one sorted range list per IP version, then validate it."""
ranges = {4: [], 6: []}
with open(path, newline="") as f:
for row in csv.reader(f):
if len(row) != 5:
raise ValueError(f"bad row: {row}")
net = ipaddress.ip_network(row[0], strict=False)
ranges[net.version].append((int(net.network_address), int(net.broadcast_address), *row[:4]))
index = {}
for version, rs in ranges.items():
rs.sort()
if any(b[0] <= a[1] for a, b in zip(rs, rs[1:])):
raise ValueError(f"overlapping IPv{version} prefixes")
index[version] = ([r[0] for r in rs], rs)
return index, len(ranges[4]) + len(ranges[6])
def refresh(index=None, rows=0):
"""Fetch a new copy only if it changed. On any failure, keep serving the last good one."""
headers = {}
if index and os.path.exists(ETAG_PATH):
headers["If-None-Match"] = open(ETAG_PATH).read().strip()
fd, tmp = tempfile.mkstemp(dir=".", suffix=".part")
os.close(fd)
try:
with urllib.request.urlopen(urllib.request.Request(URL, headers=headers), timeout=60) as resp:
with open(tmp, "wb") as out:
out.write(resp.read())
etag = resp.headers.get("ETag", "")
new_index, new_rows = load(tmp)
if new_rows < max(MIN_ROWS, 0.9 * rows):
raise ValueError(f"only {new_rows} rows, keeping the old file")
os.replace(tmp, CSV_PATH) # atomic swap
with open(ETAG_PATH, "w") as f:
f.write(etag)
print(f"downloaded new list: {new_rows:,} prefixes")
return new_index, new_rows
except urllib.error.HTTPError as e:
print("not modified, keeping current list" if e.code == 304 else f"refresh failed: {e}")
except Exception as e:
print(f"refresh failed: {e}")
finally:
if os.path.exists(tmp):
os.remove(tmp)
return index, rows
def match(index, ip):
"""Return Apple's row for a relay egress IP, or None."""
try:
addr = ipaddress.ip_address(ip.strip())
except (ValueError, AttributeError):
return None
if addr.version == 6 and addr.ipv4_mapped:
addr = addr.ipv4_mapped # ::ffff:104.28.46.99 becomes 104.28.46.99
starts, rs = index[addr.version]
n = int(addr)
i = bisect.bisect_right(starts, n) - 1
if i >= 0 and n <= rs[i][1]:
return dict(zip(("prefix", "country", "region", "city"), rs[i][2:]))
return None
if __name__ == "__main__":
t0 = time.time()
index, rows = load(CSV_PATH) if os.path.exists(CSV_PATH) else (None, 0)
index, rows = refresh(index, rows)
print(f"{rows:,} prefixes ready in {time.time() - t0:.1f}s")
for ip in ["104.28.46.99", "172.224.226.1", "2a02:26f7:c880::1", "::ffff:104.28.28.41",
"162.159.192.1", "102.129.235.17", "not-an-ip"]:
print(f"{ip:22} {match(index, ip)}")
La première exécution, à 09 h 41 UTC, a téléchargé le fichier et affiché :
downloaded new list: 285,091 prefixes
285,091 prefixes ready in 12.8s
104.28.46.99 {'prefix': '104.28.46.99/32', 'country': 'ZM', 'region': '', 'city': 'Lusaka'}
172.224.226.1 {'prefix': '172.224.226.0/27', 'country': 'GB', 'region': 'GB-EN', 'city': 'London'}
2a02:26f7:c880::1 {'prefix': '2a02:26f7:c880::/54', 'country': 'GB', 'region': 'GB-EN', 'city': 'London'}
::ffff:104.28.28.41 {'prefix': '104.28.28.41/32', 'country': 'AU', 'region': 'AU-SA', 'city': 'Adelaide'}
162.159.192.1 None
102.129.235.17 None
not-an-ip None
162.159.192.1 est une adresse de connexion WARP et 102.129.235.17 un serveur VPN commercial : aucune des deux ne devait correspondre, et aucune n'a correspondu. Nous avons aussi testé les chemins d'échec :
- Fichier inchangé. La deuxième exécution a envoyé l'ETag enregistré, reçu un 304 et affiché « not modified, keeping current list ». Le chargement et l'indexation du fichier local ont pris 4,3 secondes : construisez donc l'index une seule fois au démarrage, pas à chaque requête.
- Téléchargement défectueux. Nous avons pointé
URLvers un chemin inexistant (le serveur d'Apple a répondu 400). Séparément, nous avons fixé le nombre minimal de lignes au-dessus du nombre réel. Dans les deux cas, le script a consigné l'échec, supprimé son fichier temporaire et continué à répondre à partir de l'ancienne copie. - Adresses mappées.
::ffff:104.28.28.41a correspondu à sa ligne IPv4. Les serveurs double pile enregistrent souvent les clients IPv4 sous cette forme.
Comme le fichier ne contient aucun préfixe qui se chevauche, une seule recherche dichotomique par requête suffit. Le chargeur refuse tout futur fichier présentant des chevauchements, et l'actualisation se rabat alors sur la dernière copie valide.
Comment détecter Cloudflare WARP, et pourquoi il n'existe pas de liste
Vous ne pouvez pas comparer WARP à une liste publique, car Cloudflare n'en publie pas. WARP ne peut être identifié que par un fournisseur qui étiquette les plages qu'il connaît, ou sur l'appareil de l'utilisateur lui-même.
La documentation de Cloudflare sur les politiques de sortie est sans ambiguïté : « Cloudflare does not publish Cloudflare One Client egress IP ranges. » (Cloudflare ne publie pas les plages d'IP de sortie du client Cloudflare One.) Les « plages d'IP WARP » qui circulent sur les forums sont autre chose. Le guide pare-feu de Cloudflare dit de 162.159.192.0/24 : « This IP is used for the consumer WARP client (1.1.1.1 with WARP) and is not required for Zero Trust services. » (Cette IP est utilisée par le client WARP grand public, 1.1.1.1 avec WARP, et n'est pas requise pour les services Zero Trust.) C'est là que l'application WARP se connecte. Votre serveur web ne voit jamais ces adresses comme IP clientes.
Le site obtient-il l'adresse réelle de l'utilisateur par un autre moyen ? Pas en navigation normale. La FAQ WARP de Cloudflare indique : « 1.1.1.1 + WARP replaces your original IP address with a Cloudflare IP that consistently and accurately represents your approximate location. This happens regardless of whether the site is on the Cloudflare network or not. » (1.1.1.1 + WARP remplace votre adresse IP d'origine par une IP Cloudflare qui représente de façon cohérente et précise votre position approximative, que le site soit ou non sur le réseau Cloudflare.)
La même FAQ documente deux fuites : « WARP does not proxy WebRTC traffic. » (WARP ne fait pas transiter le trafic WebRTC.) Et : « If you grant a website access to your microphone or camera, traffic will bypass WARP and your original IP address will be visible. » (Si vous accordez à un site l'accès à votre micro ou à votre caméra, le trafic contourne WARP et votre adresse IP d'origine devient visible.)
Sur l'appareil lui-même, https://www.cloudflare.com/cdn-cgi/trace affiche un champ warp=. Sur notre machine, qui n'utilise pas WARP, il indiquait warp=off. Seule la personne qui ouvre cette page le voit : c'est utile à une équipe support qui diagnostique la connexion d'un client, mais inutile à un serveur qui évalue un visiteur.
Notre API renvoie relay_provider: "Cloudflare WARP" pour les plages de connexion WARP publiées par Cloudflare. Une requête sur 162.159.192.1 a renvoyé is_relay: true, relay_provider: "Cloudflare WARP", is_hosting: true et is_anycast: true, avec un score de 24 et allow. C'est l'adresse à laquelle se connectent les applications WARP, pas une adresse que votre serveur verra comme visiteur.
Ce que renvoie notre API pour les adresses Cloudflare absentes de la liste d'Apple
Les adresses de sortie du réseau de confidentialité de Cloudflare qui ne figurent pas sur la liste d'Apple reviennent avec le libellé "Cloudflare", tandis que les plages de connexion WARP publiées par Cloudflare reviennent avec "Cloudflare WARP". Voici 104.28.210.10. Elle se trouve dans le même /16 que deux de nos relais Apple, mais n'est pas sur la liste d'Apple. Voici une copie abrégée de notre requête à 09 h 40 UTC le 12 octobre 2026, valeurs non modifiées :
{
"ip": "104.28.210.10",
"asn": {
"asn": 13335,
"org": "CLOUDFLARENET - Cloudflare, Inc.",
"user_type": "consumer_privacy_network"
},
"geo": {
"country_code": "CA",
"city": "Toronto"
},
"detection": {
"is_vpn": false,
"is_hosting": false,
"is_relay": true,
"is_anonymous": false,
"relay_provider": "Cloudflare"
},
"scoring": {
"fraud_score": 9,
"recommended_action": "allow",
"detection_methods": ["relay_ip"]
}
}
| IP | Sur la liste d'Apple ? | relay_provider | Autres champs | Score, action, méthodes |
|---|---|---|---|---|
| 104.28.210.10 | Non | Cloudflare | AS13335, consumer_privacy_network, is_vpn false, is_hosting false | 9, allow, relay_ip |
| 104.28.28.41 | Oui (AU, Adélaïde) | iCloud Private Relay | AS13335, consumer_privacy_network | 9, allow, relay_ip |
| 162.159.192.1 | Non (adresse de connexion WARP) | Cloudflare WARP | is_hosting true, is_anycast true | 24, allow, datacenter_ip + no_ptr_datacenter + relay_ip |
| 102.129.235.17 (VPN, pour comparaison) | Non | aucun | is_vpn true, is_anonymous true | 92, block, known_vpn_server + openvpn_open + ipsec_open |
Lisez "Cloudflare" comme « une adresse de sortie de confidentialité grand public de Cloudflare non attribuée à Apple ». Cela ne signifie pas un utilisateur WARP confirmé, et nous ne le prétendons pas. Notre référence d'API ne liste aujourd'hui que deux valeurs de relay_provider, « iCloud Private Relay » et « Cloudflare WARP » : cette troisième valeur n'est donc pas encore documentée. Nous avons demandé à l'équipe backend de la documenter.
L'enseignement utile se trouve dans les deux premières lignes. À l'intérieur d'un même /16 de Cloudflare, la correspondance exacte avec le CSV sépare le relais d'Apple (104.28.28.41) des autres sorties de confidentialité de Cloudflare (104.28.210.10). Notre libellé concorde avec la liste d'Apple dans les deux cas. Les deux obtiennent un score de 9 et allow : votre politique est donc la même dans les deux cas. La ligne du VPN n'a pas non plus de nom de fournisseur : nos sondes l'ont détecté, mais il ne figure sur aucune liste de fournisseurs dont nous disposons, ce qui explique pourquoi un VPN peut rester anonyme.
Private Relay et WARP côte à côte
| Question | iCloud Private Relay | Cloudflare WARP |
|---|---|---|
| Qui l'exploite | Apple, avec des réseaux partenaires pour le second relais | Cloudflare |
| Qui peut l'utiliser | Les abonnés iCloud+ sur un iPhone, iPad ou Mac validé | Quiconque installe l'application gratuite 1.1.1.1 |
| Ce qu'il couvre | Safari, les requêtes DNS, le trafic http non sécurisé des applications | Le trafic de l'appareil, sauf WebRTC et les sites ayant accès à la caméra ou au micro |
| Liste de sortie publique | Oui, le CSV d'Apple | Non |
| Localisation | Région conservée ; ville approximative par défaut, zone plus large si l'utilisateur le choisit | Une IP Cloudflare qui représente la position approximative de l'utilisateur |
| Comment un serveur l'identifie | Correspondance exacte avec le CSV d'Apple, ou indicateur de relais d'un fournisseur | Uniquement le libellé d'un fournisseur |
Les deux peuvent se trouver sur AS13335 : le réseau seul ne permet d'identifier ni l'un ni l'autre.
Ce que renvoient nos requêtes pour les IP de relais
Dans nos requêtes, les adresses Private Relay reviennent comme relais, pas comme anonymes ou VPN, et aboutissent à allow en l'absence d'autres éléments. Nous avons suivi 104.28.46.99 de bout en bout. La ligne d'Apple indique Zambie, Lusaka. Voici la requête, telle que vous l'enverriez avec une clé :
curl https://api.geoiphub.com/v1/lookup/104.28.46.99 \
-H "x-api-key: YOUR_API_KEY"
Nous l'avons exécutée sans clé à 09 h 40 UTC le 12 octobre 2026, ce que l'API autorise pour un usage léger. Voici une copie abrégée de la réponse, valeurs non modifiées :
{
"ip": "104.28.46.99",
"asn": {
"asn": 13335,
"org": "CLOUDFLARENET - Cloudflare, Inc.",
"asn_type": "unknown",
"user_type": "consumer_privacy_network"
},
"geo": {
"country_code": "AO",
"region": "Luanda",
"city": "Luanda",
"geo_confidence": 0.8
},
"detection": {
"is_proxy": false,
"is_vpn": false,
"is_tor": false,
"is_hosting": false,
"is_relay": true,
"is_anonymous": false,
"anonymity_level": "medium",
"relay_provider": "iCloud Private Relay"
},
"scoring": {
"fraud_score": 9,
"recommended_action": "allow",
"detection_methods": ["relay_ip"]
}
}
Le relais est nommé, is_vpn et is_anonymous sont à false, et scoring.detection_methods montre le seul signal qui s'est déclenché : relay_ip. Le score est de 9, l'action est donc allow. La géolocalisation indique l'Angola, ce que contredit la ligne d'Apple ; nous traitons ce point dans la section suivante. Pour cette adresse, la décision est de l'autoriser, de limiter son débit comme une adresse partagée et de prendre sa localisation dans la ligne d'Apple.
Voici les autres relais à côté d'un vrai VPN :
| IP | Ligne d'Apple | Notre résultat le 12/10/2026 |
|---|---|---|
| 172.224.226.1 | GB, GB-EN, Londres | AS36183 Akamai, asn_type hosting ; is_relay true, iCloud Private Relay, is_hosting true ; score 24, allow ; datacenter_ip, no_ptr_datacenter, relay_ip ; géo GB, Londres |
| 104.28.28.41 | AU, AU-SA, Adélaïde | AS13335 ; is_relay true, iCloud Private Relay ; score 9, allow ; relay_ip ; géo AU, Sydney, 0,8 |
| 102.129.235.17 (VPN) | Absente de la liste | AS834 IPXO ; is_vpn true, is_anonymous true ; score 92, block ; known_vpn_server, openvpn_open, ipsec_open |
L'indicateur de relais ne fait pas baisser le score. Il s'y ajoute. Sur 104.28.46.99, relay_ip est la seule entrée de detection_methods : il représente donc la totalité du score de 9. 172.224.226.1 obtient 24 parce que deux signaux de centre de données se sont aussi déclenchés, ce qui le laisse à un point sous la limite allow de 25. Les relais aboutissent donc à allow en l'absence d'autres éléments. Si autre chose pèse contre l'adresse, par exemple une inscription sur une liste d'abus, le score augmente et l'action peut passer à review. La page comment le score est calculé liste les signaux.
L'API étiquette le relais. Le CSV d'Apple est votre vérification indépendante, et le script ci-dessus l'exécute sans nous. Évaluer un relais comme s'il s'agissait d'un VPN est le cas typique des faux positifs de la détection de VPN.
Pourquoi les utilisateurs de Private Relay affichent la mauvaise ville, y compris dans nos données
Une IP de relais ne garantit que la région de l'utilisateur, et une ville approximative par défaut. La seule localisation qui fait foi pour une IP de relais est la ligne d'Apple elle-même, et notre base de données n'est pas toujours d'accord avec elle.
La page d'Apple destinée aux opérateurs indique que l'IP du relais « représente fidèlement, par défaut, la localisation approximative du client à l'échelle de la ville ». Les utilisateurs peuvent élargir cette zone. Le Guide d'utilisation de l'iPhone actuel d'Apple propose deux options de localisation de l'adresse IP, « Maintain General Location » (conserver la localisation générale) et « Use Country and Time Zone » (utiliser le pays et le fuseau horaire). La présentation de 2021 les décrit. La première choisit des adresses qui « correspondent à peu près à une zone de la taille d'une ville cohérente avec l'endroit d'où l'utilisateur se connecte réellement ». La seconde choisit des adresses « sur une zone plus large, plus régionale », et « toutes les adresses IP de relais restent associées au pays et au fuseau horaire d'origine de l'utilisateur ».
Nous avons comparé notre géolocalisation aux lignes d'Apple pour les trois relais :
| IP | Ligne d'Apple | Notre géolocalisation | Concordance ? |
|---|---|---|---|
| 104.28.46.99 | ZM, Lusaka | AO, Luanda (geo_confidence 0,8) | Non, pays différent |
| 104.28.28.41 | AU, AU-SA, Adélaïde | AU, Sydney (geo_confidence 0,8) | Pays oui, ville non |
| 172.224.226.1 | GB, GB-EN, Londres | GB, Londres | Oui |
Deux sur trois divergent. Zambie contre Angola est une erreur au niveau du pays, le genre d'erreur qui déclenche une règle de licence ou de sanctions. Adélaïde contre Sydney donne le bon pays et la mauvaise ville. Trois IP ne constituent pas un benchmark, mais elles suffisent pour fixer une règle : pour les IP de relais, prenez la localisation dans la ligne d'Apple, pas dans une base de géolocalisation, la nôtre comprise. Décidez au niveau du pays ou de la région, et traitez la ville comme une indication. Nous avons signalé les deux divergences à notre équipe backend.
Faut-il bloquer Private Relay ou WARP ? Laissez-les passer et évaluez la session
Non. Apple valide chaque client de relais et indique que les règles antifraude fondées sur l'IP « pourraient devoir être ajustées » : autorisez donc le trafic Private Relay, limitez son débit comme une adresse partagée d'opérateur, et ne renforcez l'authentification que lorsque d'autres éléments indiquent un risque.
La page d'Apple destinée aux opérateurs est claire sur ces deux points :
« Traditional fraud detection that relies on IP addresses might need to be adjusted to ensure legitimate users aren't impacted. » (La détection de fraude traditionnelle fondée sur les adresses IP pourrait devoir être ajustée pour que les utilisateurs légitimes ne soient pas pénalisés.)
« Consider treating these addresses like larger carrier-grade NAT or enterprise IP addresses to better account for this type of traffic, since many Private Relay users may be assigned to a single relay IP address. » (Envisagez de traiter ces adresses comme de grandes adresses de NAT d'opérateur ou d'entreprise, pour mieux prendre en compte ce type de trafic, car de nombreux utilisateurs de Private Relay peuvent se voir attribuer une même adresse IP de relais.)
Apple propose aussi une alternative à la page de vérification. L'entreprise note que « les mesures d'atténuation courantes incluent les CAPTCHA ou le blocage pur et simple du trafic », et indique que « tous les appareils Apple sous iOS 16, iPadOS 16 ou macOS Monterey et versions ultérieures prennent en charge les Private Access Tokens », qui permettent à un serveur de vérifier qu'il s'agit d'un appareil légitime sans identifier l'utilisateur.
Les fraudeurs peuvent-ils utiliser des relais ? Oui, mais Private Relay exige un appareil Apple et un compte iCloud+ payant. Apple indique que la validation « est conçue pour garantir que seuls des appareils Apple valides et des comptes en règle puissent utiliser Private Relay ». C'est donc un moyen coûteux de créer des comptes en masse. WARP est une application gratuite : accordez un peu plus de poids à vos autres signaux pour les sessions WARP, sans les bloquer. Les problèmes de masquage d'IP plus difficiles se situent ailleurs, par exemple du côté des proxys mobiles.
Un détail pour votre limiteur de débit : le conseil d'Apple sur le NAT d'opérateur porte sur la façon de traiter l'adresse, pas sur un indicateur. Notre champ threat.is_cgnat était à false sur les trois requêtes de relais. Fondez plutôt le traitement des adresses partagées sur is_relay ou sur la correspondance avec le CSV. Pour vérifier une adresse de vos propres journaux, collez-la dans l'outil gratuit de recherche d'IP.
| Ce que vous voyez | Action | Pourquoi |
|---|---|---|
| IP présente dans le CSV d'Apple ou is_relay true, sans autre élément de risque | Autoriser ; limiter le débit par compte ou par session, pas par IP | Apple valide l'appareil et le compte, et de nombreux utilisateurs partagent une même IP de relais |
| IP de relais ou WARP avec un signal de compte risqué (nouveau compte, pays de paiement hors de la région de l'IP, rythme d'inscriptions élevé) | Renforcer : un Private Access Token lorsque c'est possible, sinon une 2FA ou une vérification par e-mail, pas un mur de CAPTCHA | L'IP n'apporte aucun élément ; le signal de compte, si |
| IP de relais qui aboutit aussi à review, par exemple parce qu'elle figure sur une liste d'abus | Examiner | Cet élément concerne l'adresse, pas le relais |
| IP étiquetée WARP | Autoriser et évaluer la session | Gratuit et courant ; il masque l'utilisateur mais ne prouve aucune intention |
| Règles de localisation (licences, fiscalité) sur le trafic de relais | Décider au niveau du pays ou de la région d'après la ligne d'Apple, jamais de la ville | Apple conserve la région ; la ville est approximative, voire plus large selon le réglage |
Trois vérifications à faire sur vos propres journaux cette semaine :
- Comptez les utilisateurs de relais que vous avez refoulés. Croisez les 30 derniers jours d'inscriptions, de connexions et de refus avec le CSV d'Apple à l'aide du script ci-dessus. Combien d'utilisateurs de relais vos règles ont-elles refusés ou soumis à une vérification ?
- Repérez les blocages par ASN et par hébergement. Cherchez dans vos règles AS13335, AS36183 ou
is_hosting. 172.224.226.1 est un relais avecis_hosting: true: un blocage de l'hébergement touche donc les utilisateurs de relais. - Vérifiez les limites par IP et les géorepérages à l'échelle de la ville. Apple recommande de traiter les IP de relais comme du NAT d'opérateur : une limite par IP dimensionnée pour un seul foyer bridera de nombreux utilisateurs, et une barrière à l'échelle de la ville se déclenchera à tort sur une localisation approximative.
Questions fréquentes
Comment savoir si iCloud Private Relay est activé ?
Sur un iPhone, ouvrez Réglages, touchez votre nom, puis iCloud, puis Relais privé. En tant qu'exploitant d'un site, vous ne voyez pas ce réglage, seulement l'IP : si elle figure dans la liste de sortie d'Apple, la requête est passée par Private Relay.
iCloud Private Relay est-il un VPN ?
Non. Il ne couvre que Safari, le DNS et le trafic http non sécurisé des applications, maintient l'utilisateur dans son propre pays et sa propre région, et est réservé aux appareils Apple validés disposant d'iCloud+.
Cloudflare WARP masque-t-il votre adresse IP ?
Oui. Selon Cloudflare, WARP remplace l'IP d'origine par une IP Cloudflare, que le site soit ou non sur Cloudflare, sauf pour le trafic WebRTC et les sites ayant accès à la caméra ou au micro.
Où trouver la liste des adresses IP d'iCloud Private Relay ?
Apple la publie à l'adresse mask-api.icloud.com/egress-ip-ranges.csv. Le 12 octobre 2026, elle contenait 285 091 préfixes IPv4 et IPv6 répartis sur 235 codes pays.
Un site web peut-il voir l'IP réelle derrière Private Relay ?
Non, par conception. Le site ne voit que l'IP du relais, et seul le premier relais d'Apple voit l'adresse de l'utilisateur.
Faut-il bloquer iCloud Private Relay ?
Non. Apple indique que les règles antifraude fondées sur l'IP peuvent devoir être ajustées pour les utilisateurs de relais. Autorisez-le, limitez son débit comme une adresse de NAT à grande échelle (CGNAT), et ne renforcez l'authentification que sur la base d'autres signaux de risque.
L'équipe derrière l'API GeoIPHub
Rédigé par l'équipe GeoIPHub, les personnes qui développent l'API de renseignement IP GeoIPHub et son scanner. Les brouillons sont préparés avec l'aide de l'IA et relus par l'équipe ; les exemples d'API sont de vraies requêtes sur l'API en production, sauf mention « illustratif ».
Prévention de la fraude