Inteligencia IPDetecta iCloud Private Relay y Cloudflare WARP, y déjalos pasar
Detecta iCloud Private Relay con la lista de salidas de 285.091 filas de Apple y consultas en vivo a la API, entiende por qué Cloudflare WARP no tiene lista pública y deja pasar a los usuarios de relay.
Descargamos la lista de Apple a las 09:40 UTC del 12 de octubre de 2026. Contenía 285.091 prefijos, 41.734 IPv4 y 243.357 IPv6, de 235 códigos de país. Dentro del 104.28.0.0/16 de Cloudflare, 19.723 de las 65.536 direcciones están en ella. Las otras 45.813 no, así que una regla escrita contra ese bloque, o contra toda la red de Cloudflare, no puede distinguir a un usuario de Private Relay de cualquier otra cosa enrutada por ahí.
A continuación analizamos el archivo de Apple y ofrecemos un comparador en Python probado para IPv4 e IPv6. Explicamos lo que se puede y no se puede saber sobre WARP, y mostramos consultas reales de direcciones de relay, incluidos dos casos en los que nuestra propia geolocalización discrepa de la de Apple. El artículo termina con una tabla de políticas. Para el conjunto más amplio de señales de anonimizadores, empieza por cómo funciona la detección de VPN y proxies.
Cómo detectar iCloud Private Relay: compara con la propia lista de Apple
Apple publica todos los prefijos de salida de Private Relay en un único CSV, así que una coincidencia exacta te indica que una IP es una salida de relay. La guía de Apple para operadores de redes y servidores remite a los servidores a esa lista, o a una marca del proveedor:
"Tu servidor puede reconocer el tráfico de Private Relay usando la lista anterior de direcciones IP de Private Relay o comprobando cómo lo clasifica tu proveedor de base de datos de geo IP."
La misma página nombra los campos que hay que buscar: "Otros campos relevantes pueden incluir: 'is_relay', 'is_hosting', 'privacy_service' o 'privacy_proxy'." Dicho de otro modo, Apple espera que uses su lista o un campo como el que devuelve nuestra API.
La lista, además, está limpia de una forma en que la mayoría de las listas de IP no lo están. La visión general de Private Relay de diciembre de 2021 de Apple afirma que las direcciones IP del relay "no se usan ni se comparten para ningún otro fin que prestar el servicio Private Relay". Así que una coincidencia exacta no tiene daños colaterales. El tráfico de nadie más sale desde esas direcciones.
Qué contiene el CSV de salidas de Apple
El archivo está en https://mask-api.icloud.com/egress-ip-ranges.csv. Lo descargamos y analizamos cada fila con el módulo ipaddress de Python.
| Medida | Valor (descargado el 12-10-2026, 09:40 UTC) |
|---|---|
| Filas (prefijos) | 285.091 |
| Prefijos IPv4 | 41.734 |
| Prefijos IPv6 | 243.357 |
| Direcciones IPv4 cubiertas | 105.647 |
| Códigos de país distintos | 235 |
| Columnas | 5: prefijo, país, región, ciudad y un campo final vacío |
| Tamaño del archivo | 12.047.231 bytes |
| Prefijos solapados | Ninguno |
Cada fila es una línea de geofeed. Estas son dos filas reales del archivo:
172.224.226.0/27,GB,GB-EN,London,
104.28.46.99/32,ZM,,Lusaka,
La segunda fila tiene la región vacía, así que tu parser tiene que aceptar campos en blanco. Una trampa al contar: wc -l imprime 285.090, uno menos, porque el archivo no termina en salto de línea. Cuenta las filas analizadas.
Consultar el archivo periódicamente es barato. El servidor devolvió un ETag, "6acc40fb-b7d37f", y respondió a nuestra petición condicional con 304 Not Modified. Apple no dice con qué frecuencia actualiza la lista, así que no lo vamos a adivinar. Elige un calendario de actualización que te convenga.
Por qué no basta una regla por ASN o por /16
Las salidas del relay comparten redes con otro tráfico. En 104.28.0.0/16, 19.723 de 65.536 direcciones están en la lista de Apple, y el resto no. La visión general de Apple dice que el segundo relay "lo operan socios externos que son algunas de las mayores redes de distribución de contenidos (CDN) del mundo". Los tres relays que muestreamos están en dos de ellas, Cloudflare (AS13335) y Akamai (AS36183).
Bloquear AS13335 afecta a mucho más que a los usuarios de relay. Ponerlo en la lista de permitidos deja pasar mucho más que relays. La coincidencia por prefijo es la herramienta precisa, y puedes comprobar si cualquier IP es VPN o relay para ver cómo se clasifica una dirección concreta.
Por qué una IP de relay no es una IP de VPN
Private Relay oculta la IP del usuario al sitio, pero lo mantiene en su región real, solo cubre parte del tráfico y está limitado a dispositivos Apple validados con cuentas de pago. Por eso no debería puntuarse como una VPN.
El diseño reparte el conocimiento entre dos relays gestionados por empresas distintas. Apple gestiona el primero, que ve la dirección del usuario pero no el sitio. Un socio gestiona el segundo, que ve el sitio pero no al usuario. La página de Apple para operadores dice que, de este modo, ninguna parte, Apple incluida, puede ver los detalles de la navegación de un usuario.
| Salto | Ve la IP del usuario | Ve qué sitio |
|---|---|---|
| iPhone, iPad o Mac del usuario | Sí | Sí |
| Primer relay (Apple) | Sí | No |
| Segundo relay (una red socia, p. ej. Cloudflare o Akamai) | No | Sí |
| Tu servidor | No, solo la IP del relay | Es el sitio |
Cuatro frases de la página de Apple para operadores cambian cómo deberías tratar estas direcciones:
- Alcance. "Private Relay protege la navegación web de los usuarios en Safari, las consultas de resolución DNS y el tráfico http no seguro de las apps." Una IP de relay no implica una sesión de Safari. Una app que hace peticiones http sin cifrar llega de la misma forma.
- Región. "Private Relay conserva la región en la que está el usuario, así que tu servidor puede fiarse de la región asignada a la dirección IP que ve." La visión general de 2021 añade que "no permite a los usuarios presentarse como si se conectaran desde otro país o región".
- Validación. "Todas las conexiones que usan Private Relay validan que el cliente es un iPhone, iPad o Mac y que el cliente tiene una suscripción válida a iCloud+."
- Estabilidad. "La dirección IP del relay se mantendrá estable durante una sesión de navegación mientras el usuario interactúa con tu sitio web."
Una VPN permite al usuario elegir cualquier país y cubre todo el dispositivo. Cloudflare es franca sobre su propio producto. "Técnicamente, WARP es una VPN", escribió cuando lanzó WARP. Volvemos a WARP más abajo.
Una trampa práctica: algunas salidas del relay están en centros de datos, así que pueden activarse las marcas de hosting. Nuestra consulta de 172.224.226.1, un relay de la lista de Apple, devuelve is_hosting: true. Esa es la razón por la que los relays aparecen como IP de centros de datos, y por la que un bloqueo general del hosting atrapa a clientes de Apple.
Comparar una IP con la lista de Apple en Python
Carga el CSV en rangos enteros ordenados, una lista por versión de IP, y busca en ellos con búsqueda binaria. Actualiza con una petición condicional y conserva la última copia buena si una descarga falla o parece incorrecta.
Este es el script exacto que ejecutamos el 12 de octubre de 2026, con Python 3.9.6. Solo usa la biblioteca estándar.
"""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 primera ejecución, a las 09:41 UTC, descargó el archivo e imprimió:
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 es una dirección de conexión de WARP y 102.129.235.17 es un servidor VPN comercial, así que ninguna debería coincidir, y ninguna coincidió. También probamos los caminos de fallo:
- Archivo sin cambios. La segunda ejecución envió el ETag guardado, recibió un 304 e imprimió "not modified, keeping current list". Cargar e indexar el archivo local tardó 4,3 segundos, así que construye el índice una sola vez al arrancar, no en cada petición.
- Descarga defectuosa. Apuntamos
URLa una ruta que no existe (el servidor de Apple respondió 400). Por separado, subimos el número mínimo de filas por encima del real. En ambos casos el script registró el fallo, borró su archivo temporal y siguió respondiendo con la copia anterior. - Direcciones mapeadas.
::ffff:104.28.28.41coincidió con su fila IPv4. Los servidores de doble pila suelen registrar los clientes IPv4 de esa forma.
Como el archivo no tiene prefijos solapados, basta con una búsqueda binaria por consulta. El cargador rechaza cualquier archivo futuro que tenga solapamientos, y en ese caso la actualización recurre a la última copia buena.
Cómo detectar Cloudflare WARP, y por qué no hay lista
No puedes comparar WARP con una lista pública, porque Cloudflare no la publica. WARP solo puede identificarlo un proveedor que etiquete los rangos que conoce, o el propio dispositivo del usuario.
La documentación de políticas de salida de Cloudflare lo dice claramente: "Cloudflare no publica los rangos de IP de salida del Cloudflare One Client." Los "rangos de IP de WARP" que circulan en los hilos de los foros son otra cosa. La guía de firewall de Cloudflare dice de 162.159.192.0/24: "Esta IP la usa el cliente WARP de consumo (1.1.1.1 con WARP) y no es necesaria para los servicios Zero Trust." Ahí es donde se conecta la app WARP. Tu servidor web nunca ve esas direcciones como IP de clientes.
¿Recibe el sitio la dirección real del usuario por otra vía? No en la navegación normal. Las preguntas frecuentes de WARP de Cloudflare dicen: "1.1.1.1 + WARP sustituye tu dirección IP original por una IP de Cloudflare que representa de forma coherente y precisa tu ubicación aproximada. Esto ocurre tanto si el sitio está en la red de Cloudflare como si no."
Las mismas preguntas frecuentes documentan dos fugas. "WARP no hace de proxy del tráfico WebRTC." Y: "Si concedes a un sitio web acceso a tu micrófono o tu cámara, el tráfico se saltará WARP y tu dirección IP original será visible."
En el propio dispositivo, https://www.cloudflare.com/cdn-cgi/trace imprime un campo warp=. En nuestra máquina, que no usa WARP, mostraba warp=off. Solo lo ve la persona que abre esa página, así que ayuda a un equipo de soporte que depura la conexión de un cliente. No sirve de nada a un servidor que puntúa a un visitante.
Nuestra API devuelve relay_provider: "Cloudflare WARP" para los rangos de conexión de WARP publicados por Cloudflare. Una consulta de 162.159.192.1 devolvió is_relay: true, relay_provider: "Cloudflare WARP", is_hosting: true e is_anycast: true, con una puntuación de 24 y allow. Esa es la dirección a la que se conectan las apps WARP, no una que tu servidor vaya a ver como visitante.
Qué devuelve nuestra API para direcciones de Cloudflare que no están en la lista de Apple
Las direcciones de salida de la red de privacidad de Cloudflare que no están en la lista de Apple vuelven con la etiqueta "Cloudflare", mientras que los rangos de conexión de WARP publicados por Cloudflare vuelven como "Cloudflare WARP". Este es el caso de 104.28.210.10. Está en el mismo /16 que dos de nuestros relays de Apple, pero no figura en la lista de Apple. Es una copia recortada de nuestra consulta a las 09:40 UTC del 12 de octubre de 2026, con los valores sin editar:
{
"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 | ¿En la lista de Apple? | relay_provider | Otros campos | Puntuación, acción, métodos |
|---|---|---|---|---|
| 104.28.210.10 | No | Cloudflare | AS13335, consumer_privacy_network, is_vpn false, is_hosting false | 9, allow, relay_ip |
| 104.28.28.41 | Sí (AU, Adelaida) | iCloud Private Relay | AS13335, consumer_privacy_network | 9, allow, relay_ip |
| 162.159.192.1 | No (dirección de conexión de WARP) | Cloudflare WARP | is_hosting true, is_anycast true | 24, allow, datacenter_ip + no_ptr_datacenter + relay_ip |
| 102.129.235.17 (VPN, para comparar) | No | none | is_vpn true, is_anonymous true | 92, block, known_vpn_server + openvpn_open + ipsec_open |
Interpreta "Cloudflare" como "una dirección de salida de privacidad para consumidores de Cloudflare no atribuida a Apple". No significa un usuario de WARP confirmado, y no afirmamos que lo sea. Nuestra referencia de la API solo enumera hoy dos valores de relay_provider, "iCloud Private Relay" y "Cloudflare WARP", así que este tercer valor no está documentado por ahora. Hemos pedido al equipo de backend que lo documente.
Lo útil está en las dos primeras filas. Dentro de un mismo /16 de Cloudflare, la coincidencia exacta con el CSV separa el relay de Apple (104.28.28.41) de otras salidas de privacidad de Cloudflare (104.28.210.10). Nuestra etiqueta coincide con la lista de Apple en ambos casos. Las dos puntúan 9 y allow, así que tu política es la misma en cualquier caso. La fila de la VPN tampoco tiene nombre de proveedor: nuestros sondeos la detectaron, pero no está en ninguna lista de proveedores que tengamos, que es por qué una VPN puede quedarse sin nombre.
Private Relay y WARP lado a lado
| Pregunta | iCloud Private Relay | Cloudflare WARP |
|---|---|---|
| Quién lo gestiona | Apple, con redes socias para el segundo relay | Cloudflare |
| Quién puede usarlo | Suscriptores de iCloud+ en un iPhone, iPad o Mac validado | Cualquiera que instale la app gratuita 1.1.1.1 |
| Qué cubre | Safari, consultas DNS, tráfico http no seguro de las apps | El tráfico del dispositivo, salvo WebRTC y los sitios con acceso a la cámara o al micrófono |
| Lista pública de salidas | Sí, el CSV de Apple | No |
| Ubicación | Se conserva la región; ciudad aproximada por defecto, más amplia si el usuario lo elige | Una IP de Cloudflare que representa la ubicación aproximada del usuario |
| Cómo lo identifica un servidor | Coincidencia exacta con el CSV de Apple, o la marca de relay de un proveedor | Solo la etiqueta de un proveedor |
Ambos pueden estar en AS13335, así que la red por sí sola no separa a ninguno.
Qué devuelven nuestras consultas para IP de relay
En nuestras consultas, las direcciones de Private Relay vuelven como relays, no como anónimas ni como VPN, y quedan en allow salvo que haya otras evidencias. Seguimos 104.28.46.99 de principio a fin. La fila de Apple dice Zambia, Lusaka. Esta es la petición, tal como la enviarías con una clave:
curl https://api.geoiphub.com/v1/lookup/104.28.46.99 \
-H "x-api-key: YOUR_API_KEY"
La ejecutamos sin clave a las 09:40 UTC del 12 de octubre de 2026, algo que la API permite para un uso ligero. Esta es una copia recortada de la respuesta, con los valores sin editar:
{
"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"]
}
}
El relay tiene nombre, is_vpn e is_anonymous son false, y scoring.detection_methods muestra la única señal que se activó: relay_ip. La puntuación es 9, así que la acción es allow. La geolocalización dice Angola, algo que contradice la fila de Apple; lo tratamos en la siguiente sección. La decisión para esta dirección es permitirla, limitar su tasa como dirección compartida y tomar su ubicación de la fila de Apple.
Estos son los otros relays junto a una VPN real:
| IP | Fila de Apple | Nuestro resultado del 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; puntuación 24, allow; datacenter_ip, no_ptr_datacenter, relay_ip; geo GB, Londres |
| 104.28.28.41 | AU, AU-SA, Adelaida | AS13335; is_relay true, iCloud Private Relay; puntuación 9, allow; relay_ip; geo AU, Sídney, 0,8 |
| 102.129.235.17 (VPN) | No está en la lista | AS834 IPXO; is_vpn true, is_anonymous true; puntuación 92, block; known_vpn_server, openvpn_open, ipsec_open |
La marca de relay no reduce la puntuación. La aumenta. En 104.28.46.99, relay_ip es la única entrada de detection_methods, así que explica toda la puntuación de 9. 172.224.226.1 puntúa 24 porque también se activaron dos señales de centro de datos, lo que la deja a un punto del límite de allow, que es 25. Así que los relays quedan en allow salvo que haya otras evidencias. Si algo más cuenta en contra de la dirección, como una entrada en una lista de abuso, la puntuación sube y la acción puede pasar a review. La página sobre cómo se construye la puntuación enumera las señales.
La API etiqueta el relay. El CSV de Apple es tu comprobación independiente, y el comparador de arriba la ejecuta sin depender de nosotros. Puntuar un relay como si fuera una VPN es el caso clásico de los falsos positivos en la detección de VPN.
Por qué los usuarios de Private Relay muestran una ciudad incorrecta, también en nuestros datos
Una IP de relay solo garantiza la región del usuario y, por defecto, una ciudad aproximada. La única ubicación fiable para una IP de relay es la propia fila de Apple, y nuestra base de datos no siempre coincide con ella.
La página de Apple para operadores dice que la IP del relay "representa con precisión, por defecto, la ubicación aproximada del cliente a nivel de ciudad". Los usuarios pueden ampliarla. La Guía del usuario del iPhone actual de Apple enumera dos opciones de Ubicación de la dirección IP: "Mantener ubicación general" y "Usar país y zona horaria". La visión general de 2021 las describe. La primera elige direcciones que "corresponden aproximadamente a un área a nivel de ciudad coherente con el lugar desde el que el usuario se está conectando realmente". La segunda elige direcciones "en un área más amplia, más regional", y "todas las direcciones IP del relay seguirán correspondiendo al país y la zona horaria originales del usuario".
Comparamos nuestra geolocalización con las filas de Apple para los tres relays:
| IP | Fila de Apple | Nuestra geolocalización | ¿Coinciden? |
|---|---|---|---|
| 104.28.46.99 | ZM, Lusaka | AO, Luanda (geo_confidence 0,8) | No, país distinto |
| 104.28.28.41 | AU, AU-SA, Adelaida | AU, Sídney (geo_confidence 0,8) | País sí, ciudad no |
| 172.224.226.1 | GB, GB-EN, Londres | GB, Londres | Sí |
Dos de las tres discrepan. Zambia frente a Angola es un error a nivel de país, del tipo que hace saltar una regla de licencias o de sanciones. Adelaida frente a Sídney acierta el país y falla la ciudad. Tres IP no son un benchmark, pero bastan para fijar una regla: para las IP de relay, toma la ubicación de la fila de Apple, no de ninguna base de datos de geolocalización, incluida la nuestra. Decide por país o región y trata la ciudad como una pista. Hemos comunicado ambas discrepancias a nuestro equipo de backend.
¿Deberías bloquear Private Relay o WARP? Déjalos pasar y puntúa la sesión
No. Apple valida a todos los clientes del relay y dice que las reglas antifraude basadas en IP "podrían necesitar ajustes", así que permite el tráfico de Private Relay, limita su tasa como si fuera una dirección compartida de operador y refuerza la verificación solo cuando otras evidencias apunten a un riesgo.
La página de Apple para operadores es directa en ambos puntos:
"La detección de fraude tradicional que se basa en direcciones IP podría necesitar ajustes para garantizar que los usuarios legítimos no se vean afectados."
"Considera tratar estas direcciones como direcciones de NAT a nivel de operador o direcciones IP empresariales de mayor tamaño para tener mejor en cuenta este tipo de tráfico, ya que a muchos usuarios de Private Relay se les puede asignar una misma dirección IP de relay."
Apple también ofrece una alternativa a la página de desafío. Señala que "las mitigaciones habituales incluyen CAPTCHAs o bloquear el tráfico por completo", y dice que "todos los dispositivos Apple con iOS 16, iPadOS 16 o macOS Monterey y versiones posteriores admiten Private Access Tokens", que permiten a un servidor comprobar que se trata de un dispositivo legítimo sin identificar al usuario.
¿Pueden los defraudadores usar relays? Pueden, pero Private Relay necesita un dispositivo Apple y una cuenta de pago de iCloud+. Apple dice que la validación "está diseñada para garantizar que solo los dispositivos Apple válidos y las cuentas en regla puedan usar Private Relay". Eso lo convierte en una forma cara de crear cuentas en masa. WARP es una app gratuita, así que da un poco más de peso a tus otras señales en las sesiones de WARP, no un bloqueo. Los problemas más difíciles de ocultación de IP están en otra parte, como los proxies móviles.
Un detalle para tu limitador de tasa: el consejo de Apple sobre el NAT a nivel de operador se refiere a cómo tratas la dirección, no a una marca. Nuestro threat.is_cgnat fue false en las tres consultas de relay. Basa el tratamiento de direcciones compartidas en is_relay o en la coincidencia con el CSV. Para comprobar una dirección de tus propios logs, pégala en la herramienta gratuita de consulta de IP.
| Lo que ves | Acción | Por qué |
|---|---|---|
| IP en el CSV de Apple o is_relay true, sin otras evidencias de riesgo | Permitir; limitar la tasa por cuenta o por sesión, no por IP | Apple valida el dispositivo y la cuenta, y muchos usuarios comparten una misma IP de relay |
| IP de relay o de WARP más una señal de riesgo en la cuenta (cuenta nueva, país de pago fuera de la región de la IP, velocidad de registros) | Reforzar la verificación: un Private Access Token donde se admita; si no, 2FA o una comprobación por email, no un muro de CAPTCHA | La IP no aporta evidencias; la señal de la cuenta sí |
| IP de relay que además cae en review, por ejemplo porque está en una lista de abuso | Revisar | Esa evidencia se refiere a la dirección, no al relay |
| IP etiquetada como WARP | Permitir y puntuar la sesión | Es gratuito y habitual; oculta al usuario pero no demuestra intención |
| Reglas de ubicación (licencias, impuestos) sobre tráfico de relay | Decidir por país o región según la fila de Apple, nunca por ciudad | Apple conserva la región; la ciudad es aproximada o más amplia según el ajuste |
Tres comprobaciones para hacer en tus propios logs esta semana:
- Cuenta los usuarios de relay que has rechazado. Cruza los registros, inicios de sesión y rechazos de los últimos 30 días con el CSV de Apple usando el comparador de arriba. ¿A cuántos usuarios de relay han rechazado o desafiado tus reglas?
- Busca bloqueos por ASN y por hosting. Busca en tus reglas AS13335, AS36183 o
is_hosting. 172.224.226.1 es un relay conis_hosting: true, así que un bloqueo del hosting afecta a usuarios de relay. - Revisa los límites por IP y las geovallas por ciudad. Apple aconseja tratar las IP de relay como NAT a nivel de operador, así que un límite por IP pensado para un hogar frenará a muchos usuarios, y una geovalla a nivel de ciudad fallará con una ubicación aproximada.
Preguntas frecuentes
¿Cómo sé si iCloud Private Relay está activado?
En un iPhone, abre Ajustes, toca tu nombre, luego iCloud y después Private Relay. Como operador de un sitio no puedes ver el ajuste, solo la IP: si coincide con la lista de salidas de Apple, esa petición llegó a través de Private Relay.
¿iCloud Private Relay es una VPN?
No. Solo cubre Safari, el DNS y el tráfico http no seguro de las apps, mantiene al usuario en su propio país y región, y está limitado a dispositivos Apple validados con iCloud+.
¿Cloudflare WARP oculta tu dirección IP?
Sí. Cloudflare afirma que WARP sustituye la IP original por una IP de Cloudflare tanto si el sitio está en Cloudflare como si no, salvo en el tráfico WebRTC y en los sitios a los que se concede acceso a la cámara o al micrófono.
¿Dónde está la lista de direcciones IP de iCloud Private Relay?
Apple la publica en mask-api.icloud.com/egress-ip-ranges.csv. El 12 de octubre de 2026 contenía 285.091 prefijos IPv4 e IPv6 de 235 códigos de país.
¿Puede un sitio web ver la IP real detrás de Private Relay?
Por diseño, no. El sitio solo ve la IP del relay, y solo el primer relay de Apple ve la dirección propia del usuario.
¿Debería bloquear iCloud Private Relay?
No. Apple indica que puede ser necesario ajustar las reglas antifraude basadas en IP para los usuarios de relay. Permítelo, limita su tasa como si fuera NAT a nivel de operador y refuerza la verificación solo ante otras señales de riesgo.
El equipo detrás de la API de GeoIPHub
Escrito por el equipo de GeoIPHub, las personas que crean la API de inteligencia IP de GeoIPHub y su escáner. Los borradores se preparan con ayuda de IA y el equipo los edita; los ejemplos de la API son consultas reales contra la API en producción, salvo que se indique que son ilustrativos.
Prevención del fraude