Resumo do conteúdo: quando uma verificação de negócio mostra vazamento WebRTC, você deve primeiro parar de fazer login ou operar contas importantes, fechar o ambiente atual e, em seguida, verificar a conexão do proxy, o modo WebRTC, o IPv6 e as regras de bypass do proxy. Para usuários do MostLogin, o procedimento mais comum é: confirmar que o proxy foi detectado com sucesso, definir o WebRTC do ambiente como Private (Privado); se o negócio não precisar de áudio/vídeo na web ou comunicação ponto a ponto, também pode escolher Disabled (Desativado); ao mesmo tempo, ative as regras de proteção que impedem a abertura do ambiente quando o proxy falha.
É importante notar que a presença de múltiplos endereços na página de teste nem sempre significa vazamento. Somente quando a página expõe seu IPv4 público real, seu IPv6 público real ou quando aparece uma saída de rede que não deveria estar associada a esse ambiente é que se trata de um problema de alto risco que requer ação imediata.
O que é WebRTC? Por que ele pode contornar as configurações comuns de proxy?
WebRTC significa Web Real-Time Communication, ou seja, “comunicação em tempo real pela web”. Ele permite que os navegadores realizem chamadas de voz, videoconferências, compartilhamento de tela e transmissão de dados ponto a ponto diretamente. Muitas ferramentas online de reunião, atendimento ao cliente e colaboração o utilizam.
Para encontrar um caminho de conexão viável entre dois dispositivos, o WebRTC usa o ICE para coletar vários “endereços candidatos”. Esses candidatos podem incluir endereços de interfaces de rede do dispositivo, endereços públicos mapeados descobertos por servidores STUN e endereços retransmitidos por servidores TURN. A documentação da MDN sobre tipos de candidatos ICE mostra que candidatos host representam endereços diretos do dispositivo, candidatos srflx são gerados pela interação STUN/TURN e candidatos relay são retransmitidos via TURN. Explicação da MDN sobre conectividade WebRTC
Essa é a razão fundamental dos vazamentos WebRTC: uma página web cria uma conexão WebRTC via JavaScript e lê os candidatos ICE. Se o navegador não restringir corretamente esses endereços, as informações de rede visíveis pela página podem ser inconsistentes com a saída do proxy. A MDN também indica claramente que os endereços candidatos ICE podem vazar informações sobre a localização do dispositivo e a topologia de rede além do esperado pelo usuário, podendo ser usados para fingerprinting do navegador. Notas de segurança da MDN sobre RTCIceCandidate
Entendimento simples: as requisições web comuns podem passar pelo proxy, mas o WebRTC também busca separadamente caminhos para comunicação em tempo real. Quando esses dois caminhos não são controlados de forma unificada, o site pode ver simultaneamente o “IP do proxy” e “outro conjunto de endereços de rede”.
O que configura realmente um vazamento WebRTC?
Para determinar se há vazamento, não basta verificar se apareceu um IP na página de teste — é necessário comparar “o que a página exibiu” com “o que o ambiente deveria exibir”.
| Resultado do teste | Configura vazamento? | Avaliação de risco |
|---|---|---|
| O IP público WebRTC é consistente com o IP do proxy detectado pelo MostLogin | Geralmente não | Normal, continue verificando DNS, fuso horário e consistência de localização geográfica |
| Exibe o IP público real da banda larga residencial, rede corporativa ou hotspot móvel | Sim | Alto risco, pare imediatamente as operações de conta no ambiente atual |
| O proxy é IPv4, mas a página de teste mostra IPv6 público real | Sim | Alto risco, indica que o IPv6 pode não estar coberto pelo proxy |
Mostra endereços privados como 192.168.x.x, 10.x.x.x | Nem sempre | Trata-se de exposição de informações da rede local, geralmente não é vazamento de saída pública, mas aumenta as informações de fingerprint de rede |
Mostra nomes aleatórios com .local | Geralmente não | Na maioria dos casos, é resultado do uso de mDNS pelo navegador para ocultar endereços locais |
| Mostra múltiplos endereços, mas todos pertencem ao mesmo proxy ou saída de retransmissão | Geralmente não | Pode ser IPv4, IPv6 ou diferentes tipos de candidatos ICE |
Navegadores modernos podem usar nomes de host mDNS no lugar de IPs de rede local. Portanto, se a página de teste mostrar algo como uma string aleatória terminada em .local, isso não significa necessariamente que o IP público real foi exposto. O que realmente importa é: apareceu o endereço público real do ISP que você vê ao consultar fora do ambiente do navegador?
Quais são as consequências de um vazamento WebRTC?
1. Conflito entre a identidade do proxy e a identidade de rede real
Suponha que um ambiente MostLogin esteja configurado com um proxy de Nova York, EUA, e as requisições web também mostrem o IP de Nova York, mas o WebRTC exponha o IP público da rede local do usuário. A plataforma não vê um ambiente de navegação natural e estável, mas sim dois sinais de conexão com localizações geográficas ou provedores de rede conflitantes.
Isso não prova automaticamente quem o usuário é, mas enfraquece o efeito de isolamento do proxy e pode se tornar um dos sinais para controle de risco anormal, verificação adicional ou revisão de sessão.
2. Diferentes ambientes de navegador podem ser associados pelo mesmo IP real
Uma equipe cria vários ambientes independentes para diferentes projetos de teste, cada um usando um proxy diferente. Se todos esses ambientes expuserem o mesmo IP público do escritório via WebRTC, o site pode obter um sinal de associação repetido entre os ambientes. Mesmo que Cookie, Canvas e WebGL estejam isolados, a saída de rede real repetida pode reduzir a independência entre os ambientes.
3. Exposição de localização aproximada, provedor de rede e estrutura de rede
O IP público geralmente pode ser usado para determinar país, região a nível de cidade e provedor de rede; endereços de rede local, IPv6 ou diferentes interfaces de rede também podem revelar mais características da topologia de rede. O IP geralmente não pode determinar sozinho um endereço exato ou nome real, mas pode ser combinado com contas, cookies, fingerprints de dispositivo e dados de comportamento.
4. Videoconferências e chamadas web podem enfrentar um dilema entre “privacidade e usabilidade”
Desativar completamente o WebRTC pode reduzir a superfície de exposição, mas videoconferências, atendimento de voz, compartilhamento de tela ou transferência direta de arquivos que dependem do WebRTC podem não funcionar corretamente. Portanto, a abordagem correta não é desativá-lo em todos os cenários, mas escolher entre Private e Disabled de acordo com as necessidades do negócio.
Após o navegador anti-detecção mostrar vazamento WebRTC, faça primeiro estes 6 passos
Passo 1: Pausar operações sensíveis no ambiente atual
Se a página de detecção já mostrou o IP público real, não continue fazendo login, pagamentos, publicando conteúdo ou trocando contas importantes. Primeiro, registre os resultados do teste, incluindo:
- O endereço exibido pela detecção normal de IP;
- O IPv4 e IPv6 exibidos pela detecção WebRTC;
- O endereço do proxy e país/região configurados no MostLogin;
- Horário do teste, nome do ambiente e se está usando VPN.
Registrar as informações serve para localizar o problema. Não é recomendável manter senhas de proxy, cookies de conta ou outras credenciais nas capturas de tela.
Passo 2: Estabelecer uma comparação entre “IP real — IP do proxy — IP do WebRTC”
Realize três grupos de verificações sem abrir contas de negócio:
- Em um navegador comum e sem proxy, consulte o IPv4 e IPv6 públicos atuais como linha de base da rede real.
- Na aba
Proxydo MostLogin, clique na verificação de IP do proxy e registre a saída esperada. - Abra o ambiente correspondente e leia os endereços candidatos na página de teste WebRTC.
Se o resultado do WebRTC for igual ao primeiro grupo de linha de base, mas não for igual ao segundo grupo de saída do proxy, pode-se confirmar basicamente que há vazamento. Se o resultado for consistente com o IP do proxy, é mais provável que seja uma exibição normal de candidatos WebRTC.
Passo 3: Corrija primeiro o proxy, depois ajuste o WebRTC
As configurações de WebRTC não podem corrigir um proxy que já está offline, com falha de autenticação ou configurado incorretamente. Acesse a página de edição do ambiente alvo, abra a aba Proxy, verifique o protocolo, host, porta, usuário e senha, e execute a verificação de IP do proxy. O guia oficial de criação de ambiente do MostLogin indica que atualmente podem ser configurados direct, http, https e socks5, e é possível verificar o resultado da conexão com “Check proxy IP”. MostLogin: Criar um novo ambiente
Somente após a verificação do proxy ser bem-sucedida e o país e cidade exibidos corresponderem ao esperado, prossiga para o próximo passo.
Passo 4: Escolher o modo WebRTC adequado no MostLogin
O caminho de operação geralmente é:
Profiles (Lista de ambientes) → Selecionar o ambiente alvo → Edit (Editar) → Fingerprint (Fingerprint) → WebRTC
A documentação oficial atual do MostLogin mostra as configurações suspensas de WebRTC, onde Private é usado para ocultar o IP real mantendo a funcionalidade WebRTC, e também pode oferecer Public e Disabled. MostLogin: Instruções de configuração de fingerprint WebRTC
| Modo | Cenário recomendado | Observações |
|---|---|---|
| Private | Navegação diária, áudio/vídeo no navegador, atendimento ao cliente ou ferramentas de colaboração | Escolha prioritária; após salvar, é obrigatório testar novamente e confirmar que o resultado é consistente com o proxy |
| Disabled | Ambientes que não precisam de videoconferência, voz ou funcionalidade P2P | Fronteira de privacidade mais clara, mas funcionalidades relacionadas do site podem falhar |
| Public | Apenas para testes de desenvolvimento ou compatibilidade que necessitem explicitamente de candidatos de rede reais | Não adequado para ambientes de proxy que precisam ocultar a saída de rede real |
Para ambientes de proxy comuns, recomenda-se usar primeiro Private. Somente quando o negócio não depende de WebRTC, ou o modo Private ainda não atende aos requisitos de isolamento, teste o Disabled. Não conclua que há vazamento apenas porque a página de teste mostra “WebRTC enabled”; o importante é qual endereço ele retornou.
Passo 5: Ativar a proteção contra falhas do proxy e verificar a lista de bypass do proxy
Acesse as configurações globais ou as preferências de ambiente do MostLogin e ative as seguintes proteções:
- Não abrir o ambiente quando houver erro de rede do proxy;
- Não abrir o ambiente quando o IP do proxy mudar;
- Não abrir o ambiente quando o país ou região do IP do proxy mudar;
- Não abrir o ambiente quando a sincronização falhar.
O MostLogin descreve oficialmente essas configurações como proteções pré-inicialização, sendo que a proteção contra erro de rede do proxy previne a exposição acidental do IP real do ISP quando o proxy falha. MostLogin: Profile preferences
Também verifique Settings → Proxy bypass. Os domínios adicionados à lista de bypass usarão a rede local diretamente, em vez do proxy do ambiente atual. A documentação oficial do MostLogin também indica claramente que os domínios de bypass serão acessados por conexões locais reais. MostLogin: Proxy bypass Se sites de teste, domínios de autenticação ou seus domínios de API/CDN estiverem aqui, remova as exceções desnecessárias e salve.
Passo 6: Fechar completamente e reabrir o ambiente para realizar testes cruzados
Após salvar as configurações, feche todo o ambiente do navegador e reinicie-o, não apenas atualize a página de detecção. Use pelo menos duas páginas de detecção independentes para verificar:
- O IP público normal exibido pelo navegador;
- O IPv4 nos candidatos WebRTC;
- O IPv6 nos candidatos WebRTC;
- Se DNS, fuso horário, idioma e localização geográfica são consistentes com a região do proxy.
O critério de aprovação no reteste é: a página de detecção não mostra mais o IPv4/IPv6 público real do ISP; os endereços públicos exibidos pelo WebRTC devem ser consistentes com o proxy, saída de retransmissão ou comportamento esperado do produto; os resultados permanecem estáveis após reiniciar o ambiente.
Exemplo de uso do MostLogin: Ambiente com proxy de Nova York detectado com IPv6 real
Cenário
Uma equipe de QA de sites multirregionais criou um ambiente MostLogin chamado US-NewYork-QA-01, e a verificação do proxy HTTP mostra IPv4 de Nova York, EUA. Ao abrir a página de teste, o IP normal continua sendo de Nova York, mas a área WebRTC mostra um IPv6 público do provedor local.
Diagnóstico
Este é um vazamento real, não apenas um caso comum de “múltiplos IPs aparecendo”. O motivo é que o proxy HTTP cobre as requisições web IPv4, mas o caminho de rede IPv6 do host não é tratado igualmente, e os candidatos WebRTC ainda podem expor esse endereço.
Tratamento
- Feche o ambiente para evitar continuar testes de login.
- Verifique se o serviço de proxy suporta explicitamente IPv6; se não suportar, use uma solução de proxy que cubra completamente IPv4/IPv6, ou desative o caminho IPv6 desprotegido na camada de rede do sistema.
- Edite o ambiente e em
Fingerprint → WebRTCselecione Private. - Ative “Não abrir o ambiente quando houver erro de rede do proxy”.
- Verifique a lista de bypass do proxy e remova domínios de exceção relacionados ao site de teste.
- Reabra o ambiente para reteste e confirme que o IPv6 real não aparece mais.
Neste cenário, apenas trocar o modo WebRTC pode eliminar temporariamente a detecção, mas a cobertura do IPv6 pelo proxy continua sendo o problema fundamental, portanto ambos devem ser verificados.
Exemplo de uso do MostLogin: A página de teste mostra .local, mas o IP público é consistente com o proxy
Cenário
O usuário está usando um proxy do Reino Unido, o IP normal e o endereço público WebRTC mostram ambos o Reino Unido; a página de teste também lista uma string aleatória terminada em .local, e o usuário pensa erroneamente que houve vazamento.
Avaliação
.local é geralmente uma manifestação do uso de nomes mDNS pelo navegador para ocultar endereços de rede local. Desde que não apareça o IPv4/IPv6 público real do ISP e os candidatos públicos sejam consistentes com o proxy do Reino Unido, não se pode concluir apenas com base no .local que há vazamento de IP real.
Tratamento
Mantenha a configuração Private atual, registre o resultado e use outra página de teste para verificação cruzada. Neste momento, trocar de proxy com frequência, randomizar fingerprints ou reconstruir o ambiente pode, na verdade, introduzir mais variações em um ambiente de teste que deveria estar estável.
Exemplo de uso do MostLogin: Videoconferência não conecta após desativar o WebRTC
Cenário
A equipe de suporte remoto definiu o WebRTC como Disabled e as chamadas de atendimento web e o compartilhamento de tela não conseguem estabelecer conexão.
Tratamento
Altere o ambiente para Private, mantenha a conexão do proxy funcionando e reteste os endereços WebRTC. Se o IP real não aparecer mais e o áudio/vídeo voltar a funcionar, é possível conciliar funcionalidade com isolamento de rede. Se o vazamento persistir no modo Private, investigue o protocolo do proxy, IPv6, divisão de VPN e domínios de bypass, em vez de escolher Public diretamente para restaurar a chamada.
Se o vazamento persistir após a correção, onde pode estar o problema?
Se o MostLogin já está configurado como Private, mas o teste ainda mostra o IP público real, continue verificando na seguinte ordem:
- O proxy não está realmente conectado. Quando as credenciais estão erradas, o nó expirou ou o servidor proxy está offline, o navegador pode não obter a saída esperada.
- O IPv6 não está coberto. O proxy processa apenas IPv4, e o host ainda pode acessar a rede pelo IPv6 real.
- Regras de bypass do proxy. O site de teste ou subdomínios relacionados estão configurados para conexão direta.
- Divisão de VPN ou conflito de rotas do sistema. Usar simultaneamente VPN, proxy do sistema e proxy do ambiente pode criar diferentes caminhos de rede.
- Processos do ambiente antigo ainda em execução. Após salvar as configurações, o ambiente não foi completamente fechado e os processos antigos ainda usam a configuração original.
- Extensões do navegador alteram o comportamento de rede. Extensões de VPN, proxy, privacidade ou WebRTC podem entrar em conflito com as configurações do ambiente.
- Falso positivo ou cache da página de detecção. Use uma segunda página de teste e reinicie o ambiente para verificar, não tire conclusões com base em um único resultado.
Se duas páginas de teste independentes mostrarem estavelmente o mesmo endereço público real, salve capturas de tela sem credenciais sensíveis, o número da versão do MostLogin, sistema operacional, protocolo do proxy e etapas de reprodução, e entre em contato com o suporte do MostLogin ou o provedor de proxy.
Lista de verificação de proteção contra vazamento WebRTC
Após o primeiro uso de cada novo ambiente, troca de proxy, atualização do cliente ou mudança de rede, execute a seguinte verificação:
Perguntas frequentes
O teste WebRTC mostra múltiplos IPs, isso significa necessariamente vazamento?
Não necessariamente. Múltiplos resultados podem vir de IPv4, IPv6, interfaces de rede local, mapeamento STUN, retransmissão TURN ou mDNS. Somente quando aparece o IP público real do ISP, saídas de rede não relacionadas ou endereços públicos claramente conflitantes com a localização do proxy é que se deve considerar como vazamento de alto risco.
Após usar um proxy, qual IP o WebRTC deve mostrar?
O ideal é que a página web não veja seu IP público real do ISP. Dependendo do navegador e da política do produto, a página de teste pode mostrar o endereço do proxy, endereço de retransmissão, candidatos locais ocultos ou nenhum endereço disponível. O critério não é “só pode aparecer um IP”, mas sim “não pode aparecer a saída pública real que precisa ser isolada”.
MostLogin: devo escolher Private ou Disabled?
Quando áudio/vídeo web, chamadas de atendimento ou compartilhamento de tela são necessários, escolha prioritariamente Private e reteste; quando não usar WebRTC de forma alguma, pode escolher Disabled. O Disabled pode afetar funcionalidades do site, portanto não é a solução ideal padrão para todos os ambientes.
O vazamento WebRTC pode expor nome real e endereço exato?
Geralmente, não é possível obter diretamente nome real ou endereço exato apenas pelo IP, mas o IP público pode revelar região aproximada e provedor, e também pode ser combinado com contas, cookies, fingerprints do navegador e registros de comportamento para formar pistas de associação mais fortes.
Já ocorreu um vazamento, basta corrigir as configurações?
A correção só impede a exposição posterior, não pode revogar os dados que o site já recebeu. Para negócios importantes, verifique o período em que o vazamento ocorreu, os ambientes afetados e os registros de login; quando necessário, encerre sessões antigas, atualize credenciais e observe se a plataforma apresenta verificações anormais.
Conclusão
O cerne do vazamento WebRTC não é “se o WebRTC está ativado”, mas sim se ele expõe endereços públicos reais inconsistentes com o ambiente de proxy atual. Após detectar anomalias, pause primeiro as operações sensíveis e complete a comparação com os três grupos de dados: IP real, IP do proxy e IP do WebRTC. Os usuários do MostLogin geralmente podem resolver o problema verificando a conexão do proxy, selecionando WebRTC Private, ativando a proteção contra falhas do proxy, limpando regras de bypass desnecessárias e verificando o caminho IPv6.
Incluir a verificação WebRTC no processo fixo antes de colocar um novo ambiente em produção é mais confiável do que tentar corrigir após o aparecimento de anomalias nas contas. Após cada troca de proxy, rede ou versão do cliente, é necessário testar novamente para garantir que a saída de rede e o fingerprint do navegador permaneçam consistentes a longo prazo.
