Como checar se o proxy funciona (e se ele vaza o seu IP)

Um proxy pode responder e mesmo assim vazar o seu IP real. Confira o exit, DNS, WebRTC, protocolo e blocklists antes de colocar o endpoint em produção.

Como checar se o proxy funciona (e se ele vaza o seu IP)

Um proxy “funcionar” significa duas coisas diferentes. O gateway precisa aceitar o seu cliente e buscar uma página. O resto do seu dispositivo também precisa parar de expor o IP real. Muitos endpoints passam no primeiro teste e falham no segundo.

Faça essa checagem antes de escalar um plano. Faça de novo depois da rotação. Pools mudam. O firmware do navegador no celular muda. Um teste que passou ontem não é um contrato.

01Confirme o IP de saída primeiro#

Aponte um cliente simples para o proxy. Use o mesmo protocolo e a mesma autenticação que você vai usar em produção. Depois peça uma página que devolve o IP do cliente.

O checador de proxy é o caminho curto para esse primeiro hop. Ele diz se o endpoint responde, qual protocolo falou e qual IP o destino viu. Se essa etapa falhar, pare. Vazamento de DNS não importa em um gateway morto.

Abra Meu IP pelo mesmo proxy. Leia o país, o ASN e o rótulo de hosting versus residencial, se a página mostrar um. Compare com o que você comprou. Um produto “residencial dos EUA” que sai em um ASN de nuvem é o produto errado, não um problema de configuração.

Repita a consulta depois de rotacionar. Um pool misto pode entregar outro país no próximo session id. Se você pagou por proxies dos EUA, a segunda amostra ainda precisa estar nos Estados Unidos.

02Procure vazamentos em volta do proxy#

Um proxy só cobre o tráfego que o seu cliente envia por ele. Todo o resto ainda pode usar a sua rede real.

DNS é o vazamento comum. O navegador pergunta o nome ao seu ISP antes de o proxy ver a URL. Force o DNS pelo proxy ou por um resolvedor que você escolheu. Depois abra uma página de teste de vazamento de DNS com o proxy ligado. Os resolvedores que você vê não devem ser o ISP de casa.

WebRTC é o vazamento específico do navegador. Alguns navegadores abrem uma conexão peer que revela um endereço local ou público mesmo quando o HTTP está no proxy. Desative o WebRTC nesse perfil, ou use uma ferramenta que mostra os endereços candidate. Se um candidate for o seu IP público real, o perfil não é seguro para trabalho com contas.

IPv6 é o vazamento silencioso. Você passou IPv4 pelo proxy e o sistema operacional ainda tem um endereço IPv6 global. Sites que preferem v6 pulam o proxy. Desative o IPv6 nesse perfil ou use um proxy dual-stack que você realmente testou em uma página de echo v6.

Aplicativos podem ignorar o proxy do sistema. Um app nativo pode ignorar a configuração do SO e ir direto. Teste o app, não só o navegador. SOCKS5 na camada do aplicativo costuma ser a única via confiável. Veja SOCKS5 vs HTTP se o cliente oferecer os dois.

03Cheque reputação, não só alcance#

Um IP pode buscar uma página e ainda ser inútil para o seu trabalho. Flags de hosting, blocklists e abuso anterior vivem no endereço.

Se a tarefa é e-mail, cadastro ou qualquer coisa que outras pessoas já queimaram, passe o exit pela blacklist de IP. Um listing é um aviso. Não é um julgamento moral. Pools residenciais compartilhados acumulam listings. IPs dedicados de datacenter também.

Se a tarefa é scraping, busque a URL-alvo de verdade, não só um serviço de echo. Alguns hosts deixam https://httpbin.org passar e ainda bloqueiam a sua página de catálogo. Salve o código de status, o tamanho do body e se um challenge apareceu. Essa é a única nota que importa.

Se a tarefa é QA de geo, compare a página que você queria com a página que você recebeu. Moeda, idioma e catálogo devem bater com o país que você comprou. Um ASN correto com a vitrine errada significa que o site está usando outro sinal.

04Torne a checagem repetível#

Anote os passos. O mesmo cliente, a mesma autenticação, a mesma URL de echo, a mesma URL-alvo, as mesmas páginas de vazamento. Rode quando comprar. Rode quando rotacionar. Rode quando um job começar a falhar.

Registre o IP de saída, o ASN, o protocolo e se DNS ou WebRTC mostrou o seu endereço real. Quando um fornecedor trocar uma porta, você vai saber o que mudou.

Não pule erro de autenticação. Usuário e senha no campo errado parecem um proxy morto. Autenticação por IP-allowlist parece um proxy morto a partir de uma rede de escritório nova. Corrija a autenticação antes de abrir um ticket.

Um proxy que responde, sai no país certo, esconde o seu IP real e devolve a página-alvo está funcionando. Qualquer coisa a menos é uma aprovação parcial. Mantenha fora de produção até fechar a parte que falta.