Detecte o iCloud Private Relay e o Cloudflare WARP, e depois deixe-os passar

Baixamos a lista da Apple às 09:40 UTC de 12 de outubro de 2026. Ela continha 285.091 prefixos, 41.734 IPv4 e 243.357 IPv6, em 235 códigos de país. Dentro do 104.28.0.0/16 da Cloudflare, 19.723 dos 65.536 endereços estão na lista. Os outros 45.813 não estão, então uma regra escrita contra esse bloco, ou contra toda a rede da Cloudflare, não consegue distinguir um usuário do Private Relay de qualquer outra coisa roteada por ali.

A seguir, analisamos o arquivo da Apple e apresentamos um matcher em Python testado para IPv4 e IPv6. Explicamos o que se pode e o que não se pode saber sobre o WARP e mostramos consultas reais de endereços de relay, incluindo dois casos em que a nossa própria geolocalização diverge da Apple. O post termina com uma tabela de políticas. Para o conjunto mais amplo de sinais de anonimização, comece por como funciona a detecção de VPN e proxy.

Como detectar o iCloud Private Relay: compare com a lista da própria Apple

A Apple publica todos os prefixos de saída do Private Relay em um único CSV, então uma correspondência exata indica que um IP é uma saída de relay. O guia da Apple para operadores de rede e de servidores direciona os servidores para essa lista ou para uma flag do provedor:

"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." (Seu servidor pode reconhecer o tráfego do Private Relay usando a lista de endereços IP do Private Relay acima ou verificando como ele é categorizado pelo seu provedor de banco de dados de geolocalização de IP.)

A mesma página cita os campos a procurar: "Other relevant fields may include: 'is_relay', 'is_hosting', 'privacy_service', or 'privacy_proxy'." (Outros campos relevantes podem incluir: 'is_relay', 'is_hosting', 'privacy_service' ou 'privacy_proxy'.) Ou seja, a Apple espera que você use a lista dela ou um campo como o que a nossa API retorna.

A lista também é limpa de um jeito que a maioria das listas de IP não é. A visão geral do Private Relay de dezembro de 2021 da Apple diz que os endereços IP de relay "are not used or shared for any purpose other than to provide the Private Relay service" (não são usados nem compartilhados para nenhuma outra finalidade além de prestar o serviço Private Relay). Portanto, uma correspondência exata não tem efeito colateral. Nenhum outro tráfego sai desses endereços.

O que há no CSV de saída da Apple

O arquivo fica em https://mask-api.icloud.com/egress-ip-ranges.csv. Nós o baixamos e processamos cada linha com o módulo ipaddress do Python.

Cada linha é uma linha de geofeed. Aqui estão duas linhas reais do arquivo:

A segunda linha tem a região vazia, então o seu parser precisa aceitar campos em branco. Uma armadilha na contagem: wc -l mostra 285.090, um a menos, porque o arquivo não termina com quebra de linha. Conte as linhas processadas.

Consultar o arquivo periodicamente custa pouco. O servidor retornou um ETag, "6acc40fb-b7d37f", e respondeu à nossa requisição condicional com 304 Not Modified. A Apple não diz com que frequência atualiza a lista, então não vamos adivinhar. Escolha a frequência de atualização que fizer sentido para você.

Por que uma regra por ASN ou /16 não basta

As saídas de relay compartilham redes com outro tráfego. No 104.28.0.0/16, 19.723 dos 65.536 endereços estão na lista da Apple, e o resto não. A visão geral da Apple diz que o segundo relay "is operated by third-party partners who are some of the largest content delivery networks (CDNs) in the world" (é operado por parceiros terceiros que estão entre as maiores redes de distribuição de conteúdo (CDNs) do mundo). Os três relays que amostramos ficam em duas delas, Cloudflare (AS13335) e Akamai (AS36183).

Bloquear o AS13335 atinge muito mais do que usuários de relay. Colocá-lo em uma allowlist deixa passar muito mais do que relays. A correspondência por prefixo é a ferramenta precisa, e você pode verificar qualquer IP quanto a VPN ou relay para ver como um endereço específico é classificado.

Por que um IP de relay não é um IP de VPN

O Private Relay esconde o IP do usuário do site, mas o mantém na sua região real, cobre apenas parte do tráfego e é limitado a dispositivos Apple validados em contas pagas. É por isso que ele não deve ser pontuado como uma VPN.

O design divide o conhecimento entre dois relays operados por empresas diferentes. A Apple opera o primeiro, que vê o endereço do usuário, mas não o site. Um parceiro opera o segundo, que vê o site, mas não o usuário. A página da Apple para operadores diz que, dessa forma, nenhuma parte isolada, nem mesmo a Apple, consegue ver os detalhes da navegação de um usuário.

Quatro trechos da página da Apple para operadores mudam a forma como você deve tratar esses endereços:

• Escopo. "Private Relay protects users' web browsing in Safari, DNS resolution queries, and insecure http app traffic." (O Private Relay protege a navegação dos usuários no Safari, as consultas de resolução de DNS e o tráfego http inseguro de apps.) Um IP de relay não significa uma sessão do Safari. Um app que faz requisições http simples chega do mesmo jeito.
• Região. "Private Relay preserves the region the user is in, so your server can trust the region assigned to the IP address it sees." (O Private Relay preserva a região em que o usuário está, então o seu servidor pode confiar na região atribuída ao endereço IP que ele vê.) A visão geral de 2021 acrescenta que ele "does not allow users to represent themselves as connecting from a different country or region" (não permite que os usuários se apresentem como se estivessem se conectando de outro país ou região).
• Validação. "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." (Todas as conexões que usam o Private Relay validam que o cliente é um iPhone, iPad ou Mac e que o cliente tem uma assinatura iCloud+ válida.)
• Estabilidade. "The relay IP address will remain stable during a browsing session while a user is interacting with your website." (O endereço IP do relay permanecerá estável durante uma sessão de navegação enquanto o usuário interage com o seu site.)

Uma VPN permite que o usuário escolha qualquer país e cobre o dispositivo inteiro. A Cloudflare é franca sobre o próprio produto. "Technically, WARP is a VPN" (Tecnicamente, o WARP é uma VPN), escreveu a empresa quando lançou o WARP. Voltamos ao WARP mais abaixo.

Uma armadilha prática: parte das saídas de relay fica em data centers, então flags de hospedagem podem disparar. A nossa consulta de 172.224.226.1, um relay que está na lista da Apple, retorna is_hosting: true. É por isso que relays aparecem como IPs de datacenter, e por isso que um bloqueio geral de hospedagem pega clientes da Apple.

Compare um IP com a lista da Apple em Python

Carregue o CSV em intervalos de inteiros ordenados, uma lista por versão de IP, e faça busca binária neles. Atualize com uma requisição condicional e mantenha a última cópia boa se um download falhar ou parecer errado.

Este é exatamente o script que executamos em 12/10/2026, no Python 3.9.6. Ele usa apenas a biblioteca padrão.

A primeira execução, às 09:41 UTC, baixou o arquivo e imprimiu:

162.159.192.1 é um endereço de conexão do WARP e 102.129.235.17 é um servidor de VPN comercial, então nenhum dos dois deveria corresponder, e nenhum correspondeu. Também testamos os caminhos de falha:

• Arquivo inalterado. A segunda execução enviou o ETag salvo, recebeu um 304 e imprimiu "not modified, keeping current list". Carregar e indexar o arquivo local levou 4,3 segundos, então monte o índice uma vez na inicialização, e não a cada requisição.
• Download ruim. Apontamos URL para um caminho que não existe (o servidor da Apple respondeu 400). Em outro teste, elevamos o número mínimo de linhas acima do real. Nas duas vezes, o script registrou a falha, apagou o arquivo temporário e continuou respondendo a partir da cópia antiga.
• Endereços mapeados. ::ffff:104.28.28.41 correspondeu à sua linha IPv4. Servidores dual-stack costumam registrar clientes IPv4 nesse formato.

Como o arquivo não tem prefixos sobrepostos, uma busca binária por consulta é suficiente. O loader recusa qualquer arquivo futuro que tenha sobreposições, e a atualização volta para a última cópia boa.

Como detectar o Cloudflare WARP, e por que não há lista

Você não consegue comparar o WARP com uma lista pública, porque a Cloudflare não publica uma. O WARP só pode ser identificado por um provedor que rotule as faixas que conhece, ou no próprio dispositivo do usuário.

A documentação de políticas de saída da Cloudflare é clara sobre isso: "Cloudflare does not publish Cloudflare One Client egress IP ranges." (A Cloudflare não publica as faixas de IP de saída do Cloudflare One Client.) As "faixas de IP do WARP" que circulam em fóruns são outra coisa. O guia de firewall da Cloudflare diz sobre 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." (Este IP é usado pelo cliente WARP para consumidores (1.1.1.1 com WARP) e não é necessário para os serviços Zero Trust.) É ali que o app WARP se conecta. O seu servidor web nunca vê esses endereços como IPs de cliente.

O site recebe o endereço real do usuário por algum outro caminho? Não na navegação normal. O FAQ do WARP da Cloudflare diz: "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." (O 1.1.1.1 + WARP substitui o seu endereço IP original por um IP da Cloudflare que representa de forma consistente e precisa a sua localização aproximada. Isso acontece independentemente de o site estar ou não na rede da Cloudflare.)

O mesmo FAQ documenta dois vazamentos. "WARP does not proxy WebRTC traffic." (O WARP não faz proxy do tráfego WebRTC.) E: "If you grant a website access to your microphone or camera, traffic will bypass WARP and your original IP address will be visible." (Se você conceder a um site acesso ao seu microfone ou câmera, o tráfego vai contornar o WARP e o seu endereço IP original ficará visível.)

No próprio dispositivo, https://www.cloudflare.com/cdn-cgi/trace mostra um campo warp=. Na nossa máquina, que não usa WARP, ele mostrou warp=off. Só a pessoa que abre essa página vê o resultado, então ele ajuda uma equipe de suporte a depurar a conexão de um cliente. Não serve para nada em um servidor que está pontuando um visitante.

A nossa API retorna relay_provider: "Cloudflare WARP" para as faixas de conexão do WARP publicadas pela Cloudflare. Uma consulta de 162.159.192.1 retornou is_relay: true, relay_provider: "Cloudflare WARP", is_hosting: true e is_anycast: true, com pontuação 24 e allow. Esse é o endereço ao qual os apps WARP se conectam, e não um que o seu servidor verá como visitante.

O que a nossa API retorna para endereços da Cloudflare que não estão na lista da Apple

Endereços de saída da rede de privacidade da Cloudflare que não estão na lista da Apple voltam rotulados como "Cloudflare", enquanto as faixas de conexão do WARP publicadas pela Cloudflare voltam como "Cloudflare WARP". Veja o 104.28.210.10. Ele fica no mesmo /16 que dois dos nossos relays da Apple, mas não está na lista da Apple. Esta é uma cópia resumida da nossa consulta às 09:40 UTC de 12/10/2026, com os valores sem edição:

Leia "Cloudflare" como "um endereço de saída de privacidade para consumidores da Cloudflare não atribuído à Apple". Isso não significa um usuário de WARP confirmado, e não afirmamos isso. A nossa referência da API lista hoje apenas dois valores de relay_provider, "iCloud Private Relay" e "Cloudflare WARP", então esse terceiro valor ainda não está documentado. Pedimos à equipe de backend que o documente.

O ponto útil está nas duas primeiras linhas. Dentro de um mesmo /16 da Cloudflare, a correspondência exata com o CSV separa o relay da Apple (104.28.28.41) de outra saída de privacidade da Cloudflare (104.28.210.10). O nosso rótulo concorda com a lista da Apple nos dois casos. Ambos têm pontuação 9 e allow, então a sua política é a mesma de qualquer forma. A linha da VPN também não tem nome de provedor: as nossas sondagens a detectaram, mas ela não está em nenhuma lista de provedores que temos, e é por isso que uma VPN pode ficar sem nome.

Private Relay e WARP lado a lado

Ambos podem estar no AS13335, então a rede sozinha não distingue nenhum dos dois.

O que as nossas consultas retornam para IPs de relay

Nas nossas consultas, endereços do Private Relay voltam como relays, e não como anônimos ou VPN, e caem em allow a menos que existam outras evidências. Rastreamos o 104.28.46.99 de ponta a ponta. A linha da Apple diz Zâmbia, Lusaka. Esta é a requisição, como você a enviaria com uma chave:

Executamos sem chave às 09:40 UTC de 12/10/2026, o que a API permite para uso leve. Aqui está uma cópia resumida da resposta, com os valores sem edição:

O relay é identificado pelo nome, is_vpn e is_anonymous são false, e scoring.detection_methods mostra o único sinal que disparou: relay_ip. A pontuação é 9, então a ação é allow. A geolocalização diz Angola, o que a linha da Apple contradiz; tratamos disso na próxima seção. A decisão para esse endereço é permiti-lo, aplicar rate limit como a um endereço compartilhado e usar a localização da linha da Apple.

Aqui estão os outros relays ao lado de uma VPN real:

A flag de relay não reduz a pontuação. Ela soma. No 104.28.46.99, relay_ip é a única entrada em detection_methods, então responde pela pontuação inteira de 9. O 172.224.226.1 tem pontuação 24 porque dois sinais de datacenter também dispararam, o que o deixa um ponto dentro do limite de allow, que é 25. Portanto, relays caem em allow a menos que existam outras evidências. Se algo mais pesar contra o endereço, como uma listagem por abuso, a pontuação sobe e a ação pode passar para review. A página como a pontuação é calculada lista os sinais.

A API rotula o relay. O CSV da Apple é a sua verificação independente, e o matcher acima a executa sem depender de nós. Pontuar um relay como se fosse uma VPN é o caso clássico dos falsos positivos na detecção de VPN.

Por que usuários do Private Relay aparecem na cidade errada, inclusive nos nossos dados

Um IP de relay só garante a região do usuário e, por padrão, uma cidade aproximada. A única localização confiável para um IP de relay é a própria linha da Apple, e o nosso banco de dados nem sempre concorda com ela.

A página da Apple para operadores diz que o IP do relay "accurately represents the client's coarse city-level location by default" (representa com precisão, por padrão, a localização aproximada do cliente no nível da cidade). Os usuários podem ampliar isso. O Manual do Usuário do iPhone atual da Apple lista duas opções de Localização do Endereço IP, "Maintain General Location" (Manter localização geral) e "Use Country and Time Zone" (Usar país e fuso horário). A visão geral de 2021 descreve as duas. A primeira escolhe endereços que "map to a roughly city-level area consistent with where the user is actually connecting from" (correspondem a uma área aproximadamente do tamanho de uma cidade, coerente com o local de onde o usuário está de fato se conectando). A segunda escolhe endereços "across a broader, more regional area" (em uma área mais ampla, mais regional), e "All Relay IP addresses will still map to the user's original country and time zone." (Todos os endereços IP de relay continuarão correspondendo ao país e ao fuso horário originais do usuário.)

Comparamos a nossa geolocalização com as linhas da Apple para os três relays:

Dois dos três divergem. Zâmbia contra Angola é um erro no nível do país, do tipo que dispara uma regra de licenciamento ou de sanções. Adelaide contra Sydney acerta o país e erra a cidade. Três IPs não são um benchmark, mas bastam para definir uma regra: para IPs de relay, use a localização da linha da Apple, e não de qualquer banco de geolocalização, inclusive o nosso. Decida com base no país ou na região e trate a cidade como um indício. Registramos as duas divergências com a nossa equipe de backend.

Você deve bloquear o Private Relay ou o WARP? Deixe-os passar e pontue a sessão

Não. A Apple valida todo cliente de relay e diz que regras antifraude baseadas em IP "might need to be adjusted" (podem precisar de ajuste), então permita o tráfego do Private Relay, aplique rate limit como faria com um endereço compartilhado de operadora e só exija verificação adicional quando outras evidências apontarem risco.

A página da Apple para operadores é direta sobre os dois pontos:

"Traditional fraud detection that relies on IP addresses might need to be adjusted to ensure legitimate users aren't impacted." (A detecção de fraude tradicional que depende de endereços IP pode precisar de ajustes para garantir que usuários legítimos não sejam afetados.)

"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." (Considere tratar esses endereços como endereços IP de NAT de nível de operadora ou corporativos maiores, para lidar melhor com esse tipo de tráfego, já que muitos usuários do Private Relay podem ser atribuídos a um único endereço IP de relay.)

A Apple também oferece um substituto para a página de desafio. Ela observa que "Common mitigations include CAPTCHAs or blocking traffic altogether" (Mitigações comuns incluem CAPTCHAs ou o bloqueio total do tráfego) e diz que "Every Apple device running iOS 16, iPadOS 16, or macOS Monterey and later supports Private Access Tokens" (Todo dispositivo Apple com iOS 16, iPadOS 16 ou macOS Monterey e posteriores oferece suporte a Private Access Tokens), que permitem a um servidor verificar se o dispositivo é legítimo sem identificar o usuário.

Fraudadores podem usar relays? Podem, mas o Private Relay exige um dispositivo Apple e uma conta paga do iCloud+. A Apple diz que a validação "is designed to ensure that only valid Apple devices and accounts in good standing are allowed to use Private Relay" (foi projetada para garantir que apenas dispositivos Apple válidos e contas em situação regular possam usar o Private Relay). Isso torna o relay uma forma cara de criar contas em massa. O WARP é um app gratuito, então dê às sessões WARP um pouco mais de peso nos seus outros sinais, e não um bloqueio. Problemas mais difíceis de ocultação de IP estão em outro lugar, como os proxies móveis.

Um detalhe para o seu rate limiter: a recomendação da Apple sobre NAT de nível de operadora trata de como você lida com o endereço, e não de uma flag. O nosso threat.is_cgnat foi false nas três consultas de relay. Baseie o tratamento de endereço compartilhado em is_relay ou na correspondência com o CSV. Para verificar um endereço dos seus próprios logs, cole-o na ferramenta gratuita de consulta de IP.

Três verificações para fazer nos seus próprios logs esta semana:

• Conte os usuários de relay que você recusou. Cruze os cadastros, logins e recusas dos últimos 30 dias com o CSV da Apple usando o matcher acima. Quantos usuários de relay as suas regras recusaram ou desafiaram?
• Encontre bloqueios por ASN e por hospedagem. Procure nas suas regras por AS13335, AS36183 ou is_hosting. O 172.224.226.1 é um relay com is_hosting: true, então um bloqueio de hospedagem atinge usuários de relay.
• Verifique limites por IP e geofences por cidade. A Apple recomenda tratar IPs de relay como NAT de nível de operadora, então um limite por IP dimensionado para uma única residência vai estrangular muitos usuários, e uma cerca no nível da cidade vai falhar com uma localização aproximada.

Perguntas frequentes

Como sei se o iCloud Private Relay está ativado?

No iPhone, abra Ajustes, toque no seu nome, depois em iCloud e em Retransmissão Privada (Private Relay). Como operador de um site, você não vê essa configuração, apenas o IP: se ele corresponder à lista de saída da Apple, a requisição passou pelo Private Relay.

O iCloud Private Relay é uma VPN?

Não. Ele cobre apenas o Safari, o DNS e o tráfego http inseguro de apps, mantém o usuário no próprio país e região e é limitado a dispositivos Apple validados com iCloud+.

O Cloudflare WARP esconde o seu endereço IP?

Sim. A Cloudflare afirma que o WARP substitui o IP original por um IP da Cloudflare, esteja o site na Cloudflare ou não, exceto no tráfego WebRTC e em sites com acesso à câmera ou ao microfone.

Onde fica a lista de endereços IP do iCloud Private Relay?

A Apple a publica em mask-api.icloud.com/egress-ip-ranges.csv. Em 12/10/2026 ela continha 285.091 prefixos IPv4 e IPv6 em 235 códigos de país.

Um site consegue ver o IP real por trás do Private Relay?

Não, por design. O site vê apenas o IP do relay, e só o primeiro relay da Apple vê o endereço do próprio usuário.

Devo bloquear o iCloud Private Relay?

Não. A Apple diz que regras antifraude baseadas em IP podem precisar de ajuste para usuários de relay. Permita o tráfego, aplique rate limit como faria com um NAT de nível de operadora (CGNAT) e só exija verificação adicional diante de outros sinais de risco.