Uma avaliação gratuita é uma quantidade pequena e fixa de banda, e a forma como você a utiliza determina se você aprende algo com ela. A abordagem comum é apontá-la para um endpoint de teste que retorna um endereço IP, confirmar que o endereço muda e concluir que os proxies funcionam. Isso não diz quase nada do que você precisava saber, e é o motivo pelo qual as pessoas acabam comprando um plano que as decepciona nos sites com os quais realmente se importam.
Uma avaliação existe para responder a uma pergunta: isso vai funcionar nos meus alvos, no meu volume, nos meus mercados? Tudo abaixo está organizado para que as respostas de maior valor venham primeiro, caso sua banda acabe antes da sua curiosidade.
Antes de começar: prepare-se para não desperdiçá-la
Dois minutos de preparação mudam o valor de uma avaliação.
Anote seus alvos reais, os sites ou endpoints reais dos quais seu projeto depende, e inclua o mais difícil em vez de apenas os fáceis. Anote seus mercados reais, os países específicos e, se relevante, as cidades de que você precisa. E decida com antecedência como é uma aprovação, por exemplo noventa por cento de respostas válidas no seu alvo principal a partir de dois países, porque um limite definido previamente evita que você racionalize um resultado medíocre depois.
Em seguida, configure a validação de resposta antes da sua primeira requisição. Este é o passo de preparação mais importante de todos, porque uma página de desafio, um resultado vazio, uma listagem truncada ou um redirecionamento para uma página genérica frequentemente chegarão com um status 200, e um teste que conta códigos de status vai reportar sucesso sem coletar nada. Verifique um marcador que só aparece em uma página genuinamente boa: um elemento esperado, um tamanho de conteúdo plausível, um campo conhecido no JSON. Os modos de falha estão catalogados em detectando conteúdo bloqueado ou falso.
import requests
PROXY = "http://customer-USERNAME-country-us:PASSWORD@p.shifter.io:443"
PROXIES = {"http": PROXY, "https": PROXY}
def is_valid(html):
return "product-price" in html and len(html) > 20_000 # your own marker
ok = 0
for i in range(100): # a small, honest sample
r = requests.get("https://your-real-target.example/item/123",
proxies=PROXIES, timeout=20)
if r.status_code == 200 and is_valid(r.text):
ok += 1
print(f"validated success rate: {ok}%") # not "did it return 200"Teste um: taxa de sucesso nos seus próprios alvos
Este é o teste que importa mais do que todos os outros combinados, e deve consumir a maior parte da sua avaliação.
Execute uma amostra significativa, algo em torno de cem requisições, contra cada alvo real e meça a taxa de sucesso validada em vez da taxa HTTP. Inclua seu alvo mais defendido, porque um pool que lida bem com os sites fáceis e falha no difícil não é um pool que resolve seu problema. Se você tem uma configuração atual, execute a mesma amostra por meio dela como controle, para que você esteja comparando em vez de adivinhando.
Fique atento ao padrão em que o sucesso começa alto e se degrada ao longo da execução, já que isso geralmente significa que seu ritmo é agressivo demais para o alvo, e não que o pool é ruim, e é uma lição de ritmo que vale a pena aprender durante uma avaliação, e não em produção.
Teste dois: precisão geográfica
Se o seu projeto depende de localização, e a maioria depende, verifique se o país que você solicita é o país que você recebe, e verifique todos os mercados de que você realmente precisa, em vez de um exemplo conveniente. Um pool pode ser excelente em uma região e escasso em outra, e o número global em uma página de marketing não diz nada sobre o lugar específico de onde você coleta.
Vale a pena verificar dois níveis. Primeiro, o endereço de saída tem geolocalização no país solicitado, amostrado em requisições suficientes para detectar inconsistência. Segundo, e mais significativo, o site alvo se comporta como se você estivesse lá: moeda correta, preços locais, catálogo regional, resultados de busca locais. O segundo é o teste real, porque os bancos de dados de geolocalização de IP e a opinião do próprio alvo nem sempre concordam, e é a opinião do alvo que você está pagando para obter. Se você precisa de segmentação em nível de cidade, verifique-a na granularidade de cidade, em vez de presumir que a precisão de país a implica.
Teste três: o pool é o que ele afirma ser
Gaste um pouco de banda amostrando endereços de saída e agrupando-os pela organização a que pertencem. Provedores de internet de consumo são o que você quer ver; uma parcela significativa de organizações de hospedagem ou nuvem indica que o pool está diluído com espaço de datacenter, o que importa porque esses endereços são os que seus alvos tratarão como tráfego de máquina. O método completo está em identificando IPs de datacenter vendidos como residenciais, e a distinção subjacente está em a anatomia de um IP residencial.
Enquanto estiver nisso, observe que a qualidade do endereço é um eixo separado do tipo de endereço: um pool genuinamente residencial que tenha sido abusado a ponto de ter má reputação ainda vai atrair desafios, que é exatamente o que o teste um mede de fora.
Teste quatro: comportamento de sessão
Se alguma parte do seu projeto envolve um fluxo em múltiplas etapas, uma busca com paginação, um login, um contexto de localização que você define e depois lê, confirme duas coisas durante a avaliação.
Confirme que a rotação de fato rotaciona quando você não especifica uma sessão, e confirme que uma sessão fixa de fato mantém um endereço pelo tempo necessário. Em seguida, execute uma das suas sequências reais de múltiplas etapas de ponta a ponta em uma sessão mantida, porque um pool pode parecer bom em requisições únicas e ainda assim quebrar um fluxo se o endereço mudar no meio dele. Se o seu trabalho precisa de muitas identidades mantidas simultaneamente, verifique se sessões concorrentes se comportam de forma independente.
Teste cinco: desempenho e consumo
Dois números para registrar, ambos afetando o plano que você acabará comprando.
Latência e vazão importam se o seu trabalho é sensível ao tempo, então meça os tempos de resposta pelo proxy nos seus alvos reais em vez de em um endpoint de teste de velocidade, e espere que o residencial seja mais lento do que uma conexão direta, já que o tráfego percorre um caminho mais longo. O que importa é se é rápido o suficiente para o seu trabalho, não se corresponde a um benchmark de datacenter. A abordagem de medição está em testando velocidade, taxa de sucesso e precisão de localização.
Em seguida, meça bytes por requisição, que é o número que transforma uma estimativa de plano em uma decisão de plano. Multiplique sua média medida pelo seu volume mensal esperado de requisições e você terá uma cifra real de banda, em vez de um palpite, que é o insumo para estimar a banda mensal. Se o resultado for desconfortável, este também é o momento de descobrir que buscar um endpoint de dados em vez de renderizar páginas completas move você para um nível abaixo, como abordado em cortando custos de banda de proxy.
Com o que não gastar uma avaliação
Algumas coisas queimam banda sem ensinar nada.
Testar contra um endpoint de eco de IP prova que o proxy está conectado, o que é uma verificação de sanidade de trinta segundos, não uma avaliação. Testar apenas alvos fáceis lisonjeia o pool e esconde a resposta de que você precisava. Executar um volume enorme contra um único alvo não mede qualidade e pode fazer com que esse endereço seja bloqueado, o que então faz o pool parecer pior do que é. E julgar com base em um punhado de requisições dá apenas ruído, já que uma amostra de cinco requisições não consegue distinguir um pool de noventa e cinco por cento de um de setenta por cento.
Mais uma coisa: não avalie um provedor com base em alegações de tamanho de pool. Um número de destaque não é algo que uma avaliação consiga verificar, e não é o que determina seus resultados. Densidade nos seus países e sucesso nos seus alvos, isso sim é o que determina.
Uma lista de verificação para a avaliação
- Prepare-se: alvos reais incluindo o mais difícil, mercados reais, um limite de aprovação, e validação de resposta escrita antes da primeira requisição.
- Meça a taxa de sucesso validada, aproximadamente cem requisições por alvo, com um controle se você tiver um.
- Verifique a geografia em cada mercado de que você precisa, tanto a localização de saída quanto o comportamento do alvo.
- Amostre organizações de saída para confirmar que o pool é genuinamente residencial.
- Execute um fluxo real de múltiplas etapas em uma sessão fixa, e confirme a rotação sem uma.
- Registre latência e bytes por requisição, e então dimensione seu plano a partir de números medidos.
Se uma avaliação passar nos seis pontos com os seus próprios alvos, a decisão de plano se torna aritmética em vez de um salto de fé. O conjunto completo de escolhas em nível de plano está em escolhendo o plano de proxy residencial certo.
Conclusão
Uma avaliação é banda, e banda gasta em um endpoint de eco de IP responde a uma pergunta que você não tinha. Gaste-a nos seus alvos reais com validação de resposta real, verifique os mercados de que você realmente precisa, confirme que o pool é genuinamente residencial, execute um fluxo de sessão se o seu trabalho tiver um, e registre bytes por requisição para que seu plano seja dimensionado a partir de medição. Defina o limite de aprovação antes de começar. Faça isso e você termina a avaliação sabendo se o produto resolve o seu problema, que é a única coisa para a qual uma avaliação serve.
Se você quiser executar essa lista de verificação, pode fazê-lo em uma avaliação gratuita dos proxies residenciais Shifter, com segmentação por país e cidade, rotação por padrão, e sessões fixas para os fluxos que precisam delas. Quando os números voltarem, o preço por GB significa que o plano que você escolher segue a banda que você mediu, em vez de um palpite.