WebRTC: como detectar e corrigir vazamentos de IP real — guia passo a passo

Introdução

Neste guia passo a passo, você aprenderá como detectar e fechar vazamentos de IP real do WebRTC enquanto trabalha por meio de um proxy. Vamos explicar detalhadamente por que o vazamento de WebRTC é perigoso para a privacidade, como verificá-lo e como fechá-lo garantidamente nos navegadores populares, através de extensões e em navegadores anti-detecção. Em uma etapa separada, mostraremos como relacionar corretamente as configurações com um proxy móvel e como garantir que não haja vazamentos. Ao final, você receberá uma lista de verificação, uma análise dos erros comuns, dicas avançadas e respostas para as perguntas mais frequentes. Seguindo as instruções passo a passo, você chegará a um resultado estável sem suposições ou experimentos.

Este guia é adequado para usuários iniciantes e especialistas que desejam corrigir rapidamente e com segurança os vazamentos, bem como para usuários avançados que valorizam configurações refinadas, replicação de perfis e resultados de teste previsíveis. Não é necessário ter conhecimento prévio. Basta saber usar um navegador e entender o que é um servidor proxy.

O que você precisa saber antes: WebRTC é uma tecnologia de navegador que pode informar endereços IP externos e locais durante a troca de candidatos de conexão (ICE). Através do proxy, isso pode expor seu IP real, se nenhuma ação for tomada. Vamos explicar todos os conceitos de forma simples na seção "Conceitos Básicos".

Quanto tempo será necessário: verificar e fechar um vazamento básico em um navegador — 40 a 60 minutos; adicionar extensões, trabalhar com um navegador anti-detecção e realizar testes finais — mais 20 a 30 minutos. Se você estiver configurando vários navegadores e perfis ao mesmo tempo, planeje cerca de 90 a 120 minutos.

Preparação Inicial

Antes de começar, certifique-se de ter tudo o que é necessário e de entender como iremos verificar o resultado. Esta etapa reduzirá o risco de erros e economizará seu tempo.

Ferramentas e Acessos Necessários

• Acesso a um navegador de trabalho no computador (Chrome, Edge, Firefox, Opera ou Safari).
• Acesso às configurações do proxy que você está usando (HTTP(S) ou SOCKS5). Se estiver trabalhando com um proxy móvel, prepare as credenciais do painel do provedor. Um exemplo desse serviço é: mobileproxy.space.
• Preparação para instalar uma extensão para gerenciar o WebRTC (como uma extensão que limita ou desativa o WebRTC em navegadores baseados em Chromium) e o uBlock Origin para proteção adicional.
• Se usar um navegador anti-detecção: acesso à sua conta e painel de configurações de perfis.

Requisitos do Sistema

• Windows 10/11, macOS 12+ ou uma distribuição Linux moderna.
• Versões atualizadas dos navegadores (atualizações atuais de 2026). Atualize o navegador antes de começar.
• Conexão de internet estável.

O que Baixar e Instalar

• Navegador(s) com o qual pretende trabalhar.
• Extensão para limitar o WebRTC para seu navegador baseado em Chromium (exemplo: WebRTC Control ou WebRTC Leak Prevent). Também instale o uBlock Origin e ative a função que previne vazamentos de WebRTC, se disponível nas configurações.
• Navegador anti-detecção (se necessário), se você estiver trabalhando com perfis. Exemplos: AdsPower, Dolphin{anty}, Incogniton, GoLogin, Octo Browser e outros.

Cópias de Segurança

Se você estiver trabalhando com um navegador anti-detecção ou com um perfil corporativo, exporte ou registre as configurações atuais dos perfis antes de fazer alterações. Se mudar políticas de sistema ou flags do navegador, registre os valores originais.

⚠️ Atenção: Antes de alterar configurações ocultas do navegador (por exemplo, about:config no Firefox ou flags em navegadores baseados em Chromium), anote os valores atuais. Isso permitirá reverter, caso algum site pare de funcionar como esperado.

✅ Verificação: Neste estágio, você deve ter: acesso ao navegador, credenciais do proxy, lista de extensões para instalação e cópias de segurança (se estiver mudando perfil ou políticas).

Conceitos Básicos

Termos-Chave em Linguagem Simples

• WebRTC — tecnologia de navegador para troca de áudio, vídeo e dados em tempo real. Para estabelecer uma conexão, o WebRTC troca "candidatos" de rotas de rede (ICE), incluindo através de STUN/TURN.
• Candidatos ICE — caminhos possíveis para comunicação entre duas partes. Estes podem incluir endereços IP públicos e locais.
• STUN/TURN — servidores auxiliares que ajudam a descobrir seu IP público, determinar rotas e estabelecer conexões mesmo atrás de NAT e firewalls.
• mDNS — método de ocultar seu IP local ao fornecer candidatos ICE, substituindo endereços locais por identificadores temporários mDNS.
• Proxy — servidor intermediário pelo qual passa seu tráfego HTTP(S) ou SOCKS5. Um proxy mascara seu IP real para os sites que você visita.

Por que ocorre vazamento de WebRTC

Mesmo que o navegador esteja configurado para trabalhar via proxy, o WebRTC pode, contornando a rota HTTP(S), acessar um servidor STUN via UDP e obter o IP público da sua conexão de internet. Esses dados podem então ser visíveis para scripts na página. Como resultado, o site consegue identificar seu IP real, apesar do proxy. Isso é o que chamamos de vazamento de WebRTC.

O que você precisa entender antes de começar

• Desabilitar completamente o WebRTC pode quebrar chamadas de áudio e vídeo, compartilhamento de tela e outras funções.
• O objetivo deste guia não é "quebrar o WebRTC", mas garantir que seu IP real não seja exposto. Onde possível, usaremos métodos "suaves": mDNS, limitação ao interface pública, regras de candidatos ICE.
• Diferentes navegadores oferecem diferentes níveis de controle. O Firefox permite ajustes finos através do about:config. Em navegadores baseados em Chromium, é mais eficaz usar uma extensão ou políticas.

Dica: Se suas atividades não precisam de funcionalidades do WebRTC (chamadas, transferências de arquivos no navegador), considere uma desativação mais rigorosa em um perfil destinado a tarefas onde a privacidade é crítica.

Passo 1: Definindo o contorno do proxy e o ambiente

Objetivo da etapa: entender como exatamente o tráfego flui do seu navegador e onde o WebRTC pode contornar o proxy.

Passos Detalhados

1. Abra o navegador com o qual você está trabalhando através do proxy.
2. Verifique a configuração ativa do proxy. Para navegadores baseados em Chromium, abra as configurações: Configurações — Sistema — Abrir configurações de proxy. Verifique se o servidor proxy está especificado, incluindo nome de usuário e senha (quando necessário).
3. Se você estiver usando um perfil em um navegador anti-detecção, abra as configurações do perfil e verifique se o proxy está especificado: tipo (HTTP, HTTPS ou SOCKS5), host, porta, nome de usuário e senha quando necessário.
4. Registre o IP externo atual que os sites veem através do seu proxy. Pesquise "meu ip" e abra qualquer serviço que mostre o IP externo. Anote este IP como "IP através do proxy".
5. Se você usa um proxy móvel, registre o painel de controle do provedor. Por exemplo, no mobileproxy.space, verifique o endereço IP, região, método de autenticação (por login/senha ou por lista de IPs permitidos) e o estado da rotação de IP.

Pontos Importantes

• Proxy ≠ WebRTC. O proxy gerencia tráfego HTTP(S)/SOCKS, e o WebRTC pode revelar o IP durante a troca ICE.
• Precisamos assegurar que quaisquer candidatos WebRTC não exponham seu IP público e local real.

⚠️ Atenção: Se você estiver utilizando políticas corporativas para o navegador, qualquer alteração nas flags ou extensões pode ser substituída pelo administrador. Verifique se você está sob uma política centralizada que desativa as opções que você precisa.

Dica: Crie um bloco de notas para registros: "IP através do proxy", "Data e hora", "Nome do perfil", "Extensão e versão". Essas anotações ajudarão a repetir rapidamente a configuração ou solucionar problemas.

✅ Verificação: Você registrou o IP visível através do proxy e está ciente de onde e como o proxy está configurado no navegador ou no perfil.

Possíveis Problemas e Soluções

• Problema: O navegador não está utilizando o proxy. Causa: Endereço ou porta incorretos. Solução: Verifique o formato do tipo de protocolo, host, porta, nome de usuário/senha.
• Problema: O proxy requer autenticação, mas o navegador não solicita nome de usuário/senha. Causa: Esquema de autenticação incorreto. Solução: Informe os dados manualmente no perfil ou configure nas configurações do sistema.

Passo 2: Verificando vazamentos de WebRTC em navegadores de desktop

Objetivo da etapa: confirmar a existência ou a ausência de vazamento antes de iniciar a configuração.

Passos Detalhados

1. Abra uma nova janela do navegador em modo normal. Se tiver extensões habilitadas, desative-as temporariamente para um teste limpo.
2. Acesse qualquer serviço que mostre os resultados do detector de WebRTC no navegador. Realize o teste. Preste atenção a dois tipos de endereços: candidato IP público e candidatos IP locais (por exemplo, endereços do tipo 192.168.x.x, 10.x.x.x ou 172.16-31.x.x).
3. Compare o IP público que o detector de WebRTC mostrou com o "IP através do proxy" que você anotou anteriormente. Se forem diferentes e o WebRTC mostrar seu IP real de provedor — este é o vazamento.
4. Se candidatos IP locais forem visíveis de forma explícita, isso também é um potencial vazamento de configuração, pois o site pode usar esses dados para correlar impressões digitais e unicidade.
5. Faça uma captura de tela dos resultados ou anote os endereços públicos e locais exibidos no teste. Depois, você poderá comparar com o resultado após a configuração.

Pontos Importantes

• Teste cada navegador separadamente. Não tire conclusões com base em um único navegador para todos.
• Os resultados dependem das versões e funcionalidades habilitadas, especialmente no Safari e no Firefox.

Dica: Realize o teste no modo incógnito e no modo normal. Às vezes, as extensões estão desativadas em modo incógnito e você verá um panorama "limpo".

✅ Verificação: Você possui os resultados registrados antes da configuração: quais endereços públicos e locais WebRTC estão sendo exibidos atualmente. Este é o ponto de partida.

Possíveis Problemas e Soluções

• Problema: Testes mostram resultados diferentes em diferentes sites. Causa: A metodologia de verificação, cache e política de WebRTC é diferente. Solução: Compare vários resultados; o importante é que seu IP público real não apareça em nenhum lugar.
• Problema: Nenhum dado é exibido. Causa: O site não obteve permissão ou o teste é incorreto. Solução: Atualize a página, permita o acesso aos dispositivos de mídia quando solicitado ou use um testador alternativo.

Passo 3: Fechando o WebRTC nos navegadores normalmente

Objetivo da etapa: minimizar ou eliminar o vazamento através das configurações internas do navegador sem extensões, sempre que possível.

Navegadores baseados em Chromium (Chrome, Edge, Opera, Brave e outros)

1. Abra as configurações do navegador. Vá para a seção "Privacidade e Segurança" — "Configurações do Site" — "Permissões Adicionais" (os nomes podem variar). Encontre as seções relacionadas à câmera e microfone. Embora isso não desative o WebRTC, proibir o acesso a mídia reduzirá o número de casos reais em que a troca ICE é iniciada durante a chamada.
2. Abra a página de flags (chrome://flags ou edge://flags, opera://flags). Procure o parâmetro que lida com a anonimização de IPs locais no WebRTC (por exemplo, "Anonymize local IPs exposed by WebRTC" ou "mDNS ICE candidates"). Mude para Enabled. Reinicie o navegador.
3. Verifique as políticas corporativas (se aplicável). Em ambientes com políticas, você pode definir o WebRtcIpHandlingPolicy como "default_public_interface_only" ou "disable_non_proxied_udp" para proibir conexões UDP diretas não proxied. Para usuários comuns, esse caminho não é obrigatório.

Firefox (Desktop)

1. Na barra de endereços, digite about:config e confirme que entende os riscos.
2. Localize o parâmetro media.peerconnection.enabled e, se não precisar de chamadas via navegador, defina como false para desativar completamente o WebRTC. Se precisar de chamadas, não desative globalmente e use os seguintes parâmetros.
3. Defina media.peerconnection.ice.no_host como true, para não expor endereços IP locais como candidatos ICE.
4. Defina media.peerconnection.ice.default_address_only como true, para limitar os candidatos apenas aos endereços padrão, e não a todas as interfaces.
5. Defina media.peerconnection.ice.obfuscate_host_addresses como true, para habilitar o ocultamento de endereços locais com mDNS.
6. Reinicie o Firefox.

Safari (macOS, iOS/iPadOS)

1. No macOS, habilite o menu "Desenvolvimento" (Safari — Preferências — Avançado — Mostrar menu "Desenvolvimento" na barra de menu).
2. Abra "Desenvolvimento" — "Funcionalidades Experimentais" e verifique as opções relacionadas aos candidatos ICE mDNS. Habilite mDNS ICE-candidates, para que IPs locais não sejam expostos diretamente.
3. Em Configurações do Site, limite o acesso à câmera e microfone para sites desnecessários, para que o WebRTC não seja ativado sem necessidade.
4. No iOS/iPadOS, em "Configurações — Safari — Extensões/Funcionalidades Experimentais", habilite opções semelhantes aos candidatos ICE mDNS, se disponíveis, e limite o acesso à câmera/microfone para sites.

⚠️ Atenção: A desativação total do WebRTC pode quebrar chamadas web, compartilhamento de tela e alguns aplicativos corporativos. Se você precisar da funcionalidade de chamadas, use um modo com mDNS e limitação de candidatos ao invés de uma desativação completa.

Dica: Se você frequentemente muda entre redes e interfaces (como Ethernet e Wi-Fi), verifique os flags e o about:config após atualizações no navegador. Às vezes, as atualizações redefinem os recursos experimentais.

✅ Verificação: Execute o teste da etapa anterior. IPs locais não devem ser exibidos abertamente, e o candidato público não deve coincidir com o IP real do provedor. Se o teste ainda mostra o IP real, passe para a etapa com extensões.

Possíveis Problemas e Soluções

• Problema: Não há opção de anonimização de IPs locais nas flags do Chromium. Causa: Versão do navegador ou política. Solução: Use uma extensão para WebRTC e o uBlock Origin, ou aplique uma política em nível de sistema (disponível para administradores).
• Problema: O Firefox quebra chamadas após desabilitar o WebRTC. Causa: Você desativou media.peerconnection.enabled. Solução: Ative novamente e aplique os parâmetros pontuais no_host, default_address_only e obfuscate_host_addresses.

Passo 4: Fechando o WebRTC com Extensões

Objetivo da etapa: alcançar um comportamento previsível em navegadores baseados em Chromium e adicionar um nível adicional de proteção.

Passos Detalhados

1. Abra o catálogo de extensões do seu navegador. Encontre e instale uma extensão que gerencie a política do WebRTC (como WebRTC Control ou WebRTC Leak Prevent). Essas extensões permitem definir uma estratégia: "Default public interface only", "Disable non-proxied UDP", etc.
2. Após a instalação, abra as configurações da extensão. Escolha a política que oculta candidatos locais e proíbe UDP não proxied. Na interface, isso pode ser chamado de "Disable non-proxied UDP" ou "Use default public interface only". Salve as configurações.
3. Instale também o uBlock Origin. Abra suas configurações e no menu "Opções" ative a função que previne vazamentos de WebRTC (se disponível na sua versão). Isso é uma proteção adicional.
4. Reinicie o navegador ou desligue e ligue as extensões, para garantir que a política foi aplicada.

Pontos Importantes

• A extensão deve ser permitida em janelas normais e privadas, se você estiver testando ambos os modos. Verifique as permissões das extensões.
• Alguns sites que usam WebRTC para streaming podem funcionar de maneira diferente após a aplicação de uma política rigorosa. Avalie o impacto sobre seus cenários.

⚠️ Atenção: Não instale extensões de fontes não confiáveis. Direitos de acesso aos "dados dos sites" concedem à extensão amplas possibilidades. Use apenas lojas e desenvolvedores verificados.

Dica: Se você alterna entre várias políticas (como para chamadas e para trabalho diário), crie dois perfis de navegador: "Trabalho (WebRTC rígido)" e "Chamadas (WebRTC moderado)".

✅ Verificação: Repita o teste de WebRTC. O IP público não deve coincidir com o seu IP real de provedor, e IPs locais não devem ser visíveis abertamente. Se o resultado for negativo — o vazamento foi fechado.

Possíveis Problemas e Soluções

• Problema: A extensão em modo incógnito não funciona. Causa: Proibido no modo privado. Solução: Abra "Gerenciar Extensões" e habilite "Permitir no modo incógnito".
• Problema: O site de chamadas parou de se conectar. Causa: UDP não proxied foi proibido. Solução: Crie um perfil separado com uma política mais suave ou desmarque temporariamente para o domínio desejado.

Passo 5: Configurando o WebRTC em Navegadores Anti-detecção

Objetivo da etapa: alcançar resultados reproduzíveis ao trabalhar com vários perfis, onde a impressão digital e a estabilidade do comportamento são importantes.

Passos Detalhados (esquema universal)

1. Abra o painel de controle do seu navegador anti-detecção (por exemplo, AdsPower, Dolphin{anty}, Incogniton, GoLogin, Octo Browser, etc.).
2. Crie um novo perfil ou abra um existente. Encontre a seção "WebRTC" ou "Configurações de Rede/Mídia/Fingerprints" dentro do perfil.
3. Escolha a estratégia do WebRTC: geralmente são oferecidas opções como "Disabled", "Real", "Altered/Fake", "Default public interface only", "Proxy only" ou semelhantes. Se não precisar de chamadas e quiser máxima privacidade, escolha "Disabled" ou uma opção que exclua candidatos locais e proíba UDP não proxied. Se precisar de chamadas, utilize "Proxy only" ou "public interface only" mais mDNS, se suportado na base de navegador do anti-detector.
4. Especifique o proxy dentro do perfil: tipo (HTTP(S) ou SOCKS5), host, porta, nome de usuário/senha. Teste a conexão através do botão "Testar" integrado (geralmente é presente na configuração do perfil).
5. Salve o perfil e inicie-o. Abra um testador de WebRTC e certifique-se de que o IP real não está visível. Registre o resultado.

Pontos Importantes

• Nos anti-detetores, frequentemente existem mimetizações de parâmetros WebRTC: geração de ufrag, senha ICE, campos SDP. Tente não modificar os valores sem necessidade. Seu objetivo é bloquear o vazamento, e não desviar da norma de maneira exótica.
• Políticas WebRTC idênticas em perfis diferentes fornecerão um comportamento consistente nos sites.

Dica: Crie um template de perfil com a política WebRTC e o proxy já configurados. Clone-o para novos perfis de trabalho. Isso economiza tempo e reduz o risco de erros.

✅ Verificação: Dentro de cada perfil iniciado, repita o teste. O IP público real não deve aparecer, e os candidatos IP locais devem estar ocultos ou substituídos por mDNS.

Possíveis Problemas e Soluções

• Problema: O perfil mostra resultados diferentes de WebRTC a cada vez que é iniciado. Causa: Geração aleatória de parâmetros. Solução: Fixe o modo WebRTC como "Disabled" ou "Proxy only" e não altere entre as execuções.
• Problema: A extensão no perfil conflita com a política do anti-detector. Causa: Configuração duplicada. Solução: Use a política do anti-detector ou a extensão, mas não altere simultaneamente as duas.

Passo 6: Conectando ao Proxy Móvel

Objetivo da etapa: combinar corretamente o fechamento do WebRTC com o proxy móvel, garantindo que a configuração final seja limpa e estável.

Passos Detalhados

1. Prepare o acesso ao proxy móvel. No painel do provedor (por exemplo, mobileproxy.space), verifique as configurações de conexão: endereço do nó, porta, tipo de proxy, autenticação (nome de usuário/senha ou lista de IPs permitidos).
2. Se o provedor suporta rotação de IP, determine como e quando a rotação ocorre. Certifique-se de que conseguirá reproduzir o teste após a rotação.
3. No navegador ou perfil anti-detecção, especifique o proxy móvel: tipo (HTTP(S)/SOCKS5), host, porta, nome de usuário/senha. Faça o teste de conexão (normalmente, há um botão "Verificar proxy" ou abra qualquer site e confirme que a página carrega).
4. Assegure-se de que a política do WebRTC já está configurada: no navegador baseado em Chromium — através da extensão e da flag de anonimização de IPs locais; no Firefox — através do about:config, no anti-detector — através do perfil.
5. Abra um testador de WebRTC. Verifique qual IP público é mostrado como candidato. Deve corresponder ao IP do proxy móvel, e não ao seu IP real do provedor. Os IPs locais devem estar ocultos ou apresentados através de mDNS.

Pontos Importantes

• Um proxy móvel muitas vezes fornece maior variabilidade de rede (operadora, região). Isso é útil, mas aumenta as exigências relativas à previsibilidade das configurações do WebRTC.
• Tente não alterar vários parâmetros de uma só vez: primeiro feche o vazamento, depois ative a rotação de IP e outras funções.

Dica: Se a geolocalização é importante em suas tarefas, fixe a região do lado do proxy móvel (por exemplo, no mobileproxy.space) e não misture redes Wi-Fi e móveis ao usar ao mesmo tempo.

✅ Verificação: O teste mostra o IP público do proxy móvel, e não o seu real. Endereços locais não são visíveis diretamente. Após a rotação do IP do proxy móvel, o teste deve mostrar o novo IP público, enquanto o IP real do provedor permanece oculto.

Possíveis Problemas e Soluções

• Problema: O teste mostra o IP real, não o móvel. Causa: UDP não proxied está habilitado ou a extensão não foi aplicada. Solução: Verifique a política do WebRTC na extensão e no about:config, reinicie o navegador, e certifique-se de que o perfil está utilizando o proxy móvel.
• Problema: Após a rotação do IP, o resultado é instável. Causa: Cache ou rotação não realizada a tempo. Solução: Limpe o cache, reinicie o navegador, aguarde a rotação confirmada no painel do provedor e, em seguida, repita o teste.

Passo 7: Técnicas Adicionais de Controle em Nível de Navegador e Sistema

Objetivo da etapa: aumentar a previsibilidade do comportamento sem comprometer a legitimidade e a usabilidade.

Passos Detalhados

1. Verifique as permissões dos sites: Configurações — Privacidade e Segurança — Configurações do Site — Permissões. Limite o acesso automático à câmera e ao microfone; exija consentimento antes do uso.
2. Crie um perfil separado para tarefas com maior privacidade. Nesse perfil, use uma política estrita de WebRTC e um número mínimo de extensões.
3. Se você for um administrador, aplique políticas no navegador para definir centralmente a política do WebRTC. Usuários sem privilégios de administrador não precisam deste passo.
4. Verifique após as atualizações: às vezes, navegadores mudam o comportamento padrão de flags do mDNS ou do WebRTC. Faça um teste de controle a cada mês.

Pontos Importantes

• Mesmo com uma política rigorosa, extensões podem ser desativadas em caso de falhas ou conflitos. Verificações regulares são essenciais.
• Navegadores anti-detecção costumam ser atualizados frequentemente. Após a atualização do núcleo, revise o funcionamento do plug-in do WebRTC e dos perfis.

Dica: Estabeleça uma rotina: "Novo perfil — teste de WebRTC imediatamente", "Atualização do navegador — teste de WebRTC imediatamente", "Mudou o proxy ou operadora — teste de WebRTC imediatamente". Isso leva 1 a 2 minutos, mas economiza horas.

✅ Verificação: Você confirmou que a nova rotina organizacional e as políticas estão funcionando: os testes não mostram o IP real em nenhum perfil e após atualizações.

Possíveis Problemas e Soluções

• Problema: Após a atualização, a extensão redefiniu as configurações. Causa: Reset da configuração. Solução: Exporte as configurações da extensão para importar rapidamente em caso de reset.
• Problema: As políticas do navegador não estão disponíveis. Causa: Não há privilégios de administrador. Solução: Use uma estratégia de extensão e perfil sem políticas de sistema.

Passo 8: Diagnóstico Usando Vários Testes

Objetivo da etapa: aprender a verificar resultados por diferentes métodos e identificar discrepâncias.

Passos Detalhados

1. Repita o teste de WebRTC em dois ou três sites diferentes. Verifique que em nenhum lugar seu IP real do provedor aparece e que IPs locais não estão claramente visíveis.
2. Faça um teste de rede simples em nível de DNS. Abra o prompt de comando. No Windows, execute: nslookup -type=txt o-o.myaddr.l.google.com 8.8.8.8. No macOS/Linux, execute: dig +short TXT o-o.myaddr.l.google.com @8.8.8.8. Certifique-se de que o endereço obtido corresponde ao tráfego via rede proxy, se você configurou um proxy ou túnel de sistema. Se o proxy foi configurado apenas no navegador, esse teste pode mostrar seu IP real, o que é normal para o nível de sistema.
3. Teste o acesso à câmera e microfone em sites onde eles são realmente necessários. Verifique se a chamada funciona, caso você tenha optado por uma estratégia "moderada" de WebRTC.

Pontos Importantes

• O teste em nível de DNS não substitui o teste de WebRTC, mas ajuda a entender para onde o tráfego do sistema está indo fora do navegador.
• A métrica principal para nós é que o JavaScript na página não detecte seu IP público real.

Dica: Mantenha um registro dos testes: data, navegador, perfil, resultado, anotações. Isso ajudará a identificar regressões raras após atualizações.

✅ Verificação: Todos os testes no nível do navegador produzem resultados consistentes: o IP real não é revelado, e os IPs locais não são publicados claramente.

Possíveis Problemas e Soluções

• Problema: Testadores diferentes de WebRTC mostram diferentes campos. Causa: Variância na profundidade da coleta. Solução: Foque no que é essencial — a aparição do IP público real ou de candidatos IP locais; não se preocupe com métricas secundárias.
• Problema: Vazamentos aleatórios. Causa: A extensão foi desativada ou a política não foi aplicada. Solução: Reinicie o navegador, verifique as permissões da extensão, repita o teste.

Verificação do Resultado

Checklist do que deve funcionar

• O teste de WebRTC no seu navegador principal não mostra o IP público real do provedor.
• Os endereços IP locais não são visíveis claramente ou são substituídos por candidatos mDNS.
• Se um proxy móvel estiver em uso, o candidato de IP público coincidirá com o IP do proxy móvel.
• Durante a rotação do IP móvel, o resultado no teste muda para um novo IP público, mas não para o IP real do provedor.
• Chamadas e funções necessárias funcionam no perfil com a política moderada de WebRTC (se isso for necessário para sua tarefa).

Como Testar

1. Execute a configuração final: navegador/perfil com o proxy ativado e a política WebRTC.
2. Abra um testador de WebRTC e registre o resultado.
3. Se estiver usando um proxy móvel, se possível, execute a rotação do IP e repita o teste.
4. Compare com as notas originais. Certifique-se de que o IP real não aparece em nenhum caso.

Teste de vazamento de DNS

Para verificação interna em nível de DNS, utilize o princípio geral: execute os comandos do sistema da etapa anterior ou use qualquer serviço confiável de verificação de vazamento de DNS. É importante entender: se o proxy estiver configurado apenas no navegador, o teste de DNS do sistema pode mostrar seu IP real — isso é normal e não significa vazamento de WebRTC no navegador. No contexto deste guia, a fonte primordial de verdade permanece o teste de WebRTC do navegador. Para voltar rapidamente à descrição das verificações de DNS, use o link interno Teste de vazamento de DNS.

Dica: Se você está documentando a equipe em um único documento, insira suas capturas de tela de "antes" e "depois" com comentários. Isso se tornará um padrão e facilitará a integração de novos funcionários.

✅ Verificação: Todos os itens da lista de verificação foram confirmados; nos testes do navegador, o IP real não é revelado; durante a rotação do proxy móvel, apenas o candidato de IP público do proxy muda.

Erros Comuns e Soluções

• Problema: Após todas as etapas, o IP real ainda é visível em um dos testadores. Causa: A extensão não obteve permissões no modo privado ou a política não foi aplicada. Solução: Ative a extensão para janelas privadas, reinicie o navegador, verifique as flags e o about:config, repita o teste.
• Problema: Chamadas no navegador desapareceram. Causa: O WebRTC foi completamente desativado. Solução: Ative o WebRTC, mas oculte os IPs locais e use mDNS; proíba apenas o UDP não proxied.
• Problema: Perfis de anti-detecção dão resultados diferentes. Causa: Diferentes modos do WebRTC ou conjunto diferente de extensões. Solução: Crie um template de perfil, sincronize o modo do WebRTC, registre a lista de extensões.
• Problema: Após a atualização do navegador, o vazamento retornou. Causa: Redefinição de flags/configurações da extensão. Solução: Faça uma auditoria rápida das configurações, importando a configuração salva, e teste novamente.
• Problema: Em um site não há vazamento, em outro há. Causa: A metodologia de teste difere, possivelmente chamando diretamente STUN. Solução: Certifique-se de que "Disable non-proxied UDP" está habilitado, verifique o uBlock Origin e as permissões da extensão.
• Problema: O proxy móvel muda de IP, e o teste às vezes mostra valores intermediários. Causa: A rotação levou tempo, cache. Solução: Aguarde a rotação ser concluída, limpe o cache, atualize a página, repita o teste.
• Problema: Políticas em nível de OS proíbem as flags necessárias. Causa: Política corporativa. Solução: Consulte o administrador ou use um caminho suportado com extensões sem conflitos.

Opções Adicionais

Configurações Avançadas

• Política de Enterprise do Chromium: defina WebRtcIpHandlingPolicy para "default_public_interface_only" ou "disable_non_proxied_udp" centralmente em todas as estações de trabalho.
• Firefox about:config: combine mDNS e proibição de candidatos host para minimizar assinaturas.
• Anti-detectar: fixe a versão do motor e a política do WebRTC no template, para que na atualização do motor você possa rapidamente verificar apenas um perfil exemplo.

Otimização

• Reduza o número de extensões. Um único extensão de WebRTC do perfil e o uBlock Origin são suficientes na maioria dos casos.
• Separe os perfis por finalidade: perfil rigoroso para privacidade, moderado — para chamadas.

O que mais pode ser feito

• Crie um protocolo para a equipe: quem e quando verifica os testes após as atualizações.
• Digitalize os resultados: mantenha logs de testes em um repositório comum, para visualizar a dinâmica e excluir regressões aleatórias.

Dica: Se você frequentemente muda de proxies ou provedores, faça uma pequena lista de verificação com 6–8 itens e mantenha-a à mão. Isso acelera o trabalho diário.

FAQ

1. Por que o WebRTC ainda pode mostrar meu IP real através do proxy?

Porque o WebRTC utiliza candidatos ICE e STUN, que podem funcionar à parte do caminho HTTP(S), incluindo UDP não proxied. Sem medidas especiais, o navegador pode expor seu IP público do provedor.

2. É suficiente apenas desativar o WebRTC?

Isso é radical e resolve o vazamento, mas quebra chamadas e alguns aplicativos. É melhor usar modos com mDNS, limitação de IPs locais e proibição de UDP não proxied, se você precisar da funcionalidade do WebRTC.

3. Precisamos de uma extensão e alterações nas flags ao mesmo tempo?

Frequentemente, uma extensão é suficiente. No entanto, ter mDNS habilitado no nível das flags mais a extensão oferece um resultado mais previsível, especialmente após atualizações.

4. Qual modo escolher em um navegador anti-detecção?

Se não precisar de chamadas — "Disabled" ou "Proxy only" com proibição de UDP não proxied. Se precisar de chamadas — "public interface only" mais mDNS e controle de permissões de mídia.

5. Como entender que IPs locais não são visíveis?

Na linha dos candidatos ICE, não deve haver padrões familiares como 192.168.x.x, 10.x.x.x, 172.16–31.x.x. Em vez disso, podem haver identificadores mDNS.

6. Eu tenho um proxy móvel, mas o teste ainda mostra meu IP real.

Verifique a extensão e a política do WebRTC. Na maioria das vezes, o UDP não proxied está habilitado ou a extensão não está ativa neste perfil ou no modo privado.

7. Qual o benefício de um provedor de proxy móvel como mobileproxy.space?

Ele fornece um IP móvel estável com a possibilidade de rotação e escolha de região. Juntamente com o WebRTC configurado corretamente, você obtém uma configuração limpa e previsível sem vazamentos do IP real.

8. É necessário fazer o teste de vazamento de DNS?

Para entender o nível do sistema, é útil, mas o teste de WebRTC do navegador é a chave neste guia. O teste de DNS não substitui a verificação do WebRTC. Use o link interno Teste de vazamento de DNS para navegação rápida à seção com detalhes.

9. O que fazer se tudo falhar após a atualização do navegador?

Verifique as flags do mDNS e a política da extensão, reinstale extensões se necessário, e repita os testes. Mantenha o export do config à mão.

10. É possível eliminar completamente quaisquer riscos de vazamento?

Na prática, reduzir a zero para cenários de navegador. Siga a rotina: extensão, flags, verificação após atualizações e controle de perfis. Isso proporciona um resultado estável sem vazamentos.

Conclusão

Você percorreu todo o caminho: aprendeu o que é um vazamento de WebRTC e por que é perigoso através de proxies, como verificar vazamentos, corrigi-los usando as ferramentas do navegador, com extensões e em navegadores anti-detecção, e como vincular tudo isso corretamente ao proxy móvel e realizar testes finais. Agora você tem uma lista de verificação, um conjunto de soluções prontas para problemas comuns e uma compreensão de como manter a configuração operacional após atualizações.

O que fazer a seguir: aplique as configurações a todos os navegadores e perfis com os quais trabalha; automatize a rotina de testes; se necessário, implemente políticas centralizadas na organização. Se você usa proxies móveis, como o mobileproxy.space, padronize a rotação e a documentação dos resultados, para que qualquer funcionário possa replicar a configuração sem erros.

Para onde desenvolver: estude as características de proteção contra outras vazamentos de contexto (Canvas, AudioContext, WebGL), investigue políticas de isolamento de sites, estratégias de cookies e gerenciamento de impressões digitais. Mas a base — a ausência de vazamentos do IP real através do WebRTC — você já configurou e testou.