A maior armadilha das extensões de proxy para navegador é a abrangência: elas só cuidam do tráfego do navegador e ainda podem cair numa conexão direta quando nenhuma regra corresponde. Este artigo classifica as extensões por uso, lista critérios de avaliação como protocolo, autenticação, permissões e manutenção, e traz autotestes para verificar o IP de saída e vazamentos de WebRTC.
As extensões de proxy para navegador têm um limite que costuma passar despercebido: elas só assumem as requisições feitas pelo navegador. Atualizações do sistema, clientes de desktop e outros aplicativos continuam seguindo o caminho original. Defina primeiro com clareza o que você quer colocar no proxy e só depois escolha a ferramenta: isso poupa muita investigação mais adiante.
Comece dividindo por três usos
A necessidade mais comum é a troca por site: fazer alguns domínios passarem pelo proxy e deixar o restante em conexão direta. Esse cenário é controlado por uma lista de regras, e o valor da extensão está na troca rápida e no direcionamento por domínio.
O segundo tipo é o proxy global, em que todo o tráfego do navegador sai por um único ponto de saída. A configuração é a mais simples, mas o custo é direto: se a saída cair, o navegador fica praticamente sem internet, o que torna o uso diário instável.
O terceiro tipo está atrelado a um ambiente: cada perfil de navegador fica fixo em uma saída e os perfis não interferem entre si. É a abordagem usada quando se trabalha com várias contas ou vários projetos em paralelo; aqui a extensão é mais um complemento, porque a saída em si costuma ser configurada em um nível mais baixo.
O que observar ao avaliar uma extensão
O suporte a protocolos vem em primeiro lugar. Proxies HTTP e HTTPS tratam apenas de TCP, enquanto o SOCKS5 é mais geral, mas o suporte a UDP depende da implementação, e muitas extensões deixam o UDP passar direto ou simplesmente o descartam. Isso importa mais adiante, porque está diretamente ligado ao vazamento de WebRTC.
Observe com atenção o método de autenticação. A autenticação com usuário e senha é prática, mas as credenciais guardadas na extensão ficam localmente em texto simples ou com criptografia fraca, de modo que qualquer outra pessoa que use o computador pode lê-las; a autenticação por lista de IPs permitidos não guarda nada na extensão, ao custo de precisar refazer a lista sempre que você troca de rede.
A abrangência é onde os problemas mais aparecem. No modo de regras, domínios que não correspondem a nenhuma regra saem por padrão em conexão direta, e você pode não saber quais domínios a página realmente está requisitando. Depois que um site HTTPS estabelece a conexão, a extensão só vê o domínio, não o caminho específico, então a ideia de direcionar por caminho praticamente não funciona.
Vale olhar também o escopo das permissões. Se uma extensão de proxy pede ainda permissão para ler dados de todos os sites, acessar informações de abas ou usar a área de transferência, pergunte-se se essas permissões têm relação com a função que ela diz oferecer. As atualizações de versão do manifesto das extensões também estão restringindo as interfaces disponíveis, e por isso algumas extensões antigas foram obrigadas a mudar de arquitetura.
Para a atividade de manutenção, não olhe quantas entradas há no changelog, mas se alguém está acompanhando as mudanças do projeto original. Entre as extensões de proxy, a versão de loja do Proxy SwitchyOmega saiu do ar e um fork mantido pela comunidade (como a linha ZeroOmega) assumiu as adaptações seguintes; extensões como o FoxyProxy têm versões em vários navegadores. São apenas exemplos neutros; qual serve melhor continua dependendo dos pontos acima.
O tráfego que ela não cobre
Com a extensão instalada, o navegador passa pelo proxy, mas outros programas no mesmo computador, serviços de atualização em segundo plano e parte do tráfego interno do navegador que não segue o caminho de requisição da extensão podem continuar saindo pela máquina local. A verificação de consistência da rede não pode se limitar ao painel da extensão. Para um isolamento completo, é preciso agir no proxy do sistema ou em um nível superior.
Autoteste: primeiro a saída, depois os vazamentos
O primeiro passo é verificar o IP de saída. Abra algumas páginas que retornam o IP do visitante e a localização, confira uma vez numa janela normal e outra numa aba que atenda às suas regras, e compare se os resultados coincidem. Se a regra indica um proxy e ainda assim aparece o endereço local, a regra não entrou em vigor ou o domínio não correspondeu. Testar vários sites revela casos em que apenas parte das requisições passa pelo proxy.
O segundo passo é verificar o WebRTC. Existem páginas de teste específicas que listam os endereços candidatos locais e públicos obtidos pelo navegador; se entre os públicos aparecer o seu IP real em vez da saída do proxy, o UDP não está passando pelo proxy e os scripts da página ainda conseguem determinar sua localização real na rede.
O terceiro passo é verificar o DNS. Se a localização do servidor de resolução DNS estiver muito distante da localização da saída, alguns sites vão considerar o ambiente anômalo.
O último passo é testar de novo numa janela anônima. Muitas extensões não funcionam por padrão no modo anônimo e precisam ser autorizadas manualmente nas configurações; esquecer esse passo leva a conclusões totalmente erradas.
Decida o uso depois dos testes
Os resultados do autoteste são mais confiáveis do que a documentação da extensão. Depois de alinhar a saída real, a localização da resolução DNS e a exposição de WebRTC, decida se continua usando a extensão ou se desce a saída para um nível mais baixo. Em cenários com vários ambientes em paralelo, o ideal é dar a cada ambiente uma saída própria e fixa, em vez de várias máquinas compartilharem uma única saída.
