A taxa de sucesso em um alvo cai, páginas de desafio começam a aparecer, e o primeiro pensamento razoável é que seus IPs foram banidos. Às vezes é exatamente isso. Frequentemente não é, e a diferença importa, porque as respostas são opostas: uma pede para mudar de endereço, a outra pede para desacelerar e não mudar mais nada.
Depois há o ponto estrutural que reformula todo o problema. Em um pool de proxy residencial rotativo, você não é dono dos endereços, então não há endereço para reabilitar. Recuperação significa fazer com que a próxima requisição seja aceita, e a única forma duradoura de fazer isso é descobrir o que fez a última ser recusada.
Primeiro, confirme que é realmente um banimento
Quatro coisas parecem semelhantes vistas de fora, mas significam coisas diferentes.
Um limite de taxa é temporário e relacionado ao ritmo. Geralmente se anuncia com um 429, às vezes com um Retry-After, e se resolve sozinho se você desacelerar. Responder a isso rotacionando endereços é o erro clássico, porque manter o mesmo ritmo a partir de endereços novos é o padrão que transforma um throttling em algo duradouro.
Um bloqueio é uma recusa direcionada ao endereço ou à sessão: uma página de desafio, um 403 persistente, uma interstitial. Este é o caso em que uma identidade nova realmente ajuda.
Um bloqueio suave é o perigoso, porque retorna 200. Uma página de desafio, um resultado genérico, uma listagem truncada ou um redirecionamento para uma landing page podem ser interpretados como se fossem dados, e um pipeline que apenas conta códigos de status vai reportar saúde enquanto não coleta nada. Se você não está validando os corpos das respostas, não consegue nem distinguir isso de um sucesso, conforme detecting blocked or fake content.
Seu próprio bug vale a pena descartar cedo. Uma flag de nome de usuário malformada retorna 407, um filtro excessivamente restrito retorna 502, e uma mudança no parser pode fazer páginas boas parecerem vazias. Nada disso é um banimento.
O teste rápido: requisite a mesma URL a partir de uma rota completamente diferente, idealmente um país diferente, e a partir de uma conexão simples. Se tudo falhar, o alvo está com problemas ou o formato da sua requisição está errado. Se apenas sua rota de produção falhar, você tem um problema real de identidade.
Depois, determine o escopo
O tamanho do problema indica a profundidade da causa.
Uma sessão falhando enquanto outras têm sucesso é rotineiro. Descarte essa sessão, use um identificador novo e continue. Em um pool rotativo isso acontece continuamente e não exige intervenção além do descarte automático descrito em building a proxy manager.
Uma rota se degradando, ou seja, uma combinação de alvo e país cuja taxa de sucesso caiu enquanto outras rotas se mantêm, aponta para algo na forma como você aborda aquele alvo. Este é o caso comum e interessante, e é o que o restante deste texto aborda.
Todas as rotas para um alvo falhando significa que o alvo mudou suas defesas ou está passando por um incidente, e nenhuma quantidade de rotação vai ajudar até que você mude como você olha, não de onde você vem.
Todos os alvos falhando ao mesmo tempo quase nunca é um banimento. Olhe para o seu próprio deployment, suas credenciais e sua rede antes de qualquer outra coisa.
A saúde no nível de rota é o que torna esse diagnóstico rápido em vez de especulativo, o que é o argumento em monitoring proxy health at scale.
A resposta imediata
Quando uma rota está genuinamente bloqueada, o instinto é forçar mais. Faça o oposto.
Pare de enviar para essa rota. Continuar martelando um alvo que está te recusando aprofunda o problema, desperdiça banda em respostas que você não pode usar, e espalha o dano à medida que cada novo endereço que você usa também é sinalizado. Um circuit breaker deve fazer isso automaticamente, em vez de esperar por uma intervenção humana.
Não tente novamente de forma agressiva. Uma tempestade de retries contra um alvo que está bloqueando é a forma mais rápida de transformar um problema pontual em um problema amplo, e é por isso que os retries precisam de orçamentos e classificação, não apenas de um loop, conforme retry and backoff.
Espere. A maioria dos bloqueios tem prazo determinado. Um resfriamento de dezenas de minutos a algumas horas frequentemente limpa o estado por completo, e retomar durante um resfriamento reinicia o contador.
Mude a identidade, não apenas o endereço. Se o bloqueio foi causado pela forma como você se apresenta, e não por de onde você veio, um endereço novo sozinho não muda nada que realmente importava.
Encontrando a causa real
Bloqueios vêm de quatro origens, e vale a pena verificá-las nesta ordem porque essa é aproximadamente a frequência delas.
Ritmo. Muitas requisições, com regularidade excessiva, vindas de poucos endereços. Um espaçamento perfeitamente uniforme já é um sinal em si, já que o tráfego humano é irregular e vem em rajadas. A correção é uma taxa por endereço mais baixa, jitter e distribuição mais ampla, conforme rate limiting and throttling e a matemática de distribuição em how many proxy IPs you actually need.
Formato da requisição. Cabeçalhos que não correspondem ao navegador que você alega ser, client hints ausentes, um Accept-Language que contradiz seu país de saída, ou uma fingerprint de TLS que indica Python enquanto seu User-Agent indica Chrome. Essas são contradições, não ausências, e são fáceis de detectar, conforme setting the right headers e matching geo, timezone and locale.
Comportamento. Acessar endpoints em uma ordem que nenhuma pessoa seguiria, nunca carregar nada que um navegador carregaria, rotacionar identidade no meio de um fluxo, ou percorrer uma sequência de paginação em velocidade de máquina. Sequências que só fazem sentido para um script tendem a ser reconhecidas como scripts.
Qualidade do endereço. Às vezes é realmente o pool: endereços com reputação ruim atraem desafios independentemente do seu comportamento, e um pool supostamente residencial diluído com espaço de datacenter se comporta exatamente como espaço de datacenter, conforme spotting datacenter IPs sold as residential.
Se uma rota está bloqueada e seu ritmo e o formato da sua requisição são ambos defensáveis, é nesse momento que a qualidade do endereço se torna a hipótese principal, em vez da primeira suposição.
Retomando sem repetir o erro
Voltar mal é como um bloqueio resolvido se torna um bloqueio recorrente.
Comece com um canário em vez do trabalho completo: um punhado de requisições através de uma sessão nova, validadas adequadamente, para confirmar que o alvo está te aceitando novamente. Se passarem, aumente gradualmente em vez de retomar na taxa anterior, porque voltar imediatamente ao ritmo que causou o problema é um padrão reconhecível por si só. Mude algo antes de retomar, seja o ritmo, os cabeçalhos, a estratégia de sessão ou a geografia, já que retomar de forma idêntica é apostar que o bloqueio foi aleatório. E acompanhe a taxa de sucesso validada enquanto você aumenta, para descobrir nos primeiros minutos, e não na manhã seguinte.
Se um alvo se mostrar persistentemente hostil depois de tudo isso, as opções honestas são reduzir a ambição sobre ele, abordá-lo de forma diferente, ou aceitar que não vale o custo, o que é a lógica de escalonamento em scraping heavily protected sites.
Conclusão
Distinga primeiro os quatro casos parecidos, já que um limite de taxa respondido com rotação piora e um bloqueio suave contado como sucesso é invisível. Estabeleça o escopo, porque uma sessão falhando é rotineiro, uma rota degradada é uma causa que vale a pena encontrar, e tudo falhando ao mesmo tempo geralmente é o seu próprio deployment. Quando uma rota está genuinamente bloqueada, pare em vez de forçar, não tente novamente insistentemente, espere um resfriamento, e mude a identidade em vez de apenas o endereço. Depois encontre a causa em ordem de probabilidade: ritmo, formato da requisição, comportamento, e só então a qualidade do pool. Retome com um canário e um aumento gradual, tendo mudado algo, e acompanhe a taxa de sucesso validada enquanto faz isso. Em um pool rotativo, o endereço nunca foi o ativo; o acesso é, e o acesso se conquista parecendo comum.
Ter um lugar limpo para retomar é o que os proxies residenciais oferecem, um grande pool de endereços reais de nível residencial com direcionamento por país e cidade, para que uma sessão descartada seja substituída em vez de reutilizada, com preços por GB que tornam uma recuperação disciplinada mais barata do que uma teimosa.