Primeiro, confirme quem deu o aviso de VPN
Quando uma página exibe “proxy ou VPN detectada”, é preciso distinguir de qual camada vem a mensagem. O primeiro tipo comum baseia-se em rótulos de provedores de inteligência de IP: o site chama uma API para verificar se o endereço atual aparece em listas de hospedagem, proxy ou redes anônimas e, em seguida, mostra o alerta de risco. O segundo tipo são regras de recusa mantidas pelo próprio site, como permitir apenas endereços de determinados países ou ASNs, ou incluir em lista negra um bloco CIDR inteiro com abuso recente. O terceiro tipo é a detecção do ambiente do navegador, que usa JavaScript para ler candidatos WebRTC, resultados de DNS, fuso horário ou idioma e avisa quando encontra inconsistências com a conexão principal da página.
A base e a confiabilidade desses três julgamentos são completamente diferentes. Rótulos de provedores de dados geralmente vêm de observações históricas e envios de terceiros, com datas de atualização variadas e possíveis entradas expiradas; regras personalizadas do site costumam visar apenas a própria experiência, sem conclusões universais; a detecção do navegador mistura configuração do dispositivo e fatores da rede, nem sempre indicando uma VPN real. Muitas plataformas mostram apenas um aviso genérico, sem evidências específicas ao usuário. Se você tratar o aviso como “confirmação de que você usou VPN”, estará pulando a investigação real.
A maioria dos sites julga com base em requisições visíveis, bancos de endereços e regras próprias, sem conseguir observar diretamente o túnel criptografado entre o dispositivo do usuário e o gateway remoto da VPN. Portanto, o aviso da página não é prova de que seu protocolo VPN foi capturado. Primeiro, verifique os rótulos e suas fontes em Detecção de VPN e proxy; depois, investigue proxy do sistema, túneis corporativos e saídas do provedor para decidir se é problema de configuração, registro antigo ou política do site de destino.
Qual a diferença entre rótulos de VPN, proxy, Tor e hosting?
VPN estabelece uma conexão de rede virtual; o acesso remoto comum usa túnel criptografado, mas nem toda rede chamada VPN é definida por criptografia. Proxy geralmente encaminha requisições para certas aplicações ou protocolos; a criptografia depende da implementação. Nós de saída do Tor representam a linha pela qual o circuito se conecta aos serviços de internet de destino; relays comuns não têm necessariamente papel de saída. O rótulo de hosting é uma pista de classificação de provedores de dados sobre o uso de datacenter ou infraestrutura em nuvem. Esses conceitos podem se sobrepor, mas não são intercambiáveis.
Não se pode igualar hosting a VPN, nem VPN a intenção maliciosa. Empresas usam VPN para acesso remoto de funcionários a sistemas internos como prática comum de segurança; indivíduos usam VPN comercial como escolha legítima de privacidade. Muitos sites recusam endereços de hospedagem porque grande parte do tráfego automatizado e ataques vem de datacenters, não porque o endereço execute um serviço VPN. Por outro lado, endereços de banda larga residencial também podem ser usados temporariamente como saída; a classificação precisa considerar tempo e fonte da observação.
Listas de Tor devem ser lidas junto com fonte, data de atualização e papel do nó: acertar a lista de saída atual significa apenas que aquela fonte registrou esse IP como saída naquele momento; não acertar não prova que Tor não foi usado. Relays comuns, pontes e nós de saída têm funções diferentes; não se pode tratar todos os nós como origem de acesso ao site de destino. Saídas desativadas podem permanecer em bancos de dados por atraso de atualização; consulte a entrada específica em vez de ler apenas um rótulo.
De onde vêm as evidências de classificação de IP?
Os principais caminhos para sites ou sistemas antifraude obterem contexto de IP incluem: registros públicos de alocação de endereços dos registros regionais de internet, bancos de classificação de provedores comerciais, listas de blocos publicadas por provedores de nuvem e observações próprias acumuladas de tráfego de ataque ou comportamento de login. Prefixos públicos oficiais mostram apenas a quem um CIDR foi alocado, como um provedor de nuvem ou ISP, não a localização física atual da conexão nem se há túnel. Fontes autorizadas podem fornecer rótulos de proxy ou Tor, mas a frequência de atualização e as regras de julgamento costumam ser opacas.
RDAP fornece organização registrante, faixa, eventos e contatos do recurso de endereço; ASN identifica o sistema autônomo. BGP mostra anúncios de rota observados; validação de origem RPKI verifica se prefixo e ASN de origem estão em conformidade com autorização válida, sem validar o caminho completo nem o comportamento do usuário. A organização registrante ser provedor de nuvem é pista de contexto, não prova independente de que o dispositivo atual usa VPN; tampouco se pode usar RPKI Valid como evidência de boa reputação do endereço.
Sobre como usar informações de RDAP e ASN para julgamento, consulte RDAP, ASN, BGP e RPKI: como interpretar os dados de um IP. Não dependa de um único rótulo para concluir. Observações de tráfego real podem ter viés: por exemplo, um endereço compartilhado abusado por poucos usuários leva o IP inteiro à lista negra. A classificação de provedores de dados pode misturar blocos de hospedagem com VPN ou omitir novos serviços anônimos. Quanto mais específica a evidência, mais confiável: tempo, fonte, endereço e lista atualizada valem mais do que uma simples conclusão de “alto risco”.
Ordem de investigação quando banda larga comum é marcada
Quando um endereço de banda larga residencial ou hotspot móvel é marcado como proxy, primeiro verifique as configurações do dispositivo. O sistema operacional ou navegador pode ter proxy manual; certas extensões alteram a saída; computadores corporativos podem ter VPN obrigatória ou túnel de segurança. Depois, verifique o ambiente de rede atual: o gateway corporativo pode sair por datacenter; a operadora pode usar CGNAT, fazendo vários usuários compartilharem um IPv4 público. Compartilhamento significa que o mesmo endereço pode ser usado por outros usuários simultaneamente, herdando rótulos de risco.
Alocação dinâmica, transferência de endereço ou mudança de uso podem tornar rótulos antigos inconsistentes com o ambiente atual, mas confirme o registro real de alocação antes de supor que todo endereço dinâmico de banda larga já foi VPS. Consultas públicas RDAP geralmente fornecem registro atual e alguns campos de eventos, sem garantir histórico completo de instantâneos. Você pode verificar com a operadora a data de alocação do endereço e comparar com a entrada da lista e sua data de atualização; ao verificar IPv4 e IPv6 separadamente, confirme que ambas as consultas se referem ao mesmo caminho de serviço.
Esse tipo de investigação precisa combinar as ideias de Como saber seu IP público e verificar se está em CGNAT: confirme se o que você vê é um endereço público ou um endereço interno da operadora. Se for CGNAT, a saída visível externamente é diferente do seu endereço local, e o rótulo de risco pode vir de outros usuários no mesmo pool. Não conclua imediatamente que o banco de dados está errado; talvez seu ambiente realmente tenha um túnel corporativo ou proxy de ponto de acesso. Registre o horário, o tipo de rede e o endereço no momento e compare com o horário de julgamento indicado pelo site para localizar a causa do falso positivo.
Caso ilustrativo: rede corporativa e hotspot de celular
Suponha que um funcionário acesse um serviço restrito a determinada região usando o computador da empresa no escritório e a página exiba "VPN detectada". Ao mesmo tempo, o funcionário conecta o mesmo serviço pelo hotspot do celular e o aviso desaparece. Este caso é totalmente ilustrativo e não representa nenhum teste real. A causa provável é que a saída da rede da empresa passa por uma VPN corporativa ou gateway de segurança, e o endereço de saída está em um segmento de datacenter, marcado pelos provedores de dados como hospedagem ou proxy. O hotspot do celular usa o endereço da operadora, classificado como residencial ou móvel, e não aciona a mesma regra.
Nesse cenário hipotético, é necessário registrar separadamente o tipo de rede, o horário de acesso, o IP de saída de cada um e se existe túnel corporativo no computador da empresa e no hotspot do celular. O computador da empresa pode estar configurado com VPN global ou proxy, e a resolução DNS e a saída de conexão são consistentes; o hotspot do celular não tem essas configurações. Mesmo que os IPs de saída sejam diferentes, não é possível atribuir o problema diretamente a um funcionário específico, pois a saída corporativa geralmente é compartilhada, e muitos funcionários podem usar o mesmo endereço ao mesmo tempo.
Para investigar mais a fundo, pode-se verificar a tabela de rotas ou as configurações de proxy do sistema no computador da empresa para confirmar se o tráfego é forçado por túnel; verificar as informações RDAP do IP de saída—se pertencer a um provedor de nuvem ou segmento de hospedagem, isso corresponde às regras de risco do site. O registro do hotspot do celular serve como grupo de controle, mostrando que a mesma conta e o mesmo dispositivo (se o celular fornecer hotspot, mas ainda usar o navegador do computador) produzem resultados diferentes em redes diferentes. Este exemplo ilustra que o aviso da página pode vir do ambiente de rede, não de o usuário ter ativado VPN ativamente, e com saída compartilhada não é possível atribuir a um indivíduo.
Como comparar quando vários sites de detecção dão resultados conflitantes?
É comum que sites diferentes deem rótulos diferentes para o mesmo IP. Ao comparar, primeiro veja a definição de "proxy" ou "VPN" em cada fonte: alguns consideram segmentos de hospedagem como proxy, outros só reconhecem saídas de VPN comerciais; alguns incluem saídas Tor, outros excluem. Depois, veja o horário de atualização—uma lista pode ter sido atualizada há dois dias, outra acabou de ser escaneada, e os resultados naturalmente diferem. O endereço consultado também influencia: você vê o endereço IPv4 da conexão principal da página, mas na verdade o WebRTC vazou outro endereço IPv6, e o site pode julgar com base em endereços diferentes.
A diferença de cobertura também é importante. Alguns provedores de dados cobrem apenas segmentos de grandes provedores de nuvem e não conseguem identificar VPS pequenos ou proxies emergentes; outros podem marcar um país inteiro ou segmento de operadora como alto risco. O gerenciamento de IPv4 e IPv6 é independente, e o mesmo provedor pode dar resultados diferentes para os dois protocolos. Priorize a consulta de registros brutos, como informações de alocação retornadas pelo RDAP, snapshots de rota BGP ou o horário e motivo específicos de entradas em listas negras, em vez de apenas olhar a pontuação exibida pelo site.
Não faça votação simples entre vários sites—a maioria dizer "sim" não significa fato; nem trate o maior nível de confiança de um site como probabilidade. Confiança é uma pontuação interna do provedor de dados, que pode ser influenciada por abuso histórico ou saída compartilhada, sem calibração pública. A abordagem segura é registrar a definição de cada fonte, o horário de atualização, o endereço consultado e as evidências brutas, e então julgar em conjunto com seu próprio ambiente de rede. Desconhecido não é igual a seguro; a ausência de correspondência pode ser apenas omissão da lista; classificação não é igual a má intenção—um segmento de hospedagem marcado não significa que o usuário tenha comportamento inadequado.
Como exibir ausência de correspondência e desconhecido sem induzir a erro
Os resultados da consulta devem distinguir quatro situações: lista vazia, timeout do serviço, fonte expirada e consulta bem-sucedida sem correspondência, e não podem ser exibidos todos como verde seguro. Lista vazia pode indicar que a fonte de dados atual ainda não incluiu registros relevantes, ou pode ser inicialização incompleta do sistema; timeout do serviço significa que a interface upstream não retornou dentro do tempo acordado, o que não pode ser equiparado a ausência de risco; fonte expirada indica que o timestamp do cache local é anterior à janela de verificação, e os resultados podem não refletir a situação atual; somente quando a consulta é bem-sucedida e retorna explicitamente sem correspondência é que se pode dizer que, sob as regras atuais dessa fonte, não há entrada correspondente. Ausência de correspondência não é garantia de segurança, pois a cobertura da fonte de dados é limitada e nenhuma lista pode esgotar todos os proxies, VPNs ou saídas abusivas.
Informações geográficas de IP, ASN, BGP e RPKI descrevem estimativa de localização, contexto de registro e estado de roteamento, e não são prova de comportamento malicioso. Um ASN anunciar um prefixo não significa que todos os endereços no segmento tenham o mesmo uso; o registro RDAP como provedor de nuvem não significa que o IP atual execute um proxy. A página deve deixar claro se o rótulo descreve infraestrutura, comportamento histórico ou evento em tempo real, para que o leitor saiba a que objeto e período a conclusão se aplica.
A camada de exibição deve expressar diferentes estados com diferentes níveis visuais e deixar claro no texto que "sem registro" não é igual a "aprovado". Por exemplo, o tratamento mencionado em Reputação de IP: como interpretar riscos e bloqueios sugere fornecer entrada para nova tentativa para dados de timeout e expirados, e para ausência de correspondência marcar "não encontrado na fonte atual, mas pode haver risco não coberto". Se o usuário vir um ícone verde, pelo menos precisa saber quais condições específicas correspondem ao verde. A operadora também pode registrar a versão da fonte de dados e o timestamp de cada consulta para facilitar revisões posteriores. Isso evita má interpretação e deixa uma trilha de evidências para recursos.
Taxa de falsos positivos não é acurácia
Suponha um teste com 1000 endereços independentes, sendo 25 proxies reais e 975 não proxies. O classificador marca 30 como proxy, dos quais 20 acertam proxies reais e 10 são falsos positivos; marca 970 como não proxy, dos quais 5 são falsos negativos e 965 são exclusões corretas. Nesse caso, a precisão precision = 20/30 ≈ 0,667, o recall = 20/25 = 0,8, e a taxa de falsos positivos FPR = 10/975 ≈ 0,0103. Essa matriz de confusão é ilustrativa, não é medição deste site, pois requer dados supervisionados com rótulos verdadeiros para calcular.
A acurácia (accuracy) é a proporção de previsões corretas sobre o total: neste exemplo, (20+965)/1000 = 0,985. O valor parece alto, mas a maioria dos endereços da amostra não é proxy. A grande quantidade de verdadeiros negativos pode elevar a acurácia geral e esconder os falsos positivos entre os endereços marcados. Por isso, avalie também o FPR e a precisão (precision). Se o rótulo de proxy levar diretamente ao bloqueio, 10 dos 30 endereços marcados serão bloqueados sem serem proxies. A quantidade de endereços não permite calcular quantos usuários são afetados. Quanto maior o tráfego legítimo, mais solicitações podem sofrer bloqueios indevidos. A proporção de proxies, a sobreposição com listas de bloqueio históricas e a distribuição da população avaliada também podem alterar essas métricas.
Portanto, não se pode simplesmente equiparar a acurácia à taxa de falsos positivos percebida pelo usuário. Para demonstrar a qualidade da detecção, deve-se relatar simultaneamente o tamanho da amostra, a definição de exemplos positivos, a janela de tempo e a distribuição das fontes. Caso contrário, um número alto de acurácia pode mascarar muitos falsos positivos. Para o usuário comum, ao se deparar com o rótulo "proxy", é preciso saber de qual fonte de dados esse rótulo vem, a qual entrada específica ele corresponde e quando foi atualizado pela última vez. Se esse contexto não puder ser fornecido, o próprio rótulo merece desconfiança. Os operadores também não devem aplicar bloqueios com base apenas em um único rótulo.
O teste de vazamento do navegador é outro problema
WebRTC, DNS e detecção de reputação de IP respondem a perguntas diferentes. O WebRTC pode coletar candidatos host, srflx ou relay; o escopo de exposição específico é afetado pela política de privacidade do navegador e pela configuração da rede. As requisições HTTP são transmitidas de acordo com suas regras de proxy e roteamento. O que o teste de DNS geralmente observa é a origem das consultas feitas pelo resolvedor recursivo ao servidor autoritativo do teste. Endereços diferentes podem estar totalmente de acordo com o design; somente comparando com o caminho esperado é possível determinar se há exposição indesejada de informações.
Características do navegador, como fuso horário, idioma e Canvas, não podem, por si só, provar o uso de VPN ou fraude. O resolvedor de DNS e a saída HTTP não estarem na mesma região também não é necessariamente anormal, pois serviços de resolução pública e Anycast afetam a localização. Os resultados podem ser registrados separadamente em Verificação do ambiente do navegador e depois verificados conforme Teste de vazamento de WebRTC, DNS e IPv6: como interpretar em relação ao escopo do proxy, à escolha do resolvedor e aos tipos de candidato WebRTC. Primeiro confirme qual exposição não corresponde ao esperado e depois ajuste a configuração correspondente.
Portanto, quando um site exibir a mensagem "proxy detectado", não se deve atribuir imediatamente a culpa a vazamento do navegador ou erro do WebRTC. Deve-se verificar separadamente os resultados do vazamento do navegador e o rótulo de reputação de IP. Se o teste de vazamento mostrar um endereço local, mas a detecção externa marcar o IP de saída como hosting, pode ser apenas roteamento da operadora ou saída compartilhada. Se ambos forem anormais, considere o dispositivo do usuário ou a configuração da rede. Os operadores podem combinar os dois tipos de sinais, mas devem saber que eles vêm de camadas diferentes e têm mecanismos de erro distintos.
Como enviar uma revisão eficaz ao mantenedor
Ao enviar uma revisão, forneça o endereço público no momento, a hora e o fuso horário, o rótulo específico, o serviço afetado e a fonte dos dados. A prova de alocação de endereço pode vir de registros da operadora aos quais você tem acesso. O RDAP é uma consulta de registro de recursos da Internet, não uma função do próprio roteador, e não substitui o contrato de banda larga pessoal. Em geral, não é necessário enviar logs completos de navegação ou detalhes de mapeamento CGNAT. O alcance da correção pelo mantenedor depende se ele gerencia o banco de dados de classificação, as entradas da lista ou as regras do próprio site.
A explicação de tráfego anormal do Google pode ajudar a distinguir entre rede compartilhada, solicitações automáticas e problemas do navegador. Se encontrar um loop de desafio da Cloudflare, consulte o documento de solução de problemas de desafios para verificar se o navegador é suportado, se scripts ou extensões interferem e se a rede está estável; quando precisar de investigação do site, guarde o Ray ID e o horário da ocorrência. Esses documentos explicam as direções de solução de problemas de cada produto, não são uma promessa genérica de desbloqueio de IP.
Os requisitos de revisão variam entre provedores de dados; alguns aceitam feedback de usuários finais, outros exigem que o administrador do bloco de endereços prove o controle, e deve-se proceder pelo canal de correção específico. Escreva a solicitação como um problema verificável, por exemplo: "a entrada é anterior à alocação atual do endereço, é possível verificar a finalidade?", e anexe as evidências necessárias. Se o bloqueio real for implementado pelo site de destino, pergunte também quais regras e fontes de dados ele usa; modificar uma biblioteca pública não garante atualização imediata em todos os sites.
Como os operadores de sites podem reduzir falsos positivos
Os operadores não devem transformar a classificação de IP em um interruptor binário. Marque separadamente os pesos dos sinais de hosting, VPN, saída Tor, relay etc. e combine com comportamento de login, impressão digital do dispositivo, sessões históricas e frequência anormal para uma decisão abrangente. Ações sensíveis como alteração de senha ou saque podem ter limite mais alto, enquanto a navegação comum pode ser relaxada. Assim, mesmo que um IP seja erroneamente incluído em um pool de proxies, a conta não será bloqueada imediatamente. A classificação em si não é maliciosa; os falsos positivos geralmente vêm de fontes de dados desatualizadas ou saídas compartilhadas, como CGNAT que mapeia muitos usuários domésticos para um único IPv4.
Os operadores podem registrar em logs as regras, a versão da fonte de dados, o horário da correspondência e o resultado da revisão da apelação. Após confirmar um falso positivo, devem corrigir a regra errada ou remover a entrada de bloqueio relevante; se usarem uma regra de permissão temporária, devem limitar o escopo e definir um horário de revisão, e não escrever "remover da lista de permissões" como se fosse desbloquear. A Reputação de uma sub-rede /24: cobertura e risco pode ajudar a entender os registros de endereços vizinhos, mas a quantidade de rótulos por si só não confirma se um bloco é compartilhado, pertence ao mesmo locatário ou tem comportamento malicioso comum.
Não esconda as consequências do bloqueio de um bloco inteiro atrás de um rótulo de IP único. Se você bloquear um prefixo inteiro porque alguns endereços em um /24 têm histórico de proxy, precisa explicar aos usuários. Uma abordagem melhor é acionar captcha ou verificação em duas etapas apenas para ações de alto risco, em vez de negar o serviço. As métricas de monitoramento devem incluir a taxa de falsos positivos por ASN, por fonte de dados e por período, não a precisão média. Assim, quando uma fonte de dados marcar repentinamente os endereços de um ISP em massa como hosting, será possível reverter rapidamente e reduzir a pressão sobre os tickets de suporte.
Perguntas frequentes e limites de aceitação
O tipo de acesso residencial não garante que o endereço não tenha sido usado como saída de proxy; por outro lado, executar um cliente VPN no terminal não significa que o endereço residencial local esteja fornecendo serviço de proxy para terceiros. Após desligar a VPN, novas requisições web podem imediatamente mudar para outra saída, mas o registro do endereço antigo no banco de dados pode não desaparecer; a atualização depende da fonte e da política de retenção. Na revisão, é preciso deixar claro se a comparação é sobre a mudança de rótulo do mesmo IP ou sobre o resultado da consulta de outro endereço após a troca de saída.
A ausência de rótulo não garante o login. Muitos sites têm regras próprias de controle de risco, como exigir que o ASN do IP pertença ao país de destino, não permitir acesso de data centers ou desabilitar túneis IPv6. Mesmo que nenhuma fonte de dados de terceiros seja acionada, o site ainda pode recusar devido a cookies anormais, inconsistência de impressão digital do navegador ou frequência de requisições. Ao ver a mensagem de "detecção de proxy", primeiro separe a verificação do ambiente dos dados de reputação de IP e registre qual página e qual requisição acionaram o desafio. Se o RDAP mostrar que o IP atual pertence a uma linha dedicada corporativa ou servidor em nuvem, mesmo que você não tenha ativado VPN ativamente, é fácil ser marcado como hosting.
A conclusão só pode ser limitada às evidências atuais e ao site específico. O mesmo IP pode ser marcado como proxy no site A e funcionar normalmente no site B, pois cada site tem fontes de dados e limiares diferentes. Ao encontrar problemas insolúveis, continue investigando o fluxo em IP em lista de bloqueio ou CAPTCHA constante: o que fazer, com foco em coletar horário, IP, captura de tela da mensagem e ação de gatilho, e distinga entre bloqueio na camada de rede e captcha na camada de aplicação. Não troque de IP com frequência nem modifique a impressão digital do navegador para contornar, pois isso oculta a causa real e viola os termos de algumas plataformas.
