Autenticação de proxy com nome de usuário e senha: como conectar e evitar erros

Na autenticação com nome de usuário e senha, sua aplicação envia ao proxy as credenciais emitidas pelo provedor. O proxy as verifica e permite o uso do serviço. Esse método é útil ao trabalhar em dispositivos e redes diferentes: se o serviço não exigir também autorização por IP, transferir um script para outro servidor não exigirá mudar um endereço IP permitido.

Uma conexão funcional exige mais do que nome de usuário e senha. Você também precisa do endereço, da porta e do protocolo corretos do proxy. Sua aplicação deve ser compatível com o método de autenticação necessário. Portanto, um erro de autenticação não significa necessariamente que a senha está errada.

Para comparar os métodos de acesso e obter ajuda na escolha, consulte Autenticação de proxy. Este artigo aborda a conexão com nome de usuário e senha, desde o preenchimento das configurações até o diagnóstico de problemas em um script em uso.

O que significa autenticação com nome de usuário e senha

O nome de usuário identifica uma conta ou o acesso a um serviço específico, enquanto a senha confirma seu direito de usá-lo. Depois que a verificação é concluída com sucesso, o proxy processa a conexão dentro das permissões concedidas: a lista de endereços disponíveis, a franquia comprada e os limites aplicáveis.

As credenciais de proxy não devem ser confundidas com a senha do painel. Os dados usados por uma aplicação podem ser diferentes dos usados para entrar no site do provedor. Uma chave de API serve para solicitações à API do serviço, enquanto a senha de um site de destino serve para entrar nesse site. Use uma delas como senha de proxy somente se o provedor especificar explicitamente esse método de conexão.

Uma autenticação de proxy bem-sucedida não faz login no site de destino. Se o site exigir sua própria conta, cookies ou token, a aplicação ainda precisará fornecê-los separadamente.

Quando esse método é útil

O acesso com nome de usuário e senha pode atender a aplicações em vários locais, sejam eles fixos ou variáveis. Sem restrição de IP, cada aplicação precisa das credenciais e das configurações de conexão do proxy, sem uma entrada separada na lista de IPs permitidos para sua rede.

Por exemplo, uma equipe trabalha em dois escritórios e de casa, cada local com um IP público diferente. As aplicações podem usar as mesmas credenciais de proxy se o serviço permitir que elas compartilhem credenciais sem vínculo com IP. Cada aplicação mantém suas próprias configurações de conexão; o proxy verifica as credenciais enviadas por cada uma.

Esse método também funciona para vários servidores permanentes. Porém, o número de dispositivos, as conexões simultâneas e os recursos disponíveis dependem do plano. Uma única senha não concede acesso ilimitado.

Como uma aplicação envia credenciais de proxy

A sequência geral é simples: a aplicação contata o proxy, passa pela verificação de acesso e o usa para chegar ao recurso solicitado. Os detalhes dependem do protocolo.

Um proxy HTTP pode retornar primeiro 407 Proxy Authentication Required e indicar o método de autenticação aceito. A aplicação envia as informações de autenticação no cabeçalho Proxy-Authorization. Alguns clientes as enviam imediatamente, então o desafio inicial pode não aparecer no log.

Ao abrir um site HTTPS por um proxy HTTP comum, a autenticação pode ocorrer durante a solicitação CONNECT que estabelece um túnel. Em seguida, a aplicação estabelece uma conexão segura com o site. Outras solicitações ao site por esse túnel já estabelecido não repetem o login no proxy usado para abri-lo.

No SOCKS5, o nome de usuário e a senha são verificados no início da conexão, antes da solicitação de conexão ao destino. Se a verificação falhar, a aplicação não obterá, por meio do proxy, a conexão solicitada. Uma falha nativa de autenticação SOCKS5 não é uma resposta HTTP 407.

Selecione o protocolo e o método de autenticação compatíveis com o serviço. O SOCKS4 tem um campo de ID de usuário, mas não define a troca de nome de usuário e senha do SOCKS5. Preencher esse campo não faz um cliente SOCKS4 executar a autenticação por senha do SOCKS5.

Quais configurações inserir na aplicação

Comece pelos dados de conexão do seu serviço específico. Se a aplicação tiver campos separados, insira cada valor em seu próprio campo:

Algumas aplicações aceitam uma única string no formato protocol://username:password@host:port. Por exemplo, em http://client01:River%[email protected]:8080, o nome de usuário é client01, a senha é River@2026, o host é proxy.example e a porta é 8080. O @ dentro da senha é representado como %40 para não ser confundido com o separador antes do host.

O curl, por exemplo, é compatível com essa interpretação de uma URL de proxy. Um campo de senha separado geralmente espera a própria senha, sem codificação de URL. Não copie um valor codificado de uma URL para um campo separado sem verificar o formato: a aplicação pode tratá-lo como uma senha diferente. Para strings que contenham %, dois-pontos ou outros caracteres especiais, siga os requisitos de formato do próprio cliente.

Codifique uma única vez os caracteres necessários dentro das credenciais; codificar a string inteira danificaria seus separadores. Colocar um argumento de comando entre aspas não substitui a codificação de URL. O método de autenticação pode ter suas próprias restrições: o HTTP Basic, por exemplo, permite dois-pontos na senha, mas não no nome de usuário.

Os formatos de importação também variam. host:port:username:password e username:password@host:port não são intercambiáveis. Valores corretos na ordem errada não funcionarão se o importador esperar outra disposição.

O prefixo http:// em uma URL de proxy descreve como o cliente se conecta ao próprio proxy. Ele não impede o acesso a sites HTTPS: o cliente pode estabelecer um túnel para eles. Simplesmente mudar o prefixo para https:// não adiciona ao servidor compatibilidade com conexão segura ao proxy.

Alguns serviços incluem um país, um grupo de saída ou um parâmetro de sessão no nome de usuário. Copie a string inteira. Esses parâmetros controlam o roteamento conforme as regras do provedor; não invente sua sintaxe nem a copie de outro serviço.

Por que verificar a compatibilidade com autenticação na aplicação

A compatibilidade com proxy e a compatibilidade com autenticação de proxy são capacidades separadas. Campos de host e porta não significam necessariamente que o cliente consegue enviar nome de usuário e senha.

Verifique a combinação exata de protocolo de proxy, método de autenticação e aplicação. Por exemplo, a implementação nativa de SOCKS5 do Chrome não é compatível com autenticação de proxy SOCKS5. Credenciais corretas, por si só, não corrigem essa limitação. Uma extensão para selecionar proxies também não adiciona necessariamente o método de autenticação ausente.

Em scripts, a compatibilidade pode depender da biblioteca, de seus componentes opcionais e da forma de fornecer as configurações. Uma aplicação não usa necessariamente as configurações de proxy do sistema nem as configurações de um navegador onde a conexão já funciona.

Antes de iniciar uma tarefa grande, teste uma solicitação na aplicação que vai executá-la. Confirme que a aplicação usa o proxy especificado e não continua com uma conexão direta após uma falha. Uma página carregar com sucesso, por si só, não confirma que as configurações estão corretas.

O que acontece quando seu IP muda

Em uma conexão ADSL com IP dinâmico, o provedor de internet pode atribuir um novo endereço após reiniciar o roteador ou reconectar. Se o proxy verificar apenas nome de usuário e senha, a aplicação se conectará com as mesmas credenciais: não haverá um novo IP para adicionar no painel. O mesmo vale ao mudar do escritório para uma rede doméstica.

Porém, mudar de rede pode interromper conexões existentes. O cliente precisará se reconectar, e talvez seja necessário repetir uma solicitação não concluída. Um erro logo após passar do Wi-Fi para a internet móvel não deve ser tratado automaticamente como um problema de senha.

Alguns serviços verificam tanto as credenciais quanto o endereço de origem. Uma senha correta não supera essa restrição de rede: o novo IP deve corresponder a um endereço ou intervalo permitido. Antes de transferir um script, confirme se o serviço aceita conexões de qualquer rede ou aplica uma verificação combinada.

A senha é protegida em trânsito?

A autenticação determina quem tem permissão de acesso. A criptografia determina se alguém ao longo do caminho pode ler os dados transmitidos. Ter uma senha, por si só, não torna a conexão criptografada.

O HTTP Basic codifica o nome de usuário e a senha em Base64. Trata-se de uma representação reversível, não de criptografia. Sem proteção na conexão com o proxy, alguém que observe esse caminho de rede pode obter as credenciais. A autenticação padrão do SOCKS5 com nome de usuário e senha também não criptografa sua transmissão.

O HTTPS no site de destino protege a conexão entre a aplicação e esse site. Com um proxy HTTP, a autenticação durante o estabelecimento do túnel acontece antes; o TLS do site não protege as credenciais de proxy já enviadas. Da mesma forma, uma solicitação HTTPS por SOCKS5 não criptografa a verificação anterior da senha do proxy.

Proteger essa parte do percurso exige proteção entre a aplicação e o proxy, como um proxy HTTPS que usa TLS, quando tanto o serviço quanto o cliente forem compatíveis. A aplicação deve validar o certificado do proxy. Em algumas ofertas comerciais, “proxy HTTPS” significa apenas que sites HTTPS podem ser acessados, então verifique onde o TLS realmente se aplica.

Se uma string de conexão completa com uma senha válida for exposta, outra pessoa talvez consiga usar o serviço dentro de suas regras, consumindo a franquia ou ocupando conexões. Isso não equivale a obter a senha do painel quando as credenciais são separadas. O método de autenticação também não garante que um endereço não possa ser identificado como proxy: um desafio de autenticação acessível externamente pode revelar o serviço.

Várias aplicações podem usar as mesmas credenciais?

Tecnicamente, vários clientes podem enviar o mesmo nome de usuário e a mesma senha. O provedor determina se isso é permitido e estabelece as condições: regras de compartilhamento, limites de conexões ativas, franquia comprada e quaisquer restrições adicionais.

Por exemplo, dois scripts podem usar uma conta e abrir quantidades diferentes de conexões. Uma senha não significa uma conexão. Da mesma forma, iniciar dez processos não multiplica por dez a franquia total de conexões do serviço.

O número de pares de credenciais também é diferente do número de IPs de saída. Um nome de usuário e uma senha podem conceder acesso a uma lista de proxies estáticos ou a um gateway apoiado por um pool de endereços. O IP visto pelo site depende do proxy selecionado e das regras de roteamento do serviço.

Se o serviço oferecer credenciais separadas para aplicações ou membros da equipe, um conjunto poderá ser desativado sem alterar os outros. Com uma senha compartilhada, mudá-la exige atualizar todas as aplicações que a usam. Credenciais separadas ainda não implicam franquias separadas de conexão ou tráfego: verifique quais limites elas compartilham.

Por que um proxy rejeita nome de usuário e senha

Primeiro, identifique quem retornou o erro. O HTTP 407 diz respeito à autenticação de proxy; o 401 do site de destino diz respeito ao acesso a esse site. Uma mensagem 403 ou um tempo limite não demonstra, sem outras evidências, se a senha do proxy está correta.

Verifique o status do serviço e a franquia restante, depois teste uma solicitação com as configurações fornecidas na aplicação real. Se ela falhar, use a tabela para verificar a compatibilidade do cliente, o formato das credenciais e as restrições de IP de origem, alterando uma configuração por vez. Quando a solicitação funcionar de forma consistente, aumente a carga de trabalho e observe os limites que aparecem apenas sob carga.

Como armazenar e alterar credenciais em scripts em uso

Mantenha as credenciais separadas do código, em uma configuração com controle de acesso ou no armazenamento de segredos do seu ambiente. Uma aplicação pode recebê-las por variáveis de ambiente, mas elas não são criptografia por si só. Mantenha senhas ativas fora de repositórios e modelos compartilhados com outras pessoas.

Em geral, um log precisa do host e da porta do proxy, do resultado da conexão e do código de erro. Uma string de conexão completa contém a senha; oculte-a antes de gravar o log. Com ferramentas de linha de comando, considere que um segredo pode permanecer no histórico de comandos ou ficar visível nos argumentos do processo, dependendo da aplicação e do sistema.

Antes de mudar uma senha, encontre todos os seus consumidores: aplicações locais, processos de servidor, tarefas agendadas e sistemas de compilação. Depois da mudança, atualize suas configurações e estabeleça uma nova conexão para testá-los. Confirme que processos de longa duração também receberam o novo valor; alguns precisam ser reiniciados.

Se a senha antiga não deve mais funcionar, teste se uma nova conexão com ela é rejeitada. As conexões existentes seguem as regras do próprio serviço: mudar uma senha nem sempre as encerra imediatamente. Para uma revogação urgente, use o método de desativação de acesso compatível com o provedor.

Autenticação combinada: IP e senha

Na autenticação combinada, o proxy verifica duas condições: as credenciais e o endereço a partir do qual a aplicação se conecta. Ambas devem ser aprovadas. Uma senha correta, por si só, não supera a restrição de IP.

Nos pacotes estáticos da ProxyCompass, o modo combinado usa uma sub-rede /24. Se você tem vários endereços IPv4 públicos na mesma sub-rede, basta adicionar um deles à lista de IPs permitidos. Os outros endereços dessa sub-rede podem se conectar com nome de usuário e senha corretos, sem uma entrada separada para cada endereço.

Na ilustração, o IP público da aplicação compartilha os três primeiros números com o endereço da lista de IPs permitidos. Ela pode se conectar com credenciais válidas; um endereço fora dessa sub-rede falha na verificação de rede, e uma senha errada falha mesmo dentro dela. Outros IPs de clientes na mesma sub-rede também podem usar essa entrada. Isso é útil para aplicações que exigem campos de nome de usuário e senha. A regra diz respeito aos IPs públicos das suas aplicações, e não aos IPs de saída dos proxies comprados.