Teste de vazamento de WebRTC
O WebRTC pode entregar a um site endereços que o seu navegador não enviaria de outra forma, inclusive o que está por trás da sua VPN. Este teste consulta três servidores STUN operados pela Cloudflare e pelo Google, mostra cada endereço que voltou e o que cada um é, e os compara com o endereço que um site já vê. Quando não consegue testar algo, ele diz isso em vez de mostrar um sinal verde.
Cada endereço que o WebRTC produz aparece aqui, um por linha, à medida que os servidores STUN respondem.
Nenhum endereço que o WebRTC encontra é enviado para nós. O seu navegador pergunta aos servidores STUN por conta própria, como em qualquer videochamada. Para mostrar o que um site vê, a página pergunta ao ipify.org e ao nosso próprio servidor quais são os seus endereços e as redes deles, como faz o Teste de Vazamento de DNS.
O que é um vazamento de WebRTC?
O WebRTC é o recurso do navegador por trás das videochamadas. Para conectar duas pessoas diretamente, ele coleta todos os endereços pelos quais a sua máquina pode ser alcançada e os oferece à página, inclusive endereços que o seu navegador nunca enviaria numa requisição comum.
Esse processo se chama coleta de candidatos ICE (ICE candidate gathering) e está especificado na RFC 8445. O seu navegador lista os endereços das suas próprias interfaces de rede, depois pergunta a um servidor STUN “de que endereço você me vê chegando?” e acrescenta esse também. Qualquer página da internet pode iniciar isso com poucas linhas de JavaScript e ler cada candidato à medida que ele chega, sem nenhum pedido de permissão: é assim que foi projetado, porque uma chamada precisa funcionar sem ele.
Isso vira um vazamento quando um desses endereços é algo que você estava escondendo. Uma VPN muda o caminho que as requisições do seu navegador seguem, mas o WebRTC pode perguntar ao sistema operacional sobre todas as interfaces, então, numa máquina em que a conexão física continua ativa, o endereço real pode aparecer ao lado do da VPN. Nada deu errado: o recurso está fazendo exatamente aquilo para que foi projetado.
O que qualquer página pode iniciaruma coleta, passo a passo
const pc = new RTCPeerConnection({
iceServers: [{ urls: "stun:stun.cloudflare.com:3478" }],
});
pc.createDataChannel("");
pc.onicecandidate = (e) => e.candidate && console.log(e.candidate.candidate);
await pc.setLocalDescription(await pc.createOffer());candidate:3442447574 1 udp 2122260223 8b7f4e2a-5c1d-4e6f-9a0b-3d2c1e0f4a5b.local 54400 typ host generation 0candidate:1467250027 1 udp 1686052607 203.0.113.7 54400 typ srflx raddr 0.0.0.0 rport 9 generation 0
O que cada linha é
hostNesta máquina8b7f4e2a-5c1d-4e6f-9a0b-3d2c1e0f4a5b.localMascarado pelo seu navegadorsrflxVisto por um servidor STUN203.0.113.7Roteável na internet

O vereditoVazamento, sem vazamento ou, com honestidade, não foi possível testar, com o motivo.Cada endereçoCom o tipo de candidato, porque um candidato host significa algo diferente de um reflexivo de servidor.O que éPrivado, NAT de operadora, um túnel ou roteável. Só um endereço roteável pode ser um vazamento.Os servidoresCada servidor STUN na sua própria linha. Um servidor que não disse nada é um teste que não rodou.O que um site vêOs endereços que o seu navegador envia de qualquer forma, com os quais os do WebRTC são comparados.Como verificar se há vazamento de WebRTC
Inicie o teste acima. Ele coleta candidatos de três servidores STUN, descobre o que cada endereço é e compara os roteáveis com o endereço que um site já vê.
Há três resultados possíveis, não dois.Sem vazamento significa que todo endereço roteável que o WebRTC produziu é um que o site já tem. Vazamento significa que pelo menos um não é, ou que um endereço da sua própria máquina foi oferecido diretamente. Não foi possível testar significa que o WebRTC está desligado, bloqueado ou que nenhum servidor STUN respondeu, e é o resultado que a maioria das ferramentas transforma discretamente em aprovação.
Rode duas vezes se você usa VPN: uma com ela desligada, para ver os seus endereços de sempre, e outra com ela ligada. A segunda execução é a que importa, e a diferença entre as duas é a resposta. A página guarda o primeiro resultado para você comparar sem anotar nada.
Três resultados, não doiso que cada um significa
- Sem vazamento
Todo endereço roteável que o WebRTC produziu é um que um site já tem.
O WebRTC entregou
198.51.100.23Visto por um servidor STUNOs sites já veem8b7f4e2a-….localNesta máquinaMascarado pelo seu navegador
Um site vê
198.51.100.23 - Vazamento
Pelo menos um endereço não é um que o site já tem, ou um endereço da sua própria máquina foi oferecido diretamente.
O WebRTC entregou
198.51.100.23Visto por um servidor STUNOs sites já veem2001:db8:4a1f:7c00::1cNesta máquinaOs sites não veem
Um site vê
198.51.100.23 - Não foi possível testar
O WebRTC está desligado ou bloqueado, ou nenhum servidor STUN respondeu. Nada foi medido.
stun.cloudflare.comSem respostastun.l.google.comSem respostaO que a maioria das ferramentas mostra aqui
Sem vazamento
Rode duas vezes
VPN desligada
O WebRTC entregou203.0.113.7
Um site vê203.0.113.7
VPN ligada
O WebRTC entregou198.51.100.23203.0.113.7
Um site vê198.51.100.23
Continua lá com a VPN ligada
VazamentoUma VPN impede o vazamento de WebRTC?
Sozinha, não. Uma VPN muda para onde o seu tráfego vai; o WebRTC pode perguntar ao seu sistema operacional quais interfaces existem, e a física geralmente continua lá.
A própria descrição do IETF é exata: “se o cliente tenta esconder a sua localização física por meio de uma rede privada virtual (VPN), e a VPN e o sistema operacional local permitem roteamento por várias interfaces, o WebRTC pode descobrir não só o endereço público da VPN, mas também o endereço público do provedor sobre o qual a VPN está rodando”. Os dois endereços são oferecidos, e uma página que esteja atenta pode ler os dois.
Alguns clientes de VPN fecham a brecha roteando todo o tráfego no nível do sistema operacional, ou incluindo uma extensão de navegador que restringe o WebRTC. Os dois métodos funcionam, e os dois são coisas para verificar, não para presumir: é para isso que serve esta página. Uma VPN cuja própria página de teste de vazamento diz que você está protegido não é uma prova independente.
Uma VPN ligada, o Wi-Fi ainda ativoduas interfaces, duas respostas
O que a página recebe
198.51.100.23srflxVisto por um servidor STUNpela VPNOs sites já veem203.0.113.7srflxVisto por um servidor STUNpelo Wi-Fi, fora do túnelOs sites não veem
O que fecha a brecha
- Roteamento no nível do sistema operacionalNada sai fora do túnel, então um servidor STUN só consegue ver o endereço da VPN.
- A extensão de navegador da VPNEla restringe o WebRTC dentro do navegador, então a outra interface nunca é consultada.
- Depois, verifique em vez de presumirRode este teste com a VPN ligada. A página de teste de vazamento da própria VPN não é uma prova independente.
Host, reflexivo de servidor e relay: qual candidato é qual?
Um candidato host é um endereço da sua própria máquina. Um reflexivo de servidor é o que um servidor STUN viu: o lado público do seu NAT. Um candidato relay é o endereço de um servidor TURN, não o seu.
A distinção importa, e a maioria dos testes de vazamento a joga fora. Um candidato reflexivo de servidor que carrega o seu IPv4 público geralmente não é novidade: é o mesmo endereço que o site recebe da conexão que você já está usando. Um candidato host que carrega um endereço roteável é outra coisa: é um endereço da própria máquina, oferecido diretamente à página. Ele identifica esta máquina, não só o roteador da sua casa, e muda quando a rede muda.
A página mostra o tipo ao lado de cada endereço, junto com o transporte, a porta e o endereço relacionado que um candidato reflexivo indica. Um candidato relay é o próprio endereço do servidor TURN e não revela nada sobre você; este teste não usa nenhum servidor TURN, então, se aparecer um, outra coisa na página o configurou.
Um candidato, campo por campocomo uma página o recebe
candidate:1467250027Fundação1ComponenteudpTransporte1686052607Prioridade203.0.113.7Endereço54400Portatyp srflxTiporaddr 0.0.0.0 rport 9Endereço relacionadogeneration 0Extensão
Trocado por 0.0.0.0, porta 9, onde os endereços locais são mascarados
Os quatro tipos
typ hostNesta máquinaUm endereço de uma das suas próprias interfaces de rede.
Um privado é mascarado. Um roteável é o próprio dispositivo: a descoberta mais grave.
Mais grave quando roteável
typ srflxVisto por um servidor STUNO lado público do seu roteador, como um servidor STUN o viu.
Geralmente é o endereço que um site já tem pela sua conexão.
Geralmente não é novidade
typ prflxVisto pelo outro ladoO lado público do seu roteador, como a outra ponta de uma chamada o viu.
Só aparece ao conectar com a outra ponta, então um teste sem chamada nunca vê um.
Só durante uma chamada
typ relayO próprio endereço de um servidor relayO endereço de um servidor TURN, que retransmite o tráfego para você.
O endereço do servidor, não o seu. Este teste não usa nenhum servidor TURN, então, se houver um aqui, foi outra coisa que o configurou.
Nada sobre você
O que é um endereço mDNS .local, e ele me protege?
Os navegadores modernos trocam os seus endereços privados por um nome aleatório terminado em .local antes de oferecê-los a uma página. Funciona, para endereços privados. Nunca teve a intenção de esconder um público.
O Chrome faz isso por padrão desde a versão 76 e o Firefox tem media.peerconnection.ice.obfuscate_host_addresses definido como true: em vez de 192.168.1.20, a página recebe algo como 8b7f4e2a-….local, que não significa nada para ninguém fora da sua rede. O Safari vai além: até que um site tenha permissão de câmera ou microfone, ele não oferece nenhum candidato host. O teste acima reconhece esses nomes .local e os apresenta como a proteção funcionando, não como uma descoberta.
O rascunho do IETF que define o mecanismo é explícito sobre o que ele não faz: “um endereço que já está exposto à internet não precisa ser protegido pelo mDNS, pois pode ser observado trivialmente pelo servidor web”. Então um candidato reflexivo de servidor continua carregando o seu IPv4 público e, o que surpreende muita gente, uma máquina com um endereço IPv6 roteável ainda pode oferecer esse endereço como candidato host. Há mais uma brecha que vale conhecer: o Chrome desliga a proteção em qualquer site que já tenha permissão de câmera ou microfone, então um site de videochamada que você já usou vê os seus endereços locais reais.
O que o nome .local substituie o que ele deixa como está
O que o seu navegador tem
candidate:3442447574 1 udp 2122260223 192.168.1.20 54400 typ host generation 0
O que a página recebe
candidate:3442447574 1 udp 2122260223 8b7f4e2a-5c1d-4e6f-9a0b-3d2c1e0f4a5b.local 54400 typ host generation 0
O que cada navegador faz por padrão
- ChromeVersão 76, agosto de 2019
- Firefox
media.peerconnection.ice.obfuscate_host_addresses = true - SafariNenhum candidato host até que um site tenha permissão de câmera ou microfone
O mecanismo é um rascunho do IETF, revisado pela última vez em dezembro de 2021 e nunca publicado como RFC. draft-ietf-mmusic-mdns-ice-candidates-03
192.168.1.20O seu IPv4 privado, como candidato hostMascaradoTrocado por um nome aleatório: a página não descobre nada sobre a sua rede.203.0.113.7O seu IPv4 público, como candidato do servidor STUNVisívelJá é público, então fica. Só o endereço relacionado é apagado.2001:db8:4a1f:7c00::1cUm IPv6 roteável, como candidato hostVisívelTambém é público, então o mascaramento nunca foi feito para cobri-lo.2001:db8:4a1f:7c00:8d3:5e2f:a41c:9b07Um endereço IPv6 temporárioPode aparecerO rascunho deixa o navegador mantê-lo sem máscara, por escolha.192.168.1.20Qualquer endereço local, num site com permissão de câmera ou microfoneSem máscaraO Chrome desliga o mascaramento ali: o site vê os seus endereços locais reais.Por que o IPv6 é o vazamento que sobra
Um endereço IPv6 global pertence a uma única máquina, e não a uma casa atrás de NAT, e o mDNS o deixa de lado de propósito. É a coisa mais identificadora que o WebRTC ainda entrega.
Com IPv4, o NAT do roteador da sua casa coloca tudo atrás de um único endereço, então um candidato reflexivo de servidor diz a uma página mais ou menos o que a sua conexão comum já diz. O IPv6 não tem NAT: cada dispositivo tem o próprio endereço roteável, e um candidato host que o carrega identifica o dispositivo, não a linha. Se a sua VPN só transporta IPv4 (muitas são assim), esse endereço IPv6 também fica totalmente fora do túnel.
As extensões de privacidade ajudam, porque um endereço IPv6 temporário é trocado de tempos em tempos. Mas elas não o escondem: o rascunho do mDNS diz que esses endereços podem ficar sem ofuscação. O teste acima marca um candidato host IPv6 roteável como a coisa mais grave que ele pode encontrar, e o Teste IPv6 diz se a sua conexão tem IPv6 ou não.
Quem um endereço identificaos mesmos três dispositivos, duas vezes
192.168.1.202001:db8:4a1f:7c00::1c 192.168.1.212001:db8:4a1f:7c00::2b 192.168.1.222001:db8:4a1f:7c00::3d 203.0.113.7Um endereço para a linha inteiraUm endereço por dispositivoUm endereço IPv6 global, em duas metades
2001:db8:4a1f:7c00Prefixo de rede: a sua linha /64:8d3:5e2f:a41c:9b07Identificador de interface: este dispositivo
- Estável
2001:db8:4a1f:7c00::1c - Temporário: é trocado
2001:db8:4a1f:7c00:8d3:5e2f:a41c:9b07
Uma VPN que só transporta IPv4
- IPv4
198.51.100.23Dentro do túnel - IPv6
2001:db8:4a1f:7c00Fora do túnel::1c
Como impedir o vazamento de WebRTC em cada navegador
O Firefox tem preferências que funcionam. O Edge tem uma política corporativa. O Safari já restringe os candidatos. As extensões de navegador que ainda são recomendadas não fazem mais nada.
No Firefox, about:config → media.peerconnection.ice.default_address_only envia um único endereço em vez de todos, e media.peerconnection.ice.relay_only limita a coleta a candidatos relay, o que quebra as chamadas diretas, mas esconde todo o resto. As duas vêm desativadas por padrão; o mascaramento mDNS dos endereços privados (media.peerconnection.ice.obfuscate_host_addresses) já vem ativado. No Edge, a política WebRtcLocalIpsAllowedUrls controla quais sites podem ver endereços locais; a própria documentação da Microsoft observa que adicionar um site “enfraquece a proteção”. O Chrome não tem uma configuração equivalente para um usuário comum. O Safari é o mais rígido sem que você peça: sem permissão de câmera ou microfone, o WebKit só oferece candidatos reflexivos de servidor e relay, e nenhum candidato host.
Duas coisas ainda muito recomendadas não funcionam mais. A opção “Prevent WebRTC from leaking local IP addresses” do uBlock Origin foi removida na versão 1.38, com a observação de que ela “não é mais necessária nos navegadores modernos, exceto no Firefox para Android”. E a extensão WebRTC Network Limiter do Google, ainda listada na loja, não consegue rodar: as extensões Manifest V2 estão desativadas para todos os usuários do Chrome desde o Chrome 138, em julho de 2025. Se uma página manda você instalar qualquer uma das duas, essa página não é atualizada há anos.
O que cada navegador oferececonferido com a documentação de cada fabricante
FirefoxPreferências que funcionam
about:configmedia.peerconnection.ice.obfuscate_host_addressesPadrãotrueMascara os endereços privados. Já vem ativado.media.peerconnection.ice.default_address_onlyPadrãofalseMude paratrueEnvia um único endereço em vez de todos.media.peerconnection.ice.relay_onlyPadrãofalseMude paratrueSó candidatos relay. Esconde o máximo e quebra as chamadas diretas.
EdgePolítica corporativa
WebRtcLocalIpsAllowedUrlsLista os sites que podem ver endereços locais.
Não configurada: os endereços locais continuam mascarados.
A própria nota da Microsoft: adicionar um site enfraquece a proteção.
Windows e macOS, versão 80 e posteriores
ChromeSem configuração
Sem configuração para o usuário comum.
Endereços privados mascarados por padrão desde a versão 76.
Não num site com permissão de câmera ou microfone.
SafariRígido por padrão
Sem permissão de câmera ou microfone, só candidatos do servidor STUN e relay.
Nenhum candidato host.
Conselhos que não funcionam mais
Prevent WebRTC from leaking local IP addressesuBlock Origin
Removida na versão 1.38Não é mais necessária nos navegadores modernos, segundo o uBlock Origin, exceto no Firefox para Android.
WebRTC Network LimiterGoogle · Chrome Web Store
Ainda listada, não consegue rodarAs extensões Manifest V2 estão desativadas para todos os usuários do Chrome desde o Chrome 138, julho de 2025.
Vazamento de WebRTC, de DNS e de IP: qual é a diferença?
São três maneiras diferentes de uma VPN ser contornada. Um vazamento de WebRTC mostra um endereço; um vazamento de DNS mostra quem responde às suas consultas; um vazamento de IP é o caso simples em que o seu tráfego nunca entrou no túnel.
Um vazamento de WebRTC tem a ver com endereços que o seu navegador oferece por conta própria, por meio de um recurso feito para oferecê-los. Um vazamento de DNS tem a ver com qual resolvedor responde às suas consultas: o seu tráfego pode passar pela VPN enquanto as suas consultas continuam indo para o resolvedor do seu provedor, o que conta a esse provedor cada site que você visita. O nosso Teste de Vazamento de DNS verifica isso com o nosso próprio servidor de nomes, então consegue ver exatamente quais resolvedores perguntaram.
Um vazamento de IP, no sentido geral, é o endereço que um site simplesmente vê, e você pode conferi-lo no Qual é Meu IP ou no Qual é Meu ISP. Rode os três juntos depois de qualquer mudança na VPN: eles falham de forma independente, e um resultado limpo em um não diz nada sobre os outros.
Três maneiras de contornar uma VPNcada uma falha por conta própria
Vazamento de IP
O que vazaO endereço que toda requisição carrega
Quem fica sabendoCada site que você visita
Verifique comQual é Meu IPQual é Meu ISP
Vazamento de DNS
O que vazaQual resolvedor responde às suas consultas
Quem fica sabendoO seu provedor, para cada site que você consulta
Verifique comTeste de Vazamento de DNS
Vazamento de WebRTC
O que vazaEndereços que o seu navegador oferece a uma página
Quem fica sabendoQualquer página que pedir, sem aviso
Verifique comTeste de Vazamento WebRTC
Por que este teste consulta mais de um servidor STUN
Porque “nenhum endereço voltou” e “nenhum endereço existe” parecem idênticos, e só um deles é uma boa notícia.
Um firewall corporativo, uma VPN restritiva ou uma rede que bloqueia UDP pode impedir que um servidor STUN responda. Um teste que consulta um único fornecedor e não vê nada não aprendeu nada; mesmo assim, a resposta de costume é mostrar um sinal verde. Este consulta o endpoint STUN documentado da Cloudflare e o do Google, informa cada um separadamente e diz que não foi possível testar quando nenhum deles respondeu.
A escolha dos servidores é proposital. A Cloudflare publica stun.cloudflare.com:3478 como parte de um produto, então há termos para ler. O stun.l.google.com:19302 do Google só está documentado como o padrão do validador de WebRTC do próprio Google, sem termos publicados, então ele é usado como segunda opinião, não como fonte única. O da Twilio exige credenciais, e a Mozilla não documenta nenhum servidor STUN público, por mais que um seja citado.
Servidores STUN públicose quais deles este teste consulta
CloudflareConsultado
stun.cloudflare.com:3478Um endpoint documentado, parte de um produto, com termos para ler.
GoogleConsultado, como segunda opinião
stun.l.google.com:19302Documentado só como o padrão do validador de WebRTC do próprio Google. Sem termos publicados.
TwilioNão consultado
global.stun.twilio.com:3478Exige credenciais da API da Twilio: não está aberto a qualquer página.
MozillaNão consultado
Nenhum servidor públicoNão documenta nenhum servidor STUN público. O Firefox não vem com nenhum servidor ICE padrão.
Quando um servidor não diz nada
O meu endereço IP é um dado pessoal?
Na UE, um endereço IP dinâmico é um dado pessoal para o operador de um site que poderia identificar você com informações que o provedor tem. O Tribunal de Justiça decidiu isso em 2016.
O caso é Breyer, C-582/14, julgado em 19 de outubro de 2016, e o comunicado de imprensa do Tribunal o resume assim: “o endereço de protocolo Internet dinâmico de um utilizador constitui, para o explorador do sítio, um dado pessoal, quando esse explorador disponha de meios legais que lhe permitam identificar o utilizador em causa graças às informações suplementares que o fornecedor de acesso à Internet do utilizador dispõe”. O mesmo comunicado de imprensa observa que um site pode ter um interesse legítimo em guardar parte desses dados para se defender de ataques.
É justamente por isso que esta página faz o trabalho no seu navegador. Os candidatos ICE são coletados pelo seu navegador, comparados no seu navegador e mostrados a você; nenhum endereço que o WebRTC encontra é enviado para nós, então não há nada dele para guardarmos, entregarmos ou perdermos. Você pode acompanhar o painel de rede enquanto o teste roda.
A decisão BreyerTribunal de Justiça da União Europeia
C-582/14Breyer v Bundesrepublik Deutschland19 de outubro de 2016
- O operador do siteum endereço e um horário, dos seus registros
203.0.113.7 · 14:02:37 - os meios legais para obter isso
- O provedor de acesso à internetquem estava usando aquele endereço naquele horário
203.0.113.7 · 14:02:37 → - Dado pessoal, para esse operador
O comunicado de imprensa do Tribunal: um site pode ter um interesse legítimo em guardar parte desses dados para se defender de ataques.
Nesta página
Seu navegador
- Coleta
- Classifica
- Compara
- Mostra
- Veem o seu endereço público, como em qualquer chamada
- dnsrobot.netNenhum candidato é enviado
Teste de vazamento de WebRTC: perguntas e respostas
O que é um vazamento de WebRTC?
Como faço um teste de vazamento de WebRTC?
Uma VPN impede o vazamento de WebRTC?
O que significa um endereço .local nos resultados?
.local antes de oferecê-los a uma página, então, a partir desses nomes, um site não descobre nada sobre a sua rede doméstica. O Chrome faz isso desde a versão 76 e o Firefox faz o mesmo; o Safari vai além e não oferece nenhum candidato host até que um site tenha permissão de câmera ou microfone. O teste marca esses nomes como a proteção funcionando, e não como uma descoberta.Se o mDNS esconde o meu IP local, estou seguro?
Por que o teste às vezes diz que não foi possível testar?
Como desativo o WebRTC no Firefox?
about:config, media.peerconnection.ice.default_address_only envia um único endereço em vez de todos, e media.peerconnection.ice.relay_only limita a coleta a candidatos relay: isso esconde o máximo, mas quebra as chamadas diretas. O mascaramento dos endereços privados, media.peerconnection.ice.obfuscate_host_addresses, já vem ativado por padrão. Rode o teste de novo depois de cada ajuste para ver o que ele trouxe.Como impedir vazamentos de WebRTC no Chrome?
WebRtcLocalIpsAllowedUrls. As extensões ainda muito recomendadas não funcionam: o uBlock Origin removeu a opção de WebRTC na versão 1.38, e o WebRTC Network Limiter do Google não consegue rodar desde que o Manifest V2 foi desativado no Chrome 138.Qual é a diferença entre um candidato host e um reflexivo de servidor?
Vazamento de WebRTC é o mesmo que vazamento de DNS?
Este teste envia o meu endereço IP para algum lugar?
O meu endereço IP é um dado pessoal segundo o direito da UE?
Sentiu falta de algo?Sugira um recurso ou uma nova ferramenta
Ferramentas relacionadas
Teste de Vazamento de DNS
Veja quais servidores DNS realmente resolvem suas consultas e se sua VPN vaza consultas DNS para o seu provedor de internet
Teste IPv6
Teste se seu IPv6 funciona, que família seu navegador usa e se um site tem IPv6
Consulta de IP
Consulte geolocalização, ISP e detalhes de rede de qualquer endereço IP instantaneamente
Qual é Meu ISP
Descubra seu ISP, ASN e detalhes da conexão
Consulta DNS
Todos os registros DNS direto dos servidores do domínio, ao lado do cache do Google e da Cloudflare
Traceroute
Rastreie a rota de 8 cidades até um site ou IP, hop a hop, com cada rede nomeada
