Vendemos proxies em Geonode, por isso considere o que se segue como um conselho de uma parte interessada e verifique-o com base nos seus próprios registos. Eis a posição sincera da parte interessada: testar os seus proxies revela, na maioria das vezes, problemas que são da nossa responsabilidade, não sua, e um cliente que testa adequadamente é um cliente que abre tickets de suporte aos quais temos de responder. Ainda assim, preferimos que faça os testes. Um conjunto de proxies que se degrada silenciosamente e só é descoberto três semanas depois por um colega que pergunta por que razão o painel de preços parece errado é pior para todos do que um monitor que avisa alguém logo no primeiro dia.
O instinto que a maioria das pessoas tem em relação ao teste de proxies é que se trata de uma etapa de configuração. Adquire-se o acesso, colam-se as credenciais num verificador, aparece um visto verde e o assunto fica encerrado até que algo exploda visivelmente. Esse modelo está errado de uma forma específica e dispendiosa: os proxies normalmente não falham ao recusarem-se a funcionar. Falham ao continuarem a funcionar, mas devolvendo algo subtilmente diferente do que se pediu. O seu scraper continua a funcionar. A sua métrica de taxa de sucesso mantém-se nos 99%. Os dados subjacentes ficam incorretos.
Este artigo é o complemento do nosso guia prático sobre como testar proxies, que aborda os comandos e os scripts. Aqui, respondemos à questão prévia — por que se dar ao trabalho, quanto custa, na verdade, não testar e como decidir quanto teste é suficiente.
O modo de falha que ninguém prevê
Pense no que significa «um proxy está avariado» para o seu código. Quase todos os clientes de proxy tratam isso como um evento ao nível da ligação: o handshake TCP falha, a autenticação é rejeitada com um código 407, o túnel CONNECT é recusado, ocorre um timeout. Essas são as falhas que a sua lógica de repetição de tentativas já lida, porque levantam exceções e as exceções são fáceis de detetar.
Agora considere as falhas que não levantam nada:
- O proxy liga-se, mas o nó de saída foi reatribuído de Manchester para Frankfurt. A sua recolha de preços do Reino Unido é agora uma recolha de preços alemã. Todos os campos são analisados corretamente. Todos os valores estão errados.
- O site de destino começou a servir ao teu conjunto de proxies uma página simplificada em vez de o bloquear — uma resposta anti-bot comum e racional, porque um bloqueio suave desperdiça o orçamento do scraper sem lhe fornecer qualquer informação. O teu analisador encontra o contentor que espera, extrai três produtos em vez de quarenta e reporta sucesso.
- O proxy começou a injetar ou a remover um cabeçalho. As tuas solicitações continuam a ser concluídas. O site agora classifica-te de forma diferente do que fazia na semana passada.
- A resolução de DNS mudou discretamente do proxy para a tua própria máquina. O teu tráfego sai através do proxy; as tuas consultas de DNS saem através do teu ISP. Tem a geolocalização de um país e o comportamento do resolvedor de outro, e qualquer site que correlacione os dois vê agora uma incompatibilidade que um utilizador real nunca produziria.
- O ponto final está ativo, é rápido, está corretamente localizado e é partilhado com alguém que passou a manhã a atacar incessantemente o site exato que lhe interessa. Não há nada de errado na sua configuração. A sua taxa de sucesso nesse alvo específico é agora de 40%.
Nenhuma destas situações gera um erro. É esse o problema. A lógica de repetição de tentativas, os disjuntores de circuito e os alertas de taxa de erro assentam todos no pressuposto de que a falha é evidente, mas as falhas que mais importam no funcionamento do proxy são, por definição, silenciosas.
O que realmente avaria e com que frequência
É útil distinguir as coisas que mudam por si próprias das que mudam porque alguém as alterou. Ambas as categorias precisam de ser testadas, mas em intervalos diferentes.
| O que muda | Por que muda | Como se percebe sem testar | Atraso típico na deteção |
|---|
| Geolocalização do IP de saída | O ISP reatribui um bloco; a base de dados de geolocalização atualiza-se segundo o seu próprio calendário | Uma parte interessada consulta dados regionais anormais | Semanas |
| Reputação do IP num alvo | O endereço foi utilizado de forma agressiva por outra pessoa | A taxa de sucesso diminui apenas nesse alvo | Dias a semanas |
| Bloqueio suave ou filtragem de conteúdo | O alvo altera a sua postura anti-bot | O número de linhas diminui | Semanas |
| Desvio na assinatura do cabeçalho ou TLS | Atualizou uma biblioteca de cliente | A taxa de bloqueio aumenta após uma implementação | Dias |
| Fuga de DNS | Alteração de configuração, predefinição da biblioteca, rede de contentores | Normalmente nunca, até que haja correlação contra si | Indefinido |
| Falha efetiva do terminal | O fornecedor renova a infraestrutura | Imediatamente, ocorre a falha | Minutos |
A última linha é a única que a maioria das configurações deteta, e é a menos prejudicial. Essa inversão — a falha mais evidente ser a menos dispendiosa — é a razão pela qual os testes têm uma reputação intuitiva tão má. As pessoas lembram-se de que o seu monitorização detetou o ponto final inativo e concluem que a monitorização funciona.
A geolocalização merece atenção especial porque é aquilo em que as pessoas mais confiam e em que menos deveriam confiar. O mapeamento de IP para localização não é um facto da Internet; é uma base de dados comercial que faz inferências a partir de dados de encaminhamento, registos de registo e feeds autopublicados. A MaxMind, um dos fornecedores mais utilizados, refere na sua página de pedidos de correção que os envios de geofeeds são «importados e revistos uma vez por dia útil» e que as correções pontuais são «normalmente revistas no prazo de 1 a 2 dias úteis», e que as correções aceites são «incorporadas na próxima versão da base de dados». Os feeds auto-publicados estão padronizados na RFC 8805, e as redes que os publicam constituem a minoria que cumpre as regras.
A consequência prática: duas consultas de geolocalização podem, legitimamente, apresentar resultados diferentes para o mesmo IP, e o site que está a rastrear pode estar a utilizar uma terceira base de dados que discorda de ambas. Um proxy vendido como britânico pode ser considerado britânico pelo seu verificador e irlandês pelo seu alvo. Só o teste em relação a algo semelhante ao seu alvo real revela isso.
O custo de não realizar testes, expresso em dinheiro
Os argumentos abstratos sobre a qualidade dos dados não resistem ao confronto com uma discussão sobre o orçamento; por isso, eis a aritmética numa forma que resiste.
Suponha que execute uma tarefa de monitorização de preços em 50 000 páginas de produtos diariamente, utilizando largura de banda residencial a cerca de 0,79 $/GB, com uma média de 400 KB por página após a compressão. Isso equivale a cerca de 20 GB e aproximadamente 16 $ por dia de tráfego — ou seja, 480 $ por mês. Modesto.
Agora, suponha que 15% do seu conjunto de dados tenha sofrido um desvio geográfico e que só descubra isso quatro semanas depois. Acontecem três coisas, sendo que o custo do tráfego é a menor delas:
O tráfego é desperdiçado. Cerca de 72 dólares da despesa mensal foram gastos em dados que tem de descartar. Irritante, mas não fatal.
A repetição do processo custa o mesmo novamente. Não é possível colmatar a lacuna; tem de voltar a extrair a fatia afetada assim que tiver proxies a funcionar, o que significa pagar duas vezes pelas mesmas linhas e esperar que o trabalho termine.
As decisões tomadas com base nos dados errados são a verdadeira conta a pagar. Quatro semanas de preços regionais que, silenciosamente, se referiam à região errada equivalem a quatro semanas de posicionamento competitivo construído no mercado de outrem. Ninguém especifica isso numa fatura, e é precisamente por isso que esta situação se mantém durante tanto tempo.
Há um quarto custo que é mais difícil de quantificar e mais fácil de sentir: a confiança. Na primeira vez que se descobre que um conjunto de dados esteve errado durante um mês, todos os números subsequentes desse fluxo são postos em causa. Reconstruir essa confiança demora mais tempo do que reconstruir o próprio fluxo.
Em comparação com isso, o custo dos testes resume-se a algumas centenas de pedidos por dia para um ponto final conhecido. Com largura de banda cobrada com base no tráfego, um ciclo de validação custa cêntimos. Com a tarifação por IP, não custa absolutamente nada além do tempo necessário para o escrever. É um dos raros casos em que a opção mais barata e a opção correta são a mesma opção.
Falhas silenciosas classificadas de acordo com o tempo que permanecem ocultas
Nem todo o silêncio é igual. Classificar as falhas de acordo com o tempo que podem persistir sem serem detetadas indica o que deve ser testado de forma mais rigorosa, e esta classificação é mais útil do que a classificação por gravidade.
Permanecem ocultas indefinidamente: fugas de DNS, inconsistências nos cabeçalhos, discrepâncias nas impressões digitais TLS. Estas podem nunca produzir um sintoma visível. Alteram a forma como é classificado, e essa classificação é invisível do seu ponto de vista. Se um site decidir que o seu tráfego é automatizado e responder servindo conteúdo em cache ligeiramente desatualizado, não o descobrirá a partir dos seus registos — apenas comparando a sua saída com um pedido feito a partir de um navegador comum.
Fica oculto durante semanas: desvio de geolocalização e remoção de conteúdo. Ambos acabam por vir à tona quando alguém repara que os dados parecem estranhos, o que constitui um mecanismo de deteção cuja latência se mede pelo tempo que demora um ser humano a suspeitar.
Fica oculto durante dias: Deterioração da reputação num alvo específico. Este caso aparece nas métricas de taxa de sucesso, mas apenas se segmentar essas métricas por alvo. A taxa de sucesso agregada em doze sites absorverá facilmente a queda de um site para 40% e continuará a ser considerada saudável.
Não fica oculto: Pontos finais inativos, falhas de autenticação, tempos de espera esgotados. O seu sistema de tratamento de erros existente deteta estes problemas logo na primeira solicitação.
O padrão é suficientemente claro para servir de regra geral: quanto mais a falha se assemelha ao sucesso, mais tempo dura e mais custa. Teste na ordem inversa à intensidade com que uma coisa falha.
Testar antes de comprar versus testar durante a execução
Trata-se de atividades diferentes com objetivos distintos, e confundir as duas é um erro comum.
Os testes pré-compra respondem à pergunta: este conjunto de servidores é adequado para o meu público-alvo? São realizados numa versão de avaliação, com um volume reduzido, nos sites que realmente lhe interessam. A forma errada de o fazer é utilizar um verificador de proxy genérico e comparar as marcas verdes — todos os fornecedores passam nesse teste, incluindo aqueles que irão falhar na produção. A forma correta é selecionar uma amostra representativa da sua carga de trabalho real e submetê-la ao teste. Se um fornecedor oferecer um período de teste (o nosso inclui 1 TB de tráfego residencial para novas contas, e ofertas semelhantes são padrão no mercado), esse período de teste existe precisamente para este fim e deve utilizar cada gigabyte em pedidos realistas, em vez de o gastar em httpbin.org.
Os testes operacionais respondem a uma questão diferente: algo mudou desde ontem? São executados continuamente, numa pequena amostra fixa, e todo o seu valor reside na diferença. Um teste operacional que apenas indica o estado atual mal vale a pena ser executado. Um que indique que o estado atual difere do da semana passada vale imenso.
Esta distinção é importante porque o segundo tipo de teste é muito mais fácil de justificar e, no entanto, é frequentemente ignorado. Os testes pré-compra parecem fazer parte da devida diligência e as pessoas realizam-nos. Os testes operacionais parecem ser um encargo adicional e as pessoas abandonam-nos após o primeiro mês sem incidentes.
O que um teste deve realmente verificar
Um teste que verifica se «o pedido foi bem-sucedido» é praticamente inútil, por todas as razões acima referidas. Um conjunto de verificações útil é curto, mas específico.
| Verificação | Deteta | Com que frequência |
|---|
| O IP de saída está no país e na região esperados | Desvio de geolocalização | Em cada execução |
| O corpo da resposta contém um marcador conhecido como estável proveniente do alvo | Bloqueios suaves, remoção de conteúdo | Em cada execução |
| A contagem de linhas ou itens está dentro do intervalo esperado | Respostas parciais | Em cada execução |
| A resolução de DNS ocorreu através do proxy | Fuga de informação | Diariamente |
| Os cabeçalhos da solicitação chegam tal como foram enviados | Injeção e remoção de conteúdo | Semanalmente |
| Taxa de sucesso por alvo, não agregada | Deterioração da reputação | Continuamente |
| Percentis de latência, não médias | Degradação ocultada por solicitações rápidas | Continuamente |
Vale a pena aprofundar dois destes pontos.
Segmente sempre por alvo. Um único valor agregado da taxa de sucesso é o erro de monitorização mais comum neste domínio. Doze alvos a 99% e um a 40% resultam numa média que parece aceitável. Todas as métricas que registar devem ser por alvo.
Percentis, não médias. As distribuições de latência do proxy têm caudas longas por natureza — alguns nós de saída estão em ligações residenciais com características residenciais. Uma média de 800 ms pode corresponder a um conjunto uniformemente aceitável ou a um conjunto bimodal, em que um terço das suas solicitações demora quatro segundos. A dispersão p50/p95/p99 indica qual das situações se verifica, e apenas a segunda requer ação.
A implementação concreta de tudo isto — os scripts, os endpoints, os comandos — encontra-se no nosso guia de testes de proxy.
Integrar os testes no pipeline, em vez de os manter à margem
A razão pela qual os testes acabam por ser abandonados quase nunca é o facto de as pessoas decidirem que são desnecessários. A razão é que o conjunto de testes se encontra num script separado que alguém tem de se lembrar de executar, e a memória é um recurso renovável que se esgota.
Os testes que sobrevivem são aqueles que não podem ser ignorados. Três padrões funcionam:
Validar as primeiras N respostas de cada tarefa. Antes de a execução principal prosseguir, recupere algumas páginas e verifique-as em relação às suas asserções. Se a geolocalização estiver errada ou se faltar o marcador, interrompa antes de gastar a largura de banda. Este é o padrão de maior valor porque falha rapidamente precisamente na execução que, de outra forma, produziria um mês de dados incorretos.
Verifique as invariantes dentro do analisador. Se uma página de categoria nunca teve menos de vinte itens, considere um número inferior a vinte como um erro, em vez de um resultado. Os analisadores são onde as falhas silenciosas se tornam permanentes, por isso é aí que a proteção deve ser colocada.
Mantenha um alvo «canário». Uma página, estável, que recupere num horário fixo através do mesmo conjunto de servidores. Quando o «canário» muda e a página não, algo no seu caminho mudou. Um «canário» é barato e transforma a observação humana de que «os dados parecem estranhos» num alerta com data e hora.
Nada disto requer uma estrutura de testes ou um novo serviço. Requer que as verificações sejam estruturalmente impossíveis de esquecer, o que é uma propriedade de design e não um problema de disciplina.
Quando os testes são uma perda de tempo
Preferimos dizer isto de forma clara do que ver-vos a criar um sistema de monitorização de que não precisam.
Tarefas pontuais. Se vai extrair dados uma única vez, esta semana, e nunca mais, um sistema de validação elaborado custa mais do que a própria tarefa. Dê uma olhadela no resultado. Se parecer correto, provavelmente está. Todo o argumento a favor dos testes assenta na variação ao longo do tempo, e não há tempo para isso.
Alvos pequenos, estáticos e que se comportam bem. Sites que não utilizam medidas anti-bot e que acedes algumas centenas de vezes por dia não são locais onde os proxies se deterioram. O tratamento básico de erros é adequado.
Proxies de centro de dados com uma alocação estável, especificamente para geolocalização. Os blocos de endereços de centro de dados são atribuídos a um fornecedor e permanecem fixos, pelo que o argumento da variação na geolocalização é muito mais fraco do que no caso dos conjuntos residenciais. A reputação continua a ser importante e precisa de ser monitorizada, mas pode testar a localização com muito menos frequência. Se o seu trabalho não necessita de características residenciais, esta é uma das várias razões pelas quais a largura de banda de centros de dados — a nossa começa nos 0,14 $/GB, com o preço calculado com base no tráfego em vez de por IP — é frequentemente a aquisição mais sensata.
Antes de ter um scraper funcional. Testar proxies isoladamente, quando o fluxo de trabalho ainda não existe, produz marcas verdes sem qualquer significado. Construa o sistema e, só depois, teste-o de ponta a ponta.
E o caso-limite honesto: se o seu trabalho não for sensível ao país de onde a solicitação parece provir e não for sensível a bloqueios, talvez nem precise de proxies. Preferimos dizer-lhe isto aqui do que vender-lhe algo que não irá utilizar. Os preços que indicamos são verificados em relação à nossa própria página de preços a partir de setembro de 2026; verifique os valores atuais antes de os incluir no seu orçamento, incluindo os nossos.
Perguntas frequentes
Com que frequência devo testar os meus proxies?
Depende do que está a testar. A conectividade é testada implicitamente em cada pedido. A geolocalização e a integridade do conteúdo justificam uma verificação no início de cada tarefa, ou diariamente se as tarefas forem executadas de forma contínua. O comportamento dos cabeçalhos e do DNS raramente muda e apenas quando algo na sua pilha de aplicações muda, pelo que, normalmente, basta uma verificação semanal — além de após cada atualização de dependências.
Os verificadores de proxy online gratuitos são suficientemente bons?
São bons para uma coisa: confirmar se um ponto final está ativo e indicar o endereço que este devolve. Não conseguem dizer-lhe como o seu destino trata esse endereço, que é a questão que importa. Um proxy pode passar em todos os verificadores públicos e ser bloqueado pelo único site que lhe interessa. Utilize-os como um teste preliminar, nunca como validação.
Por que razão o meu proxy mostra um país diferente do que o fornecedor prometeu?
Normalmente porque a base de dados de geolocalização que está a consultar difere daquela que o fornecedor utiliza, ou porque o bloco de endereços foi reatribuído e as bases de dados ainda não foram atualizadas. Nenhuma das situações é necessariamente desonesta — a geolocalização por IP é uma inferência, não um facto, e diferentes fornecedores atualizam-se em intervalos diferentes. O que importa é o que o site de destino acredita, por isso teste com um serviço de pesquisa que o destino possa razoavelmente estar a utilizar e verifique mais do que um.
Os testes podem fazer com que os meus proxies sejam bloqueados?
O volume de testes é insignificante quando comparado com o volume de produção, pelo que o risco é reduzido, mas o padrão pode ser relevante. Aceder ao mesmo ponto final a partir de todos os endereços de um grande conjunto em poucos segundos é uma assinatura reconhecível. Escalone as solicitações de validação e utilize uma amostra em vez do conjunto completo.
Qual é a diferença entre um proxy lento e um proxy defeituoso?
A latência é uma característica da rota e, no caso de endereços residenciais, da ligação doméstica efetiva de alguém — um proxy lento pode ser perfeitamente válido. Um proxy defeituoso devolve conteúdo errado ou alterado, revela informações sobre a sua configuração ou é visto com desconfiança pelo seu alvo. Avalie primeiro a taxa de sucesso e a integridade do conteúdo e, em segundo lugar, a latência, a menos que a sua carga de trabalho seja genuinamente sensível à latência.
Devo testar os proxies rotativos de forma diferente dos estáticos?
Sim. Com um endereço estático, está a testar uma única coisa repetidamente, pelo que uma pequena amostra diz-lhe praticamente tudo. Com um conjunto rotativo, cada pedido pode utilizar uma saída diferente, pelo que um único teste dá-lhe informação sobre um único endereço e nada sobre o conjunto. Teste os conjuntos rotativos estatisticamente: recolha uma amostra de pedidos suficiente para caracterizar a distribuição e acompanhe a forma dessa distribuição ao longo do tempo, em vez de se concentrar em qualquer resultado individual.
A minha taxa de sucesso é de 99% — ainda preciso de testar?
Provavelmente sim, e esse número é a razão. A taxa de sucesso mede se as solicitações foram concluídas, não se as respostas estavam corretas. Bloqueios suaves, conteúdo removido e dados da região errada — todos devolvem o código de estado 200. Uma taxa de sucesso elevada acompanhada de uma diminuição no número de linhas é a assinatura clássica de um conjunto que se degradou silenciosamente.
Os testes são importantes se eu utilizar apenas proxies de centros de dados?
Menos, no que diz respeito à geolocalização, uma vez que as alocações dos centros de dados são estáveis. Mas é igualmente importante para a reputação e a integridade do conteúdo: os intervalos de endereços dos centros de dados são mais fáceis de identificar pelos sites e estão frequentemente sujeitos a bloqueios generalizados, pelo que a diferença entre «liga-se bem» e «obtém a página real» pode ser maior do que com endereços residenciais.
Conclusão
O argumento a favor de testar os proxies não é que estes sejam pouco fiáveis. Na maioria das vezes, funcionam. O argumento é que, quando deixam de funcionar corretamente, continuam normalmente a funcionar de forma incorreta, e todos os mecanismos de que já dispõe para detetar problemas foram concebidos para detetar o caso oposto.
Essa assimetria é o cerne da questão. A sua lógica de repetição de tentativas, os seus alertas de erro e o seu painel de tempo de atividade estão todos atentos a sinais de anomalia, mas as falhas mais graves passam despercebidas. Um proxy que devolve um código 200 com conteúdo proveniente do país errado nunca irá acionar nenhum desses mecanismos. Limitar-se-á a produzir dados plausíveis, bem formados, mas errados, até que alguém os analise de perto — e o intervalo até que isso aconteça é medido em semanas.
Os testes eliminam esse intervalo. Não por serem exaustivos, mas por serem específicos: verifique a localização, verifique o conteúdo, segmente por destino e coloque as verificações num local onde não possam ser ignoradas. Trata-se de uma quantidade modesta de trabalho, e é a diferença entre descobrir no primeiro dia e descobrir no trigésimo dia.
