Toda solicitação retorna 407 Proxy Authentication Required, nada chega ao destino, e as credenciais parecem corretas no painel. Este é um dos tickets de suporte mais comuns nessa categoria de produto e também um dos mais rápidos de resolver, porque o número de coisas que podem produzir um 407 é pequeno e elas podem ser eliminadas em uma ordem fixa.
Aqui está o que o código de status realmente significa, as causas que vale a pena verificar, a ordem para verificá-las e os erros específicos de cliente que produzem um 407 mesmo quando as credenciais estão corretas.
O que um 407 realmente é
Um 407 vem do proxy, não do site que você está tentando acessar. É a forma do proxy dizer que a solicitação chegou sem credenciais aceitáveis, e é o equivalente, na camada de proxy, de um 401 vindo de um servidor de origem. Essa distinção importa para a depuração: um 407 significa que seu tráfego chegou ao gateway e o gateway o recusou. A conectividade está boa. A autenticação não está.
Isso também significa que o site de destino não tem nenhum envolvimento. Se você está recebendo 407s, nada que você mude em cabeçalhos, user agents, renderização ou ritmo vai ajudar, porque sua solicitação nunca saiu do proxy.
As três causas que vale a pena verificar primeiro
Em um gateway onde o direcionamento é expresso no nome de usuário, quase todo 407 é uma dessas três coisas.
As credenciais estão erradas. Um erro de digitação, um caractere de espaço em branco perdido copiado de um painel, ou credenciais de um produto diferente. As credenciais de proxy geralmente não são as mesmas do login da sua conta, o que é uma confusão surpreendentemente comum.
Uma flag no nome de usuário estendido está malformada. Esta é a causa que as pessoas deixam passar, e é específica de gateways que codificam o direcionamento no nome de usuário. Se o seu nome de usuário carrega flags de país, cidade, sessão ou TTL, um valor não reconhecido torna todo o nome de usuário impossível de analisar, e o gateway o rejeita como uma falha de autenticação em vez de um erro de direcionamento. Um código de país digitado errado, um slug de cidade em formato incorreto, um identificador de sessão com caracteres inválidos, ou um ttl sem um sid que o acompanhe, tudo isso cai aqui. As credenciais estão perfeitas; a string de nome de usuário não está.
A senha foi rotacionada. Se alguém a regenerou no painel, todo cliente que ainda mantém o valor antigo retorna 407 até que seja atualizado. Este é o caso clássico em que funciona em uma máquina e falha em outra.
A ordem de diagnóstico
Percorra esta lista e pare quando funcionar, porque a etapa que corrige o problema identifica a causa.
Um: remova todas as flags e teste as credenciais puras. Esta única etapa separa um problema de credencial de um problema de flag, e deve sempre ser a primeira.
# bare username, no targeting flags at all
curl -x customer-USERNAME:PASSWORD@p.shifter.io:443 https://ipinfo.io/jsonSe isso funcionar, suas credenciais estão corretas e a falha está nas flags. Se ainda retornar 407, as próprias credenciais estão erradas e nenhuma quantidade de correção de flags vai ajudar.
Dois: adicione as flags de volta uma de cada vez. País primeiro, depois cidade ou ASN, depois sessão e TTL. A flag que reintroduz o 407 é a malformada, e agora você sabe exatamente qual valor verificar.
curl -x customer-USERNAME-country-us:PASSWORD@p.shifter.io:443 https://ipinfo.io/json
curl -x customer-USERNAME-country-us-city-new_york:PASSWORD@p.shifter.io:443 https://ipinfo.io/json
curl -x customer-USERNAME-country-us-city-new_york-sid-abc123:PASSWORD@p.shifter.io:443 https://ipinfo.io/jsonPreste atenção nos formatos: códigos de país são códigos ISO de duas letras, então uk é um erro comum, sendo gb o correto. Slugs de cidade usam underscores em vez de espaços ou hífens, como em new_york. E ttl só é válido junto com sid, então um TTL sozinho é inválido. A sintaxe completa está na documentação de gateway e autenticação, e as opções de direcionamento são abordadas em direcionamento em nível de cidade e direcionamento por ASN.
Três: recopie a senha do painel. Se as credenciais puras falharem na etapa um, pegue a senha diretamente do painel em vez de suas anotações ou um arquivo de configuração, e verifique especificamente se há um espaço no final, uma aspa curvada de um documento, ou uma colagem truncada.
Quatro: propague o valor por toda parte. Se funciona localmente mas não em produção, você tem uma cópia desatualizada em uma variável de ambiente, um gerenciador de segredos, uma imagem de contêiner ou uma configuração de CI. Este é um problema de implantação, não um problema de proxy.
Erros que parecem 407 mas não são
Distinguir esses casos economiza muito esforço desperdiçado, porque cada um tem uma correção diferente.
Um 502 neste gateway significa que nenhum endereço correspondeu ao seu filtro naquele momento. Isso é um problema de direcionamento, não de autenticação: suas credenciais foram aceitas e depois nada estava disponível para a combinação solicitada. Amplie o filtro, mude de cidade para país, ou relaxe uma flag de correspondência estrita.
Um 509 significa que a largura de banda do plano está esgotada com o excedente desabilitado. A autenticação teve sucesso; você ficou sem cota. Orientações relacionadas de dimensionamento estão em estimando a largura de banda mensal.
Connection refused significa que você nunca chegou ao gateway, geralmente porque você está apontando para um host legado baseado em porta em vez do endpoint atual, ou porque a saída da sua rede está bloqueada. Teste a conectividade bruta com nc -vz p.shifter.io 443 antes de presumir um problema de autenticação.
Um 403 ou uma página de desafio do destino significa que a autenticação funcionou perfeitamente e o site o recusou, o que é um problema completamente diferente, abordado em evitando bloqueios.
Erros específicos de cliente que produzem um 407
Às vezes as credenciais e as flags estão corretas e o erro é do cliente.
Caracteres especiais na senha. Se a senha contém caracteres que têm significado em uma URL, @, :, #, /, ou %, incorporá-la diretamente em uma URL de proxy quebra a análise e as credenciais chegam corrompidas. Codifique-a com percent-encoding.
import requests
from urllib.parse import quote
user = "customer-USERNAME-country-us"
pwd = quote("p@ss:word/123", safe="") # encode before embedding
PROXY = f"http://{user}:{pwd}@p.shifter.io:443"
r = requests.get("https://ipinfo.io/json",
proxies={"http": PROXY, "https": PROXY}, timeout=15)
print(r.status_code, r.text[:120])Confundir autenticação de proxy com autenticação de destino. curl -U define credenciais de proxy; -u define credenciais para o site de destino. Enviar suas credenciais de proxy como um cabeçalho Authorization não faz nada, porque a autenticação de proxy viaja em Proxy-Authorization, e a maioria dos clientes configura isso automaticamente quando as credenciais estão na URL do proxy.
Credenciais descartadas em HTTPS. Algumas configurações de cliente definem o proxy apenas para HTTP, então as solicitações simples se autenticam e as solicitações HTTPS não. Defina ambas as entradas, como no exemplo em Python acima.
Variáveis de ambiente que não são o que você pensa. HTTP_PROXY e HTTPS_PROXY definidas em um perfil de shell, um Dockerfile, ou um executor de CI podem sobrepor silenciosamente o que seu código passa, de modo que uma aplicação pode se autenticar contra uma string de proxy completamente diferente daquela em seu código-fonte. Imprima a configuração de proxy efetiva ao depurar em vez de confiar no código.
Uma biblioteca que não envia autenticação de proxy preventiva. Alguns clientes HTTP esperam ser desafiados antes de enviar credenciais e lidam mal com o desafio, particularmente com certas configurações de tunelamento. Se um curl puro funciona e sua aplicação não, a diferença está no cliente, não no gateway. As configurações que funcionam para as stacks mais comuns estão em usando proxies residenciais com Python.
Lidando com 407 em código de produção
Uma observação operacional: um 407 é um erro terminal, não transitório. Tentar novamente é inútil, porque as credenciais estarão igualmente erradas na próxima tentativa, e um loop de repetição contra uma falha de autenticação apenas consome largura de banda e pode parecer, de fora, um padrão de credential-stuffing. Classifique-o como terminal, falhe de forma explícita e emita um alerta, que é a disciplina de classificação descrita em retry e backoff.
A rotação de credenciais merece um plano de implantação em vez de um clique no painel, já que todo cliente que mantém o valor antigo começa a falhar no momento da rotação. Atualize o armazenamento de segredos primeiro, depois propague para os clientes, e só então rotacione.
Conclusão
Um 407 significa que sua solicitação chegou ao gateway e o gateway rejeitou as credenciais, então o site de destino é irrelevante e a conectividade está comprovada. Teste as credenciais puras sem flags primeiro, porque essa única etapa divide o problema ao meio, depois adicione as flags de volta uma de cada vez para encontrar a malformada, lembrando que um código de país errado ou um TTL sem uma sessão torna todo o nome de usuário impossível de analisar. Recopie a senha do painel se o teste puro falhou, e verifique se há valores desatualizados em variáveis de ambiente e armazenamentos de segredos se funciona em um lugar e não em outro. Descarte os casos parecidos: 502 é um filtro vazio, 509 é largura de banda, connection refused é o host errado, e um 403 do site não é um problema de autenticação de forma alguma. E nunca tente novamente um 407.
A referência completa de sintaxe está na documentação de gateway e autenticação, e o próprio produto é proxies residenciais, onde as mesmas credenciais funcionam em todos os países, cidades e modos de sessão com preços por GB.