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 oito 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 |
|---|---|---|
407 Proxy Authentication Required | Credenciais erradas, ou uma flag malformada no username | Testar o username puro, sem flags |
502 Bad Gateway | Nenhum endereço correspondeu ao seu filtro naquele momento | Ampliar o filtro |
509 Bandwidth Limit Exceeded | Alocação do plano esgotada, overage desativado | Verificar a carteira e o plano |
| Conexão recusada ou travada | Você nunca chegou ao gateway | nc -vz p.shifter.io 443 |
| Timeouts | Lentidão do destino, filtro muito restrito, ou sua própria concorrência | Separar o tempo de conexão do tempo de leitura |
403 ou uma página de desafio | O destino rejeitou a identidade, não o proxy | Descartar a sessão, verificar os headers |
200 com conteúdo errado ou vazio | Um bloqueio sutil, ou o locale errado | Validar o corpo, verificar sinais de geolocalização |
| Mesmo IP em toda requisição | Quase sempre reutilização de conexão no seu cliente | Testar com processos separados |
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 443Se 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.comUma 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.
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 https://ipinfo.io/json | head -c 60; echo
doneSe 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.
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.
Resumindo
Oito 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 200 com conteúdo errado é o caso 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.