← Voltar ao blog
RUENESZHARPTDEFRJAKOITTRIDVIFAHI

Proxies com login e senha em programas sem autenticação: gateway local com gost, 3proxy, Squid e proxychains

O programa solicita apenas o endereço e a porta, mas o proxy tem login e senha? Levante o gateway local: gost com um comando, 3proxy com porta para cada perfil, Squid com log ou proxychains-ng para software sem suporte a proxy. Comandos, configurações e erros que fazem vazar o IP real.

📅11 de outubro de 2026
Proxies com login e senha em programas sem autenticação: gateway local com gost, 3proxy, Squid e proxychains

Você comprou um proxy, recebeu uma string do tipo login:password@host:port, e o programa pede apenas "endereço e porta". Situação familiar: Chrome com a flag --proxy-server, configurações do sistema Windows e Android, um parser antigo, Selenium-grid, uma ferramenta sem campo para senha. A solução é a mesma há muitos anos — gateway local: um pequeno proxy na sua própria máquina, que aceita conexões sem senha e insere o login ao se conectar ao verdadeiro proxy. Vamos analisar quatro ferramentas testadas, comandos para cada uma e os erros que normalmente fazem perder tempo e dinheiro.

Por que os programas "não entendem" proxies com senha

Existem duas maneiras de se autenticar com o provedor de proxy: por login e senha (Basic Auth) ou por lista branca de IP. A segunda opção elimina o problema, mas funciona apenas se você tiver um IP externo fixo — a internet doméstica e as redes móveis frequentemente não têm isso, e nas funções em nuvem ele muda a cada execução. Comparámos detalhadamente ambas as maneiras em um guia sobre autenticação de proxy.

Com login e senha, esbarramos nas limitações dos próprios programas:

  • Chrome e Chromium. A flag --proxy-server na documentação do Chromium aceita esquema, host e porta (por exemplo, --proxy-server="foopy:8080") — não há campos para credenciais nessa sintaxe. Na janela normal do navegador, será exibido um diálogo com a senha, mas no modo headless e em testes automatizados, não há ninguém para preenchê-lo.
  • Configurações do sistema. Na configuração manual de proxy do Windows e nas configurações de Wi-Fi na maioria das versões do Android, há apenas host e porta. A senha será solicitada por um aplicativo específico ou não poderá ser inserida em lugar algum.
  • Software antigo e feito sob medida. Muitas ferramentas e bibliotecas suportam proxies, mas sem autenticação, ou falham com caracteres especiais na senha.
  • Programas sem suporte a proxy. Ferramentas de console que não leem variáveis de ambiente nem configurações.

O gateway local resolve todos os quatro casos: o programa vê o proxy 127.0.0.1:8080 sem senha, e o gateway redireciona o tráfego para o provedor já com o login.

Como funciona o esquema

  1. Na sua máquina (ou VPS, onde o parser está rodando), um servidor proxy leve é iniciado e escuta uma porta local, por exemplo, 127.0.0.1:8080.
  2. No config do gateway, é especificado o proxy "pai" (upstream) — o endereço do provedor, login e senha.
  3. O programa se conecta à porta local sem autenticação.
  4. O gateway abre uma conexão com o provedor, passa pela autenticação e redireciona o tráfego adiante. Para o site, você aparece com o IP do provedor, e não o seu.

HTTPS, nesse caso, não é decifrado: através do proxy HTTP, o navegador estabelece um túnel usando o método CONNECT, e o gateway simplesmente transmite os bytes criptografados.

Opção 1: gost — um comando, sem configs

gost (GO Simple Tunnel) — um único arquivo executável em Go para Windows, macOS e Linux. É a maneira mais rápida de levantar um gateway. No gost, a flag -L define o serviço local, -F — o nó através do qual redirecionar o tráfego. As credenciais são especificadas diretamente no endereço do nó:

gost -L http://127.0.0.1:8080 -F socks5://LOGIN:PASSWORD@HOST:PORT

Agora qualquer programa pode usar o proxy HTTP 127.0.0.1:8080 sem senha. Se a senha contém caracteres especiais (@, :, #), a documentação do gost sugere passá-los através do parâmetro auth em base64:

echo -n LOGIN:PASSWORD | base64
gost -L http://127.0.0.1:8080 -F socks5://HOST:PORT?auth=<resultado_base64>

Note: se o auth for especificado, o login e a senha escritos diretamente no endereço serão ignorados pelo gost. Várias flags -F em sequência formam uma cadeia de vários proxies.

Quando usar: quando você precisa rapidamente "conectar" um navegador ou script a um proxy, sem instalar pacotes ou editar configs.

Opção 2: 3proxy — muitos ports em uma máquina

3proxy — um servidor proxy compacto com configuração em um único arquivo. A diretiva chave é parent; segundo a documentação, sua sintaxe é: parent <weight> <type> <ip> <port> <username> <password>, e deve vir após a regra allow. A configuração mínima do gateway:

auth iponly
allow * 127.0.0.1
parent 1000 http HOST PORT LOGIN PASSWORD
proxy -p8080 -i127.0.0.1

O que é importante aqui:

  • auth iponly — sem senha, mas com verificação por ACL; a regra allow * 127.0.0.1 permite apenas conexões locais.
  • Peso 1000 significa "sempre através deste pai". Pesos abaixo de 1000 são usados pelo 3proxy para formar cadeias aleatórias.
  • Tipo de pai: http, connect, socks4, socks5 e outros — escolha o protocolo que foi fornecido pelo provedor.
  • -i127.0.0.1 vincula o serviço à interface local. Por padrão, o 3proxy aceita conexões em todas as interfaces.

Uma técnica conveniente: repetir o bloco allow / parent / proxy várias vezes com diferentes portas e diferentes contas do provedor. Assim, você obtém "porta = proxy separado": 127.0.0.1:8081 — EUA, :8082 — Alemanha e assim por diante. Este formato é compreendido pela maioria dos softwares, incluindo aqueles onde os proxies são inseridos em uma lista "host:porta".

Quando usar: dezenas de perfis ou fluxos, cada um precisa de sua própria saída.

Opção 3: Squid — se você precisa de cache e logs

Squid é mais pesado, mas oferece cache, logs detalhados e ACLs flexíveis. O provedor é especificado como um nó pai através de cache_peer, e a diretiva never_direct allow all proíbe o Squid de acessar a internet diretamente, ignorando o pai:

http_port 127.0.0.1:3128
cache_peer HOST parent PORT 0 no-query default login=LOGIN:PASSWORD
never_direct allow all

Nuances da documentação do Squid:

  • A porta ICP é definida como 0 se o pai não a suportar — proxies comerciais não têm isso.
  • No login=, são permitidas sequências de escape de URL (por exemplo, %20 para espaço), portanto, o símbolo % na senha deve ser escrito como %%.
  • Sem never_direct, o Squid pode decidir que é mais vantajoso acessar o site diretamente — e a solicitação sairá com seu IP real. Para scraping e multi-contas, esse é o pior cenário.

Quando usar: escritório ou equipe, onde é necessário registrar quem acessou o quê, ou solicitações repetidas aos mesmos recursos.

Opção 4: proxychains-ng — para programas sem suporte a proxy

Se o programa não suporta proxy de forma alguma, o proxychains-ng (Linux e macOS) pode ajudar. Ele intercepta chamadas de rede do programa e encapsula suas conexões TCP em um proxy. Suporta SOCKS4a, SOCKS5 e HTTP, autenticação — login e senha para SOCKS e Basic para HTTP. A linha na seção [ProxyList] tem o formato tipo ip porta [login senha]:

strict_chain
proxy_dns
tcp_read_time_out 15000
tcp_connect_time_out 8000

[ProxyList]
http HOST PORT LOGIN PASSWORD

Execução: proxychains4 curl https://api.ipify.org — na resposta, aparecerá o IP do provedor, e não o seu.

  • strict_chain — todos os proxies da lista são usados na ordem, e se um estiver indisponível, não haverá conexão. Mais seguro do que dynamic_chain, que ignora nós mortos.
  • proxy_dns — as solicitações DNS também passam pelo proxy. Sem isso, o provedor da sua internet vê quais domínios você está solicitando, e o site pode notar a discrepância entre a geolocalização do DNS e o IP.
  • A configuração é procurada na ordem: arquivo de -f ou variável PROXYCHAINS_CONF_FILE, depois ./proxychains.conf, ~/.proxychains/proxychains.conf e /etc/proxychains.conf.

Limitações, conforme mencionado pelos próprios autores: apenas TCP (UDP e ICMP não são proxyados), podem ocorrer falhas em programas que geram muitos processos, e no macOS, a proteção SIP não permite interceptar programas do sistema.

Qual ferramenta escolher: um guia rápido

  • Um navegador ou script, precisa "agora mesmo" — gost.
  • Muitos perfis, cada um com seu IP ou país — 3proxy com porta separada para cada conta.
  • Equipe, log de solicitações, cache — Squid.
  • Programa sem configurações de proxy — proxychains-ng.

Cinco erros que custam mais caro

  1. O gateway escuta todas as interfaces. Você iniciou o gost com -L http://:8080 em uma VPS — e obteve um proxy aberto para toda a internet nos seus gigabytes. Proxies abertos são rapidamente encontrados por scanners. Sempre especifique 127.0.0.1, e se o gateway for usado por outras máquinas — feche a porta com um firewall. Sobre como botnets rapidamente encontram portas abertas em servidores com parsers, escrevemos em uma análise do worm CARBONATO.
  2. Vazamento pela porta do gateway. Squid sem never_direct, proxychains sem proxy_dns, um navegador que se conecta diretamente via WebRTC/UDP — tudo isso revela o IP real. Verifique o resultado em um serviço de identificação de IP e em um teste de vazamento de DNS.
  3. Um gateway para todas as contas. Se 30 perfis de anti-detect estão olhando para uma porta com uma sessão sticky, todos terão o mesmo IP — isso é um caminho direto para a ligação de contas. Separe os perfis por portas ou use parâmetros de sessão do provedor.
  4. Caracteres especiais na senha. @ e : quebram a análise de endereços do tipo login:pass@host. Use o parâmetro base64 no gost, escape no Squid ou gere uma senha sem caracteres especiais.
  5. Gateway — um hop extra e ponto de falha. Na máquina local, a latência é quase zero, mas se o gateway estiver em outro data center, cada solicitação terá uma latência de rede adicional. Mantenha o gateway próximo ao programa e configure a inicialização automática (systemd, serviço do Windows), caso contrário, após a reinicialização do servidor, o parser irá silenciosamente para lugar nenhum.

Quais proxies usar atrás do gateway

O gateway não se importa com o tipo de proxy que está atrás dele — a escolha depende da tarefa:

  • Proxies residenciais — para scraping de sites protegidos, marketplaces e perfis anti-detect: IPs de usuários domésticos levantam menos suspeitas entre os anti-bots.
  • Proxies móveis — para redes sociais e aplicativos, onde a verificação é mais rigorosa: por trás de um IP de operador móvel (via CGNAT) geralmente saem muitos assinantes reais, e bloqueá-lo é arriscado para a própria plataforma.
  • Proxies de data center — para tarefas volumosas sem proteção rigorosa: verificações de disponibilidade, APIs, testes. Mais baratos por gigabyte.

Se o proxy tiver rotação, a lógica de troca de IP geralmente é definida pelo provedor — através de parâmetros no login ou configurações no painel. O gateway não quebra isso: ele transmite o login como está. Portanto, é conveniente levantar várias portas com diferentes parâmetros de sessão — uma com um novo IP a cada solicitação, outra com um IP fixo por 30 minutos.

Conclusão

Proxy com login e senha é adequado para qualquer programa, se você colocar um gateway local entre eles. O gost resolve a tarefa com um único comando, o 3proxy é conveniente para "porta = perfil", o Squid é para equipes com logs, e o proxychains-ng conecta até softwares que não sabem nada sobre proxies. As principais regras: escutar apenas 127.0.0.1, proibir conexões diretas que ignoram o pai e verificar se o site vê o IP do provedor, e não o seu.