Erros comuns de proxy residencial e como corrigi-los

Problemas de proxy parecem variados quando você está no meio de um deles e, na verdade, são bastante repetitivos. Quase tudo que dá errado se encaixa em nove padrões, e na maioria dos casos a própria resposta indica qual deles você está enfrentando. Este é o índice: encontre seu sintoma, veja a causa provável e a solução imediata, e siga o link quando precisar da versão mais longa.

A tabela rápida

Sintoma	Geralmente significa	Primeira coisa a fazer	Tentar novamente?
407 Proxy Authentication Required	Credenciais erradas, ou uma flag malformada no username	Testar o username puro, sem flags	Nunca
502 Bad Gateway	Nenhum endereço correspondeu ao seu filtro naquele momento	Ampliar o filtro	Apenas após ampliar
509 Bandwidth Limit Exceeded	Alocação do plano esgotada, overage desativado	Verificar a carteira e o plano	Não
Conexão recusada ou travada	Você nunca chegou ao gateway	nc -vz p.shifter.io 443	Não, corrigir a conectividade primeiro
Timeouts	Lentidão do destino, filtro muito restrito, ou sua própria concorrência	Separar o tempo de conexão do tempo de leitura	Sim, com backoff
403 ou uma página de desafio	O destino rejeitou a identidade, não o proxy	Descartar a sessão, verificar os headers	Não na mesma sessão
429 Too Many Requests	O destino está limitando sua taxa de requisições	Respeitar o Retry-After, depois desacelerar	Sim, após esperar
200 com conteúdo errado ou vazio	Um bloqueio sutil, ou o locale errado	Validar o corpo, verificar sinais de geolocalização	Não até corrigir a causa
Mesmo IP em toda requisição	Quase sempre reutilização de conexão no seu cliente	Testar com processos separados	Não aplicável

407: autenticação rejeitada

O gateway rejeitou suas credenciais, o que significa que seu tráfego chegou até ele e a conectividade está normal.

Três causas explicam quase todos os casos: um erro de digitação nas credenciais, uma flag malformada no username estendido, ou uma senha que foi rotacionada no painel enquanto uma cópia antiga ainda está em uso em algum lugar. A do meio é a menos óbvia, porque um valor não reconhecido como country-uk em vez de country-gb torna todo o username impossível de interpretar, e por isso é reportado como falha de autenticação em vez de erro de segmentação.

O diagnóstico é sempre o mesmo: remova todas as flags e teste primeiro o username puro. Se funcionar, o problema está nas flags e você as adiciona de volta uma a uma. Se falhar, copie a senha novamente do painel. Detalhes completos em corrigindo erros 407 e de credenciais.

Nunca tente novamente um 407. É definitivo, e um loop de novas tentativas contra ele consome largura de banda enquanto parece, de fora, um ataque de credential stuffing.

502: nada correspondeu ao seu filtro

Suas credenciais foram aceitas e então nenhum endereço estava disponível para a combinação solicitada. Isso é um problema de segmentação, não uma falha.

Geralmente aparece quando um filtro é muito restrito, uma cidade pequena, um ASN específico, ou uma combinação dos dois, e é mais provável em horários em que o pool local está reduzido, já que a disponibilidade acompanha a atividade humana. Amplie o filtro, passe de cidade para região ou país, ou remova a correspondência estrita para que o gateway recorra a um pool mais amplo. Se você depende da correspondência estrita de forma deliberada, esse erro é o sistema funcionando como esperado. Mais contexto em disponibilidade por país.

509: sem largura de banda

A alocação do plano foi esgotada e o overage não está habilitado, então as requisições são interrompidas. Não há nada de errado com a conexão ou a configuração. Adicione fundos para habilitar o overage, ou espere o ciclo reiniciar, e se isso acontece com regularidade o plano está subdimensionado, o que é uma questão de previsão abordada em estimando a largura de banda mensal.

Conexão recusada, ou uma requisição que trava para sempre

Você não está se comunicando com o gateway de forma alguma. Duas causas usuais: você está apontando para um host legado baseado em porta em vez de p.shifter.io:443, ou sua própria rede está bloqueando tráfego de saída naquela porta.

Teste a conectividade bruta antes de supor qualquer coisa sobre o proxy:

nc -vz p.shifter.io 443

Se isso falhar, é um problema de egress ou de firewall do seu lado. Se funcionar mas as requisições ainda falharem, você está diante do caminho de autenticação descrito acima.

Timeouts

A classe mais ambígua, porque vários problemas diferentes produzem o mesmo sintoma. O passo mais útil é separar o tempo de conexão do tempo total, já que eles apontam em direções opostas:

curl -o /dev/null -s -w "connect: %{time_connect}s  total: %{time_total}s\n" \
  -x customer-USERNAME:PASSWORD@p.shifter.io:443 https://example.com

Uma conexão lenta indica o caminho do proxy ou um filtro muito restrito tornando a seleção de endereço lenta. Uma conexão rápida com um total lento indica que o destino está lento, o que não é algo que uma mudança de proxy resolve. Verifique também se seus timeouts estão simplesmente ajustados para latência de datacenter, porque conexões residenciais são legitimamente mais lentas e um timeout de dois segundos vai falhar constantemente por motivos que não são erros. O diagnóstico completo está em por que as requisições dão timeout, e as opções de ajuste estão em reduzindo a latência.

403, captchas e páginas de desafio

Estes vêm do destino, não do proxy, o que significa que a autenticação e a conectividade funcionaram normalmente. O destino analisou a requisição e a recusou.

A resposta imediata é descartar aquela sessão e obter uma nova em vez de tentar novamente com a mesma identidade. A resposta duradoura é descobrir o motivo, e a ordem de probabilidade é primeiro o ritmo, depois a forma da requisição, depois o comportamento, depois a qualidade do endereço. Reduzir a velocidade resolve mais desses casos do que qualquer outra coisa, conforme rate limiting e throttling, e se o ritmo for defensável o próximo suspeito são os headers e user agent se contradizendo. O guia de recuperação está em o que fazer quando seus IPs são banidos.

429: muitas requisições

O destino está limitando sua taxa (rate limiting). Assim como um 403, isso vem do destino, não do gateway, então suas credenciais e sua conexão estão corretas. Significa que as requisições estão chegando mais rápido do que o destino aceita de um visitante, uma sessão ou uma rede.

Desacelere em vez de tentar novamente de imediato. Se a resposta trouxer um header Retry-After, espere pelo menos esse tempo antes da próxima requisição para aquele destino. Se não trouxer, recue exponencialmente, reduza a concorrência para aquele destino e distribua as requisições por mais sessões em vez de forçar mais por uma só. Tentar novamente um 429 no mesmo ritmo transforma um limite temporário em um bloqueio. O método de ritmo está no guia de rate limiting linkado na seção de 403 acima.

Um 200 que não é o que você queria

A falha mais cara, porque nada parece errado. Uma página de desafio, um conjunto de resultados vazio, uma listagem truncada, ou uma página regional genérica podem chegar com um status de sucesso, e um pipeline que conta apenas códigos de status vai registrá-los como dados.

Se o conteúdo está errado em vez de ausente, suspeite primeiro de geolocalização: um header Accept-Language que contradiz o seu país de saída, ou um DNS leak resolvendo hostnames a partir da sua localização em vez da localização do proxy, ambos produzem conteúdo plausível para o mercado errado. Veja alinhando geo, timezone e locale e prevenindo DNS leaks.

Se o conteúdo é um desafio ou um stub, trate como um bloqueio, conforme detectando conteúdo bloqueado ou falso. De qualquer forma, a lição é a mesma: valide o corpo antes de contar uma resposta como sucesso, ou nenhum dos seus monitoramentos significa nada.

O mesmo endereço em toda requisição

A rotação parece quebrada e quase nunca está. A causa usual é que seu cliente HTTP está reutilizando uma conexão, e o endereço de saída é escolhido quando a conexão é estabelecida, não a cada requisição enviada por ela.

Teste primeiro com processos separados:

for i in 1 2 3; do
  curl -s -x customer-USERNAME:PASSWORD@p.shifter.io:443 http://ip-info.com/json | head -c 60; echo
done

Se isso rotacionar e sua aplicação não, a causa é o connection pooling no seu cliente. Se nenhum dos dois rotacionar, verifique se há uma flag sid no username solicitando uma sessão sticky, e confirme que o endereço que você está vendo não é simplesmente o seu próprio, o que significaria que o proxy não está sendo aplicado. Causas completas em IP não rotacionando.

No navegador: ERR_PROXY_CONNECTION_FAILED e ERR_TUNNEL_CONNECTION_FAILED

Os navegadores costumam esconder o código de status do proxy atrás de seus próprios nomes de erro. Dois cobrem a maioria dos casos.

• ERR_PROXY_CONNECTION_FAILED significa que o navegador não conseguiu chegar ao proxy de jeito nenhum. Trate como conexão recusada acima: verifique se o host é p.shifter.io e a porta é 443, depois verifique se sua rede, firewall ou antivírus está bloqueando a conexão.
• ERR_TUNNEL_CONNECTION_FAILED significa que o navegador chegou ao proxy, mas o proxy não abriu o túnel até o destino. Isso geralmente é um 407 (credenciais ou uma flag malformada) ou um 502 (nada correspondeu ao seu filtro), então teste o username puro primeiro, como na seção do 407.

Erros de TLS e certificado

Menos comuns, e geralmente ambientais. Uma biblioteca TLS desatualizada rejeitando o cipher suite do gateway, ou um middlebox corporativo quebrando a cadeia de confiança. Atualize primeiro a biblioteca do cliente. Desativar a verificação de certificado fará o erro desaparecer e deve ser usado apenas para confirmar o diagnóstico, nunca em nada que você coloque em produção.

Uma ordem geral de operações

Quando algo quebra e você não sabe por onde começar: confirme a conectividade bruta, depois teste as credenciais puras sem flags, depois adicione as flags de volta uma a uma, depois verifique se a resposta é genuinamente o que você pediu em vez de confiar no código de status. Essa sequência isola a camada em poucos minutos, e é a mesma sequência tanto para um código de erro quanto para dados que parecem sutilmente errados.

Para qualquer coisa contínua em vez de aguda, a instrumentação que detecta esses problemas antes que você os note manualmente está em monitorando a saúde do proxy em escala.

Perguntas frequentes

Resumindo

Nove padrões cobrem quase tudo. 407 é credenciais ou uma flag malformada e nunca vale a pena tentar novamente. 502 é um filtro vazio, não uma falha. 509 é largura de banda. Conexão recusada significa que você nunca chegou ao gateway. Timeouts precisam ter o tempo de conexão separado do tempo total antes de qualquer outra coisa. Um 403 ou desafio é o destino recusando você, então mude de identidade e depois descubra o motivo. Um 429 é o destino pedindo para você desacelerar, então respeite o Retry-After e reduza o ritmo. Um 200 com conteúdo errado é o mais perigoso, e é por isso que a validação do corpo não é opcional. E o mesmo endereço em toda requisição é quase sempre reutilização de conexão no seu próprio cliente. Trabalhe da conectividade para fora, e verifique o que voltou em vez do que o código de status afirma.

O próprio gateway está documentado em como se conectar, o vocabulário no glossário, e o produto é proxies residenciais com preço por GB.