A porta do proxy não aceita conexão sem autenticação — senão qualquer pessoa que descobrisse o endereço e a porta poderia usá-la. Os provedores oferecem duas formas de dizer à porta "este é dos nossos": fixar um par de login e senha ou incluir o IP externo do cliente no whitelist. As formas não são intercambiáveis: cada uma tem sua própria falha, seu próprio ponto de vazamento e sua própria praticidade no trabalho em equipe. Vamos ver qual escolher para cada tipo de infraestrutura.

Como funcionam as duas formas

O login e a senha são enviados na própria requisição de conexão — seja na URL do proxy (login:password@host:port), seja em um cabeçalho de autorização separado. A porta verifica o par a cada conexão, independentemente de onde a requisição veio. É a verificação clássica de "quem é você", ligada às credenciais e não ao local de conexão.

O whitelist de IP funciona de outro jeito: a porta já conhece de antemão uma lista de endereços externos autorizados a se conectar sem senha. A verificação não é "quem é você", e sim "de onde você vem" — confere-se o IP de onde chegou a requisição TCP ao proxy. Se o endereço externo do cliente não coincidir com o que está na lista, a conexão é recusada antes mesmo de qualquer tentativa de autenticação.

Quando o whitelist de IP é mais conveniente

O whitelist poupa tempo onde o endereço externo do cliente é estável: servidor dedicado, link de escritório com IP estático, VPS na nuvem. Basta cadastrar o endereço uma vez no painel e, daí em diante, a conexão acontece sem senha em cada script, o que simplifica as configurações e elimina o risco de commitar o par sem querer em um repositório. Para automação em servidores, em que o script roda por anos a partir do mesmo host, é a opção que dá menos trabalho. Antes de confiar no whitelist, vale conferir se o próprio canal entrega métricas estáveis — caso contrário, a estabilidade do endereço pode esconder a degradação da própria conexão.

A desvantagem é só uma, mas fatal: se o IP externo do servidor mudar — a hospedagem deu um novo endereço depois de uma reinicialização, houve migração para outro data center, mudou o plano na operadora —, o whitelist deixa de reconhecer o cliente instantaneamente e sem aviso. O script passa a receber uma recusa de conexão, e não um erro de autenticação, o que demora mais para diagnosticar: o código parece funcionar, o proxy parece pago, mas o tráfego simplesmente não passa.

Quando o login e senha é obrigatório

Um endereço externo dinâmico torna o whitelist inútil por princípio. Internet residencial com reconexão por DHCP, acesso móvel, um notebook que se conecta todo dia de um lugar novo — nesses cenários, o IP do cliente muda mais rápido do que a lista no painel do provedor consegue ser atualizada. Nessa situação, login e senha é a única forma que funciona: a autenticação não depende de onde a requisição fisicamente saiu.

O segundo caso é o de muitas máquinas com um único par de acesso. Quando vários funcionários ou vários servidores com endereços diferentes e imprevisíveis trabalham com o proxy, incluir cada IP no whitelist manualmente é ineficiente e, em uma infraestrutura de nuvem com autoscaling, simplesmente impossível: as novas instâncias recebem novos endereços dinamicamente. A lógica é parecida em equipes que gerenciam contas por meio de um navegador antidetect: cada funcionário tem seu perfil e seu IP, e fixar um endereço no whitelist para cada um não faz sentido.

Riscos de vazamento do par login e senha

O login e a senha têm um ponto fraco que o whitelist não tem: o par de acesso é um segredo, e segredos podem vazar. Ele vai parar nos logs da aplicação durante a depuração, no histórico de comandos do shell, em um repositório público depois de um commit acidental de configuração, em uma conversa ao passar o acesso para um colega. Quem recebe o par se conecta de qualquer IP — o proxy não verifica de onde veio a requisição, apenas quem informou a senha correta.

Nesse sentido, o whitelist é mais resistente: mesmo que alguém descubra o endereço e a porta do proxy, sem incluir o próprio IP externo na lista não consegue se conectar. Não existe um segredo que possa ser copiado e levado embora — existe um vínculo com uma infraestrutura que um estranho não controla.

O que escolher para o trabalho em equipe

Uma abordagem mista costuma ser mais precisa do que uma solução universal. Para infraestrutura de servidores estável, whitelist: menos segredos nas configurações e menor risco de vazamento. Para funcionários com acesso itinerante ou residencial, para ambientes de teste e para integrações via API, login e senha, mas com rotação obrigatória: se o par foi enviado em uma conversa ou usado em um teste, o melhor é trocá-lo, e não deixá-lo valendo por tempo indeterminado. Para conferir qual método está disponível em cada porta e com que volume de tráfego, basta olhar o painel na hora de receber o endereço.

Perguntas frequentes

Dá para usar os dois métodos ao mesmo tempo na mesma porta?

Normalmente a porta aplica um único esquema de verificação, definido na entrega, mas nada impede de manter várias portas para cenários diferentes: parte com whitelist para os servidores, parte com login e senha para tarefas móveis e itinerantes.

Por que o proxy parou de me deixar entrar sem nenhuma mudança no código?

A causa mais comum é que o IP externo do cliente que estava no whitelist mudou. Verifique o endereço de saída atual do servidor e compare com a lista do painel; a hospedagem pode trocar o endereço em uma reinicialização ou migração.

O que é mais seguro guardar na configuração: a senha ou contar com o whitelist?

Se a infraestrutura é estável, o whitelist é mais seguro: na configuração não fica nenhum segredo que possa ser copiado. Se o endereço do cliente muda, o login e senha é inevitável — nesse caso, o ideal é guardá-lo em variáveis de ambiente ou em um gerenciador de segredos, e não em texto aberto no repositório.

Você pode escolher o tipo de autenticação e configurar o acesso para a sua infraestrutura na seção de proxies. Ali também dá para ver quais canais aceitam whitelist e quais são entregues só com login e senha — vale conferir isso antes de pagar, e não depois da primeira recusa de conexão.