Autenticação de proxy: user:pass ou whitelist de IP

Quando você compra um proxy, recebe um endereço e uma porta. Se o proxy encaminhasse o tráfego de qualquer pessoa que se conectasse a esse endereço, outras pessoas estariam usando o seu proxy. Por isso todo proxy pago verifica quem está se conectando antes de aceitar a conexão. Há duas formas comuns de fazer isso: usuário e senha (user:pass) ou uma lista de endereços IP permitidos (whitelist de IP).

Neste artigo, explicamos como os dois métodos funcionam por baixo dos panos, qual é mais seguro e prático em cada situação e como se conectar com cada um no cURL, no Python e no navegador. Também vemos as causas do erro 407 Proxy Authentication Required, que responde por boa parte dos chamados de suporte, e o problema que um IP dinâmico cria para a whitelist.

O que é autenticação de proxy?#

Autenticação de proxy é o servidor proxy verificar se uma conexão pertence a um usuário autorizado antes de encaminhá-la. Se a autenticação falha, o proxy não encaminha a requisição ao destino.

Os dois métodos respondem a perguntas diferentes:

• Usuário e senha: "Quem enviou esta requisição conhece as credenciais certas?"
• Whitelist de IP: "Esta conexão vem de um endereço IP permitido?"

No primeiro método a credencial está dentro da requisição; no segundo, a origem da conexão funciona como identidade. Essa diferença define a portabilidade, a segurança e as falhas típicas de cada método. Explicamos como um proxy funciona em geral em O que é um servidor proxy e como ele funciona?.

Como funciona a conexão com usuário e senha?#

Em proxies HTTP, a autenticação com usuário e senha faz parte do padrão HTTP. A RFC 9110 define o cabeçalho Proxy-Authenticate, com o qual o proxy pede credenciais, e o cabeçalho Proxy-Authorization, com o qual o cliente as envia. O esquema mais comum é o Basic, definido na RFC 7617.

Para uma requisição HTTPS, o processo é este:

1. O cliente se conecta ao proxy e envia uma requisição CONNECT target.com:443.
2. Se a requisição não traz credenciais, o proxy responde com 407 Proxy Authentication Required e um cabeçalho Proxy-Authenticate: Basic realm="proxy".
3. O cliente junta usuário e senha como user:pass, codifica em Base64 e reenvia a requisição com o cabeçalho Proxy-Authorization: Basic dXNlcjpwYXNz.
4. O proxy verifica as credenciais. Se estiverem certas, conecta-se ao destino e retorna 200 Connection Established; se não, retorna 407 de novo.

A maioria dos clientes adiciona o cabeçalho logo na primeira tentativa, então o passo 2 é pulado na prática. Os navegadores tentam primeiro sem o cabeçalho e mostram uma janela de login quando recebem um 407.

Há um detalhe importante: Base64 é codificação, não criptografia. Qualquer pessoa que veja o cabeçalho consegue decodificá-lo em segundos e ler o usuário e a senha. Na maioria das configurações, a conexão entre o cliente e o proxy é HTTP sem criptografia, o que significa que as credenciais trafegam praticamente em texto puro nesse trecho curto. O túnel HTTPS aberto com o site de destino não protege esse cabeçalho, porque ele é enviado antes de o túnel existir.

Proxies SOCKS5 têm uma subnegociação parecida de usuário e senha, definida na RFC 1929; ali também as credenciais vão sem criptografia.

Como funciona a whitelist de IP?#

Com whitelist de IP, a requisição não traz credencial nenhuma. Você cadastra um ou mais endereços IP como autorizados no painel do cliente, e o servidor proxy compara o IP de origem de cada conexão recebida com essa lista.

1. No painel, você adiciona o endereço IP público da máquina que vai usar o proxy.
2. O cliente se conecta ao proxy sem usuário nem senha.
3. O proxy olha o endereço de origem da conexão. Se estiver na lista, a requisição é encaminhada.
4. Se o endereço não estiver na lista, a conexão é recusada ou recebe um 407.

O "endereço IP público" aqui não é o endereço local do tipo 192.168.x.x que você vê nas configurações de rede do computador. O endereço que o proxy vê é o que o seu modem ou servidor usa na internet. Para descobri-lo, rode este comando com o proxy desligado:

curl https://api.ipify.org

A maior vantagem da whitelist é funcionar com software que não suporta credenciais. Alguns aplicativos de desktop antigos, clientes de jogos e ferramentas de automação só oferecem campos de endereço e porta nas configurações de proxy; nesse caso, a whitelist é a única opção.

Comparando os dois métodos#

Qual é mais seguro?#

Não há uma resposta única; os dois métodos estão expostos a riscos diferentes.

O risco do usuário e senha é o vazamento. Basta um arquivo de configuração enviado por engano a um repositório de código, um comando visível durante um compartilhamento de tela ou um login salvo no navegador de um computador compartilhado. Credenciais vazadas podem ser usadas de qualquer lugar do mundo, e esse uso é cobrado na sua conta.

O risco da whitelist de IP é um endereço IP compartilhado. Operadoras móveis e alguns provedores de internet doméstica colocam muitos assinantes atrás do mesmo IP público com uma técnica chamada CGNAT. Quando você adiciona um endereço assim à lista, usuários desconhecidos que compartilham esse endereço também podem se conectar ao seu proxy. O mesmo vale para redes de cafés, hotéis e coworkings.

Regras práticas:

• Se você trabalha a partir de um servidor com IP fixo, a whitelist é mais segura; você não carrega segredos no código.
• Não use whitelist a partir de uma linha móvel ou de uma conexão doméstica atrás de CGNAT.
• Se você usa usuário e senha, não escreva as credenciais no código; guarde-as em uma variável de ambiente ou em um gerenciador de segredos.
• Se o seu painel permite criar subusuários separados para trabalhos diferentes, aproveite; uma credencial vazada afeta só um trabalho.

Os dois métodos com exemplos#

Os endereços e as portas dos exemplos são ilustrativos; pegue os seus próprios valores no painel do cliente.

cURL#

# Usuário e senha dentro do endereço
curl -x "http://user:pass@pr.proxynet.io:8000" https://httpbin.org/ip

# Usuário e senha como opção separada
curl -x "http://pr.proxynet.io:8000" -U "user:pass" https://httpbin.org/ip

# Whitelist de IP: sem credenciais
curl -x "http://pr.proxynet.io:8000" https://httpbin.org/ip

A opção -U (forma longa --proxy-user) também reduz problemas com caracteres especiais, porque a senha não é escrita dentro do endereço. Para outras opções do cURL, veja Como usar proxy com cURL.

Python Requests#

import os
from urllib.parse import quote

import requests

user = os.environ["PROXY_USER"]
password = quote(os.environ["PROXY_PASS"], safe="")  # codifica caracteres como @, : e /

# Usuário e senha
proxy = f"http://{user}:{password}@pr.proxynet.io:8000"
r = requests.get("https://httpbin.org/ip", proxies={"http": proxy, "https": proxy}, timeout=20)
print(r.json())

# Whitelist de IP
proxy = "http://pr.proxynet.io:8000"
r = requests.get("https://httpbin.org/ip", proxies={"http": proxy, "https": proxy}, timeout=20)
print(r.json())

Como as credenciais são lidas de variáveis de ambiente, a senha não fica visível mesmo que o arquivo de código seja compartilhado. Mostramos uma configuração rotativa em Python em Como rotacionar proxies em Python. Para o equivalente em Node.js, veja Como usar proxy no Node.js.

Navegador#

Os navegadores pegam o endereço do proxy nas próprias configurações ou no sistema operacional, mas não pedem usuário e senha na tela de configurações. Quando o proxy retorna um 407 na primeira requisição, abre-se uma janela de login e você digita as credenciais ali. O Chrome não suporta autenticação com usuário e senha para proxies SOCKS5; se quiser usar SOCKS5 com o Chrome, você precisa de whitelist de IP.

Os passos para Windows e Chrome estão em Configuração de proxy no Windows e no Chrome, e para o Firefox em Configuração de proxy no Firefox. Para configurar na ferramenta de teste de APIs, veja Configuração de proxy no Postman. A opção de rotear aplicativos de desktop sem configuração de proxy está em Proxifier.

Por que aparece o erro 407 Proxy Authentication Required?#

A seção 15.5.8 da RFC 9110 define o 407 como "o cliente precisa se autenticar para usar o proxy". Ou seja, o problema está entre você e o proxy, não no site de destino. As causas mais comuns são:

1. Usuário ou senha errados. Um espaço no final ou uma diferença de maiúsculas e minúsculas ao copiar já basta.
2. A senha tem um caractere especial sem codificação. Em http://user:p@ss@pr.proxynet.io:8000, o cliente trata tudo depois do primeiro @ como nome do servidor. @ deve ser escrito como %40, : como %3A e / como %2F.
3. O IP da whitelist é diferente do IP de onde vem a conexão. O modem reiniciou, uma VPN continua ligada ou você está se conectando de outra rede no trabalho.
4. O software não envia as credenciais. Algumas ferramentas ignoram a parte user:pass@ do endereço do proxy e precisam de um campo ou opção de credenciais separado.
5. Protocolo ou porta errados. Mesmo com credenciais corretas, conectar à porta HTTP com SOCKS5, ou o contrário, gera um erro confuso.
6. A conta ou o subusuário está suspenso. O saldo pode ter acabado, o subusuário pode ter sido excluído ou a cota de tráfego pode ter se esgotado.

A saída detalhada do cURL ajuda a diagnosticar o erro:

curl -v -x "http://user:pass@pr.proxynet.io:8000" https://httpbin.org/ip 2>&1 | grep -iE "proxy-authorization|< HTTP"

Se não houver nenhuma linha Proxy-Authorization na saída, o cliente não está enviando as credenciais. Se a linha estiver lá mas a resposta for 407, as credenciais estão erradas ou há um problema com a conta. Reunimos o significado dos códigos de erro HTTP no scraping em Códigos de status HTTP no web scraping.

O que acontece com a whitelist quando o IP é dinâmico?#

Na maioria das conexões domésticas, o IP público não é fixo. Quando o modem reinicia, a linha cai ou o provedor troca os endereços periodicamente, você recebe um IP novo. O endereço antigo da whitelist deixa de valer e o proxy recusa a conexão.

As suas opções são:

• Mudar para usuário e senha. É o que dá menos trabalho com IP dinâmico.
• Pedir um IP fixo ao seu provedor. Solução permanente se o seu trabalho sempre acontece na mesma rede.
• Levar o trabalho para um servidor com IP fixo. Servidores em nuvem geralmente têm um endereço de saída fixo, o que combina com scripts de scraping e tarefas agendadas.
• Atualizar a lista automaticamente se o painel tiver API. Depende de o provedor oferecer essa API.

Funções em nuvem e contêineres com escalonamento automático podem receber um endereço de saída diferente a cada execução; nesses ambientes, geralmente não dá para usar whitelist.

Casos de uso#

• Script de scraping em um servidor com IP fixo: whitelist, para não ter senha no código. Para IPs de saída diferentes por um único endereço, usa-se um Proxies rotativos.
• Uma equipe trabalhando de redes diferentes: usuário e senha; melhor ainda se cada membro puder ter um subusuário próprio.
• Trabalho com contas que precisa de sessão: geralmente usuário e senha; um Proxies de sessão fixa para manter o mesmo IP durante a sessão e um Proxies ISP para um endereço fixo de longa duração.
• Software de desktop antigo sem campo de credenciais: a whitelist é a única opção.
• Chrome com SOCKS5: whitelist, porque o Chrome não suporta autenticação por senha em SOCKS5.

Guia de decisão#

Perguntas frequentes#

Posso usar os dois métodos ao mesmo tempo?#

Depende do provedor. Muitos provedores aceitam, na mesma conta, conexões sem senha de IPs da whitelist e conexões com usuário e senha de outros lugares. As configurações do painel definem esse comportamento.

O meu usuário e a minha senha vão para o site de destino junto com o tráfego?#

Não. O cabeçalho Proxy-Authorization é só para o proxy; o proxy não o repassa ao destino. O site de destino não vê as suas credenciais.

Como guardar a senha do proxy com mais segurança?#

Não escreva a senha no código-fonte. Use uma variável de ambiente, um arquivo .env fora do controle de versão ou o gerenciador de segredos da sua plataforma. Se suspeitar que a senha vazou, troque-a no painel imediatamente.

Quantos IPs posso adicionar à whitelist?#

O limite varia por provedor e plano. Você encontra o limite atual no painel do cliente ou com a equipe de suporte.

Por que recebo 407 mesmo com a senha correta?#

O motivo mais comum são caracteres especiais sem codificação na senha. O segundo mais comum é o seu software não enviar as credenciais que estão no endereço. Use o comando curl -v acima para verificar se o cabeçalho está sendo enviado.

A whitelist funciona com uma VPN ligada?#

Com a VPN ligada, você sai para a internet com o IP do servidor VPN. Se o IP da sua casa ou do escritório estiver na whitelist, o proxy recusa a conexão. Desligue a VPN ou adicione o endereço de saída da VPN à lista; esta última opção não é recomendada, porque outros usuários podem compartilhar esse endereço de VPN.

Em resumo#

Há duas formas de se autenticar em um proxy: usuário e senha enviados em toda requisição no cabeçalho Proxy-Authorization, ou uma whitelist de IP que olha o endereço de origem da conexão. Usuário e senha funciona em qualquer rede, mas as credenciais precisam ser guardadas com cuidado; a whitelist não deixa segredos no código, mas exige um IP fixo e não compartilhado. Um erro 407 quase sempre vem de credenciais erradas, de um caractere especial sem codificação ou de um IP antigo na whitelist. Para planos que suportam os dois métodos, conheça os nossos serviços de proxy.