IP-IntelligenceiCloud Private Relay und Cloudflare WARP erkennen und dann durchlassen
iCloud Private Relay mit Apples Egress-Liste mit 285.091 Zeilen und Live-API-Abfragen erkennen, verstehen, warum es für Cloudflare WARP keine öffentliche Liste gibt, und Relay-Nutzer durchlassen.
Wir haben Apples Liste am 12. Oktober 2026 um 09:40 UTC heruntergeladen. Sie enthielt 285.091 Präfixe, 41.734 IPv4 und 243.357 IPv6, in 235 Ländercodes. Innerhalb von Cloudflares 104.28.0.0/16 stehen 19.723 der 65.536 Adressen darauf. Die übrigen 45.813 nicht. Eine Regel, die auf diesen Block oder auf Cloudflares gesamtes Netz zielt, kann einen Private-Relay-Nutzer also nicht von allem anderen unterscheiden, was dort geroutet wird.
Im Folgenden werten wir Apples Datei aus und stellen einen getesteten Python-Matcher für IPv4 und IPv6 vor. Wir erklären, was sich über WARP wissen lässt und was nicht, und zeigen echte Abfragen von Relay-Adressen, darunter zwei Stellen, an denen unsere eigene Geolokalisierung von Apples Angaben abweicht. Am Ende steht eine Richtlinientabelle. Für die gesamte Bandbreite an Anonymisierungssignalen beginnen Sie mit wie die Erkennung von VPNs und Proxys funktioniert.
iCloud Private Relay erkennen: Apples eigene Liste abgleichen
Apple veröffentlicht jedes Egress-Präfix von Private Relay in einer einzigen CSV-Datei, sodass ein exakter Treffer zeigt, dass eine IP ein Relay-Egress ist. Apples Leitfaden für Netzwerk- und Serverbetreiber verweist Server auf diese Liste oder auf ein Flag des Anbieters:
"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." (Ihr Server kann Verkehr von Private Relay erkennen, indem er die obige Liste der Private-Relay-IP-Adressen verwendet oder prüft, wie Ihr Anbieter der Geo-IP-Datenbank ihn kategorisiert.)
Dieselbe Seite nennt die Felder, auf die Sie achten sollten: "Other relevant fields may include: 'is_relay', 'is_hosting', 'privacy_service', or 'privacy_proxy'." (Weitere relevante Felder können 'is_relay', 'is_hosting', 'privacy_service' oder 'privacy_proxy' sein.) Apple erwartet also, dass Sie entweder seine Liste oder ein Feld wie das verwenden, das unsere API zurückgibt.
Die Liste ist außerdem auf eine Weise sauber, wie es die meisten IP-Listen nicht sind. Apples Übersicht zu Private Relay vom Dezember 2021 besagt, dass Relay-IP-Adressen "are not used or shared for any purpose other than to provide the Private Relay service" (für keinen anderen Zweck als die Bereitstellung des Private-Relay-Dienstes verwendet oder geteilt werden). Ein exakter Treffer hat also keine Kollateralschäden. Von diesen Adressen geht niemandes anderer Verkehr aus.
Was in Apples Egress-CSV steht
Die Datei liegt unter https://mask-api.icloud.com/egress-ip-ranges.csv. Wir haben sie heruntergeladen und jede Zeile mit Pythons Modul ipaddress geparst.
| Kennzahl | Wert (abgerufen am 12.10.2026, 09:40 UTC) |
|---|---|
| Zeilen (Präfixe) | 285.091 |
| IPv4-Präfixe | 41.734 |
| IPv6-Präfixe | 243.357 |
| Abgedeckte IPv4-Adressen | 105.647 |
| Unterschiedliche Ländercodes | 235 |
| Spalten | 5: Präfix, Land, Region, Stadt und ein leeres abschließendes Feld |
| Dateigröße | 12.047.231 Byte |
| Überlappende Präfixe | Keine |
Jede Zeile ist eine Geofeed-Zeile. Hier sind zwei echte Zeilen aus der Datei:
172.224.226.0/27,GB,GB-EN,London,
104.28.46.99/32,ZM,,Lusaka,
Die zweite Zeile hat eine leere Region, Ihr Parser muss also leere Felder akzeptieren. Eine Falle beim Zählen: wc -l gibt 285.090 aus, eins zu wenig, weil die Datei keinen abschließenden Zeilenumbruch hat. Zählen Sie stattdessen die geparsten Zeilen.
Die Datei regelmäßig abzurufen kostet wenig. Der Server lieferte einen ETag, "6acc40fb-b7d37f", und beantwortete unsere bedingte Anfrage mit 304 Not Modified. Apple sagt nicht, wie oft die Liste aktualisiert wird, daher spekulieren wir nicht. Wählen Sie einen Aktualisierungsrhythmus, der zu Ihnen passt.
Warum eine Regel auf ASN- oder /16-Ebene nicht ausreicht
Relay-Egress teilt sich Netze mit anderem Verkehr. In 104.28.0.0/16 stehen 19.723 von 65.536 Adressen auf Apples Liste, der Rest nicht. Apples Übersicht besagt, dass das zweite Relay "is operated by third-party partners who are some of the largest content delivery networks (CDNs) in the world" (von Drittpartnern betrieben wird, die zu den größten Content Delivery Networks (CDNs) der Welt gehören). Die drei Relays aus unserer Stichprobe liegen bei zwei davon, Cloudflare (AS13335) und Akamai (AS36183).
Wer AS13335 blockiert, trifft weit mehr als Relay-Nutzer. Wer es auf die Allowlist setzt, lässt weit mehr als Relays durch. Der Präfixabgleich ist das präzise Werkzeug, und Sie können jede IP auf VPN oder Relay prüfen, um zu sehen, wie eine einzelne Adresse eingestuft wird.
Warum eine Relay-IP keine VPN-IP ist
Private Relay verbirgt die IP des Nutzers vor der Website, belässt ihn aber in seiner tatsächlichen Region, deckt nur einen Teil des Verkehrs ab und ist auf validierte Apple-Geräte mit kostenpflichtigen Konten beschränkt. Deshalb sollte es nicht wie ein VPN bewertet werden.
Das Design verteilt das Wissen auf zwei Relays, die von verschiedenen Unternehmen betrieben werden. Apple betreibt das erste, das die Adresse des Nutzers sieht, aber nicht die Website. Ein Partner betreibt das zweite, das die Website sieht, aber nicht den Nutzer. Laut Apples Seite für Betreiber kann auf diese Weise keine einzelne Partei, Apple eingeschlossen, die Details des Surfverhaltens eines Nutzers einsehen.
| Hop | Sieht die IP des Nutzers | Sieht, welche Website |
|---|---|---|
| iPhone, iPad oder Mac des Nutzers | Ja | Ja |
| Erstes Relay (Apple) | Ja | Nein |
| Zweites Relay (ein Partnernetz, z. B. Cloudflare oder Akamai) | Nein | Ja |
| Ihr Server | Nein, nur die Relay-IP | Er ist die Website |
Vier Sätze von Apples Seite für Betreiber ändern, wie Sie diese Adressen behandeln sollten:
- Umfang. "Private Relay protects users' web browsing in Safari, DNS resolution queries, and insecure http app traffic." (Private Relay schützt das Surfen der Nutzer in Safari, DNS-Auflösungsanfragen und unverschlüsselten http-Verkehr von Apps.) Eine Relay-IP bedeutet nicht zwingend eine Safari-Sitzung. Eine App, die einfache http-Anfragen stellt, kommt auf dieselbe Weise an.
- Region. "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 bewahrt die Region, in der sich der Nutzer befindet, sodass Ihr Server der Region vertrauen kann, die der sichtbaren IP-Adresse zugeordnet ist.) Die Übersicht von 2021 ergänzt, dass es "does not allow users to represent themselves as connecting from a different country or region" (Nutzern nicht erlaubt, sich so darzustellen, als würden sie sich aus einem anderen Land oder einer anderen Region verbinden).
- Validierung. "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." (Alle Verbindungen über Private Relay prüfen, dass der Client ein iPhone, iPad oder Mac ist und der Kunde ein gültiges iCloud+-Abonnement hat.)
- Stabilität. "The relay IP address will remain stable during a browsing session while a user is interacting with your website." (Die Relay-IP-Adresse bleibt während einer Browsersitzung stabil, solange ein Nutzer mit Ihrer Website interagiert.)
Bei einem VPN kann der Nutzer jedes beliebige Land wählen, und es deckt das gesamte Gerät ab. Cloudflare ist bei seinem eigenen Produkt offen: "Technically, WARP is a VPN" (technisch gesehen ist WARP ein VPN), schrieb das Unternehmen beim Start von WARP. Auf WARP kommen wir weiter unten zurück.
Eine praktische Falle: Ein Teil des Relay-Egress liegt in Rechenzentren, sodass Hosting-Flags anschlagen können. Unsere Abfrage von 172.224.226.1, einem Relay auf Apples Liste, liefert is_hosting: true. Das ist der Grund, warum Relays als Rechenzentrums-IPs erscheinen, und warum eine pauschale Hosting-Sperre Apple-Kunden trifft.
Eine IP in Python mit Apples Liste abgleichen
Laden Sie die CSV-Datei in sortierte Integer-Bereiche, eine Liste pro IP-Version, und durchsuchen Sie sie binär. Aktualisieren Sie mit einer bedingten Anfrage und behalten Sie die letzte gute Kopie, wenn ein Download fehlschlägt oder fehlerhaft aussieht.
Dies ist genau das Skript, das wir am 12.10.2026 unter Python 3.9.6 ausgeführt haben. Es verwendet nur die Standardbibliothek.
"""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)}")
Der erste Lauf um 09:41 UTC lud die Datei herunter und gab Folgendes aus:
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 ist eine Verbindungsadresse von WARP und 102.129.235.17 ein kommerzieller VPN-Server, also sollte keine der beiden einen Treffer liefern, und keine tat es. Wir haben auch die Fehlerpfade getestet:
- Unveränderte Datei. Der zweite Lauf sendete den gespeicherten ETag, erhielt eine 304 und gab "not modified, keeping current list" aus. Das Laden und Indizieren der lokalen Datei dauerte 4,3 Sekunden. Bauen Sie den Index also einmal beim Start auf, nicht pro Anfrage.
- Fehlerhafter Download. Wir haben
URLauf einen nicht existierenden Pfad gesetzt (Apples Server antwortete mit 400). Unabhängig davon haben wir die Mindestanzahl an Zeilen über die tatsächliche angehoben. In beiden Fällen protokollierte das Skript den Fehler, löschte seine temporäre Datei und antwortete weiter aus der alten Kopie. - Gemappte Adressen.
::ffff:104.28.28.41traf seine IPv4-Zeile. Dual-Stack-Server protokollieren IPv4-Clients häufig in dieser Form.
Da die Datei keine überlappenden Präfixe enthält, genügt eine binäre Suche pro Abfrage. Der Loader lehnt jede künftige Datei mit Überlappungen ab, und die Aktualisierung greift dann auf die letzte gute Kopie zurück.
Cloudflare WARP erkennen und warum es keine Liste gibt
Sie können WARP nicht mit einer öffentlichen Liste abgleichen, weil Cloudflare keine veröffentlicht. WARP lässt sich nur von einem Anbieter identifizieren, der ihm bekannte Bereiche kennzeichnet, oder auf dem Gerät des Nutzers selbst.
Cloudflares Dokumentation zu Egress-Richtlinien sagt es klar: "Cloudflare does not publish Cloudflare One Client egress IP ranges." (Cloudflare veröffentlicht keine Egress-IP-Bereiche des Cloudflare One Client.) Die "WARP-IP-Bereiche", die in Forenthreads kursieren, sind etwas anderes. Cloudflares Firewall-Leitfaden sagt über 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." (Diese IP wird für den WARP-Client für Endverbraucher (1.1.1.1 with WARP) verwendet und ist für Zero-Trust-Dienste nicht erforderlich.) Dorthin verbindet sich die WARP-App. Ihr Webserver sieht diese Adressen nie als Client-IPs.
Erhält die Website die echte Adresse des Nutzers auf anderem Weg? Beim normalen Surfen nicht. Cloudflares WARP-FAQ sagt: "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 ersetzt Ihre ursprüngliche IP-Adresse durch eine Cloudflare-IP, die Ihren ungefähren Standort konsistent und genau wiedergibt. Das geschieht unabhängig davon, ob die Website im Cloudflare-Netz liegt oder nicht.)
Dieselbe FAQ dokumentiert zwei Lecks. "WARP does not proxy WebRTC traffic." (WARP leitet WebRTC-Verkehr nicht über den Proxy.) Und: "If you grant a website access to your microphone or camera, traffic will bypass WARP and your original IP address will be visible." (Wenn Sie einer Website Zugriff auf Mikrofon oder Kamera gewähren, umgeht der Verkehr WARP und Ihre ursprüngliche IP-Adresse wird sichtbar.)
Auf dem Gerät selbst gibt https://www.cloudflare.com/cdn-cgi/trace ein Feld warp= aus. Auf unserem Rechner, auf dem WARP nicht läuft, stand dort warp=off. Nur die Person, die diese Seite öffnet, sieht das. Es hilft also einem Supportteam bei der Fehlersuche in der Verbindung eines Kunden. Einem Server, der einen Besucher bewertet, nützt es nichts.
Unsere API gibt relay_provider: "Cloudflare WARP" für Cloudflares veröffentlichte WARP-Verbindungsbereiche zurück. Eine Abfrage von 162.159.192.1 lieferte is_relay: true, relay_provider: "Cloudflare WARP", is_hosting: true und is_anycast: true, mit einem Score von 24 und allow. Das ist die Adresse, mit der sich WARP-Apps verbinden, nicht eine, die Ihr Server als Besucher sieht.
Was unsere API für Cloudflare-Adressen zurückgibt, die nicht auf Apples Liste stehen
Egress-Adressen aus Cloudflares Privacy-Netz, die nicht auf Apples Liste stehen, werden mit "Cloudflare" gekennzeichnet, während Cloudflares veröffentlichte WARP-Verbindungsbereiche als "Cloudflare WARP" zurückkommen. Hier ist 104.28.210.10. Die Adresse liegt im selben /16 wie zwei unserer Apple-Relays, steht aber nicht auf Apples Liste. Dies ist eine gekürzte Kopie unserer Abfrage vom 12.10.2026 um 09:40 UTC, Werte unverändert:
{
"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 | Auf Apples Liste? | relay_provider | Weitere Felder | Score, Aktion, Methoden |
|---|---|---|---|---|
| 104.28.210.10 | Nein | Cloudflare | AS13335, consumer_privacy_network, is_vpn false, is_hosting false | 9, allow, relay_ip |
| 104.28.28.41 | Ja (AU, Adelaide) | iCloud Private Relay | AS13335, consumer_privacy_network | 9, allow, relay_ip |
| 162.159.192.1 | Nein (WARP-Verbindungsadresse) | Cloudflare WARP | is_hosting true, is_anycast true | 24, allow, datacenter_ip + no_ptr_datacenter + relay_ip |
| 102.129.235.17 (VPN, zum Vergleich) | Nein | keiner | is_vpn true, is_anonymous true | 92, block, known_vpn_server + openvpn_open + ipsec_open |
Lesen Sie "Cloudflare" als "eine Egress-Adresse aus Cloudflares Privacy-Netz für Endverbraucher, die nicht Apple zugeordnet ist". Es bedeutet keinen bestätigten WARP-Nutzer, und das behaupten wir auch nicht. Unsere API-Referenz führt derzeit nur zwei Werte für relay_provider auf, "iCloud Private Relay" und "Cloudflare WARP", dieser dritte Wert ist also bislang nicht dokumentiert. Wir haben das Backend-Team gebeten, ihn zu dokumentieren.
Der eigentliche Erkenntnisgewinn steckt in den ersten beiden Zeilen. Innerhalb eines Cloudflare-/16 trennt der exakte CSV-Abgleich Apples Relay (104.28.28.41) von anderem Privacy-Egress von Cloudflare (104.28.210.10). Unser Label stimmt in beiden Fällen mit Apples Liste überein. Beide erhalten den Score 9 und allow, Ihre Richtlinie ist also in beiden Fällen dieselbe. Auch die VPN-Zeile hat keinen Anbieternamen: Unsere Probes haben sie erkannt, aber sie steht auf keiner Anbieterliste, die wir führen. Genau deshalb kann ein VPN unbenannt bleiben.
Private Relay und WARP im Vergleich
| Frage | iCloud Private Relay | Cloudflare WARP |
|---|---|---|
| Wer betreibt es | Apple, mit Partnernetzen für das zweite Relay | Cloudflare |
| Wer kann es nutzen | iCloud+-Abonnenten auf validiertem iPhone, iPad oder Mac | Jeder, der die kostenlose App 1.1.1.1 installiert |
| Was es abdeckt | Safari, DNS-Anfragen, unverschlüsselter http-Verkehr von Apps | Den Verkehr des Geräts, außer WebRTC und Websites mit Zugriff auf Kamera oder Mikrofon |
| Öffentliche Egress-Liste | Ja, Apples CSV | Nein |
| Standort | Region bleibt erhalten; standardmäßig grobe Stadt, auf Wunsch des Nutzers weiter gefasst | Eine Cloudflare-IP, die den ungefähren Standort des Nutzers wiedergibt |
| Wie ein Server es erkennt | Exakter Abgleich mit Apples CSV oder Relay-Flag eines Anbieters | Nur über das Label eines Anbieters |
Beide können in AS13335 liegen, das Netz allein trennt also keines von beiden.
Was unsere Abfragen für Relay-IPs zurückgeben
In unseren Abfragen kommen Private-Relay-Adressen als Relays zurück, nicht als anonym oder VPN, und landen bei allow, sofern keine anderen Hinweise vorliegen. Wir haben 104.28.46.99 durchgängig verfolgt. Apples Zeile sagt Sambia, Lusaka. Das ist die Anfrage, wie Sie sie mit einem Schlüssel senden würden:
curl https://api.geoiphub.com/v1/lookup/104.28.46.99 \
-H "x-api-key: YOUR_API_KEY"
Wir haben sie am 12.10.2026 um 09:40 UTC ohne Schlüssel ausgeführt, was die API für geringe Nutzung erlaubt. Hier ist eine gekürzte Kopie der Antwort, Werte unverändert:
{
"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"]
}
}
Das Relay ist benannt, is_vpn und is_anonymous sind false, und scoring.detection_methods zeigt das eine Signal, das angeschlagen hat: relay_ip. Der Score ist 9, also lautet die Aktion allow. Die Geolokalisierung sagt Angola, was Apples Zeile widerspricht; darauf gehen wir im nächsten Abschnitt ein. Die Entscheidung für diese Adresse lautet: zulassen, die Rate wie bei einer geteilten Adresse begrenzen und den Standort aus Apples Zeile übernehmen.
Hier die anderen Relays neben einem echten VPN:
| IP | Apples Zeile | Unser Ergebnis am 12.10.2026 |
|---|---|---|
| 172.224.226.1 | GB, GB-EN, London | AS36183 Akamai, asn_type hosting; is_relay true, iCloud Private Relay, is_hosting true; Score 24, allow; datacenter_ip, no_ptr_datacenter, relay_ip; Geo GB, London |
| 104.28.28.41 | AU, AU-SA, Adelaide | AS13335; is_relay true, iCloud Private Relay; Score 9, allow; relay_ip; Geo AU, Sydney, 0.8 |
| 102.129.235.17 (VPN) | Nicht auf der Liste | AS834 IPXO; is_vpn true, is_anonymous true; Score 92, block; known_vpn_server, openvpn_open, ipsec_open |
Das Relay-Flag senkt den Score nicht. Es erhöht ihn. Bei 104.28.46.99 ist relay_ip der einzige Eintrag in detection_methods und macht damit den gesamten Score von 9 aus. 172.224.226.1 erreicht 24, weil zusätzlich zwei Rechenzentrumssignale angeschlagen haben, womit die Adresse einen Punkt unter der allow-Grenze von 25 liegt. Relays landen also bei allow, sofern keine anderen Hinweise vorliegen. Spricht etwas anderes gegen die Adresse, etwa ein Eintrag auf einer Missbrauchsliste, steigt der Score und die Aktion kann zu review wechseln. Die Seite wie der Score entsteht listet die Signale auf.
Die API kennzeichnet das Relay. Apples CSV ist Ihre unabhängige Gegenprobe, und der Matcher oben führt sie ganz ohne uns aus. Ein Relay so zu bewerten, als wäre es ein VPN, ist der klassische Fall bei Fehlalarmen in der VPN-Erkennung.
Warum Private-Relay-Nutzer in der falschen Stadt erscheinen, auch in unseren Daten
Eine Relay-IP verspricht nur die Region des Nutzers und standardmäßig eine grobe Stadt. Der einzige maßgebliche Standort für eine Relay-IP ist Apples eigene Zeile, und unsere Datenbank stimmt nicht immer damit überein.
Apples Seite für Betreiber sagt, die Relay-IP "accurately represents the client's coarse city-level location by default" (gibt standardmäßig den groben Standort des Clients auf Stadtebene genau wieder). Nutzer können das ausweiten. Apples aktuelles iPhone-Benutzerhandbuch nennt zwei Optionen für den IP-Adressstandort, "Maintain General Location" (Allgemeinen Standort beibehalten) und "Use Country and Time Zone" (Land und Zeitzone verwenden). Die Übersicht von 2021 beschreibt sie. Die erste wählt Adressen, die "map to a roughly city-level area consistent with where the user is actually connecting from" (einem Gebiet etwa auf Stadtebene zugeordnet sind, das dem tatsächlichen Verbindungsort des Nutzers entspricht). Die zweite wählt Adressen "across a broader, more regional area" (aus einem breiteren, eher regionalen Gebiet), und "All Relay IP addresses will still map to the user's original country and time zone." (Alle Relay-IP-Adressen sind weiterhin dem ursprünglichen Land und der Zeitzone des Nutzers zugeordnet.)
Wir haben unsere Geolokalisierung mit Apples Zeilen für die drei Relays verglichen:
| IP | Apples Zeile | Unsere Geodaten | Übereinstimmung? |
|---|---|---|---|
| 104.28.46.99 | ZM, Lusaka | AO, Luanda (geo_confidence 0.8) | Nein, anderes Land |
| 104.28.28.41 | AU, AU-SA, Adelaide | AU, Sydney (geo_confidence 0.8) | Land ja, Stadt nein |
| 172.224.226.1 | GB, GB-EN, London | GB, London | Ja |
Zwei von drei weichen ab. Sambia statt Angola ist ein Fehler auf Länderebene, genau die Art, die eine Lizenz- oder Sanktionsregel auslöst. Adelaide statt Sydney trifft das Land, aber nicht die Stadt. Drei IPs sind kein Benchmark, aber sie reichen für eine Regel: Übernehmen Sie bei Relay-IPs den Standort aus Apples Zeile, nicht aus einer Geodatenbank, unsere eingeschlossen. Entscheiden Sie auf Ebene von Land oder Region und behandeln Sie die Stadt als Hinweis. Wir haben beide Abweichungen an unser Backend-Team gemeldet.
Sollten Sie Private Relay oder WARP blockieren? Lassen Sie sie durch und bewerten Sie die Sitzung
Nein. Apple validiert jeden Relay-Client und sagt, dass IP-basierte Betrugsregeln "might need to be adjusted" (möglicherweise angepasst werden müssen). Lassen Sie Private-Relay-Verkehr also zu, begrenzen Sie die Rate wie bei einer geteilten Carrier-Adresse und verlangen Sie eine zusätzliche Prüfung nur, wenn andere Hinweise auf ein Risiko deuten.
Apples Seite für Betreiber ist bei beiden Punkten deutlich:
"Traditional fraud detection that relies on IP addresses might need to be adjusted to ensure legitimate users aren't impacted." (Herkömmliche Betrugserkennung, die sich auf IP-Adressen stützt, muss möglicherweise angepasst werden, damit legitime Nutzer nicht beeinträchtigt werden.)
"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." (Behandeln Sie diese Adressen am besten wie größere Carrier-Grade-NAT- oder Unternehmens-IP-Adressen, um dieser Art von Verkehr besser gerecht zu werden, da viele Private-Relay-Nutzer derselben Relay-IP-Adresse zugeordnet sein können.)
Apple bietet auch einen Ersatz für die Challenge-Seite an. Das Unternehmen merkt an, dass "Common mitigations include CAPTCHAs or blocking traffic altogether" (übliche Gegenmaßnahmen CAPTCHAs oder das vollständige Blockieren von Verkehr sind), und sagt "Every Apple device running iOS 16, iPadOS 16, or macOS Monterey and later supports Private Access Tokens" (jedes Apple-Gerät mit iOS 16, iPadOS 16 oder macOS Monterey und neuer unterstützt Private Access Tokens). Damit kann ein Server ein legitimes Gerät prüfen, ohne den Nutzer zu identifizieren.
Können Betrüger Relays nutzen? Ja, aber Private Relay setzt ein Apple-Gerät und ein kostenpflichtiges iCloud+-Konto voraus. Apple sagt, die Validierung "is designed to ensure that only valid Apple devices and accounts in good standing are allowed to use Private Relay" (soll sicherstellen, dass nur gültige Apple-Geräte und Konten mit gutem Status Private Relay nutzen dürfen). Das macht es zu einem teuren Weg, Konten in großem Stil anzulegen. WARP ist eine kostenlose App, geben Sie bei WARP-Sitzungen Ihren anderen Signalen also etwas mehr Gewicht, statt zu blockieren. Schwierigere Probleme beim Verbergen von IPs liegen anderswo, etwa bei mobilen Proxys.
Ein Detail für Ihr Rate Limiting: Apples Hinweis zu Carrier-Grade-NAT bezieht sich darauf, wie Sie die Adresse behandeln, nicht auf ein Flag. Unser threat.is_cgnat war bei allen drei Relay-Abfragen false. Knüpfen Sie die Behandlung geteilter Adressen stattdessen an is_relay oder den CSV-Abgleich. Um eine Adresse aus Ihren eigenen Logs zu prüfen, fügen Sie sie in das kostenlose IP-Lookup-Tool ein.
| Was Sie sehen | Aktion | Warum |
|---|---|---|
| IP in Apples CSV oder is_relay true, keine weiteren Risikohinweise | Zulassen; Rate pro Konto oder Sitzung begrenzen, nicht pro IP | Apple validiert Gerät und Konto, und viele Nutzer teilen sich eine Relay-IP |
| Relay- oder WARP-IP plus ein riskantes Kontosignal (neues Konto, Zahlungsland außerhalb der Region der IP, hohe Registrierungsrate) | Zusätzliche Prüfung: ein Private Access Token, wo unterstützt, sonst 2FA oder E-Mail-Bestätigung, keine CAPTCHA-Wand | Die IP liefert keinen Hinweis; das Kontosignal schon |
| Relay-IP, die zusätzlich bei review landet, etwa weil sie auf einer Missbrauchsliste steht | Prüfen | Dieser Hinweis betrifft die Adresse, nicht das Relay |
| Als WARP gekennzeichnete IP | Zulassen und die Sitzung bewerten | Kostenlos und verbreitet; verbirgt den Nutzer, beweist aber keine Absicht |
| Standortregeln (Lizenzen, Steuern) für Relay-Verkehr | Auf Ebene von Land oder Region anhand von Apples Zeile entscheiden, nie nach Stadt | Apple bewahrt die Region; die Stadt ist grob oder je nach Einstellung weiter gefasst |
Drei Prüfungen, die Sie diese Woche auf Ihren eigenen Logs ausführen sollten:
- Zählen Sie die abgewiesenen Relay-Nutzer. Verknüpfen Sie die Registrierungen, Logins und Ablehnungen der letzten 30 Tage mit dem Matcher oben mit Apples CSV. Wie viele Relay-Nutzer haben Ihre Regeln abgelehnt oder einer Challenge unterzogen?
- Finden Sie ASN- und Hosting-Sperren. Durchsuchen Sie Ihre Regeln nach AS13335, AS36183 oder
is_hosting. 172.224.226.1 ist ein Relay mitis_hosting: true, eine Hosting-Sperre trifft also Relay-Nutzer. - Prüfen Sie Limits pro IP und Geofences auf Stadtebene. Apple rät, Relay-IPs wie Carrier-Grade-NAT zu behandeln. Ein Limit pro IP, das für einen Haushalt bemessen ist, bremst also viele Nutzer aus, und ein Geofence auf Stadtebene schlägt bei einem groben Standort fehl.
Häufig gestellte Fragen
Woran erkenne ich, ob iCloud Private Relay aktiviert ist?
Öffnen Sie auf dem iPhone die Einstellungen, tippen Sie auf Ihren Namen, dann auf iCloud und dann auf Privat-Relay. Als Betreiber einer Website sehen Sie die Einstellung nicht, nur die IP: Steht sie auf Apples Egress-Liste, kam die Anfrage über Private Relay.
Ist iCloud Private Relay ein VPN?
Nein. Es deckt nur Safari, DNS und unverschlüsselten http-Verkehr von Apps ab, belässt den Nutzer in seinem eigenen Land und seiner Region und ist auf validierte Apple-Geräte mit iCloud+ beschränkt.
Verbirgt Cloudflare WARP Ihre IP-Adresse?
Ja. Laut Cloudflare ersetzt WARP die ursprüngliche IP durch eine Cloudflare-IP, unabhängig davon, ob die Website bei Cloudflare liegt, mit Ausnahme von WebRTC-Verkehr und Websites, denen Zugriff auf Kamera oder Mikrofon gewährt wurde.
Wo finde ich die Liste der IP-Adressen von iCloud Private Relay?
Apple veröffentlicht sie unter mask-api.icloud.com/egress-ip-ranges.csv. Am 12.10.2026 enthielt sie 285.091 IPv4- und IPv6-Präfixe in 235 Ländercodes.
Kann eine Website die echte IP hinter Private Relay sehen?
Konstruktionsbedingt nicht. Die Website sieht nur die Relay-IP, und nur Apples erstes Relay sieht die eigene Adresse des Nutzers.
Sollte ich iCloud Private Relay blockieren?
Nein. Apple weist darauf hin, dass IP-basierte Betrugsregeln für Relay-Nutzer möglicherweise angepasst werden müssen. Lassen Sie den Verkehr zu, begrenzen Sie die Rate wie bei Carrier-Grade-NAT und verlangen Sie eine zusätzliche Prüfung nur bei anderen Risikosignalen.
Das Team hinter der GeoIPHub-API
Verfasst vom GeoIPHub-Team, den Menschen, die die GeoIPHub-API für IP-Intelligence und ihren Scanner entwickeln. Entwürfe entstehen mit KI-Unterstützung und werden vom Team redigiert; API-Beispiele sind echte Abfragen gegen die Live-API, sofern nicht als illustrativ gekennzeichnet.
Betrugsprävention