Alguns proxies falham na primeira solicitação do navegador, enquanto o Chromium não aceita diretamente usuário e senha em SOCKS5. Este artigo explica os dois casos e o relay integrado que cuida deles.
O navegador abre um túnel de proxy HTTP com uma solicitação CONNECT e normalmente inclui o cabeçalho Host. Alguns servidores de proxy travam quando recebem esse cabeçalho: não concluem nem encerram a conexão, e a aba fica carregando sem parar. Parece que o proxy caiu, embora curl funciona por meio dele.
O relay integrado fica entre o Chromium e o proxy e reformula a solicitação no formato aceito pelo servidor. O Chromium fala com o relay por HTTP local simples; o relay envia a solicitação externa sem o cabeçalho problemático.
O Chromium só aceita SOCKS5 sem usuário e senha porque o caminho de autenticação do proxy não foi implementado. Um proxy no formato socks5://user:pass@host:1080 não funciona diretamente em nenhum navegador baseado nesse motor.
O relay abre um endpoint local sem credenciais, autentica-se no proxy externo e mantém o usuário e a senha fora do Chromium. O navegador recebe o endereço 127.0.0.1, enquanto o relay estabelece uma sessão autenticada completa com o proxy externo:
O NimbusX verifica país, cidade e fuso horário do proxy antes de iniciar o perfil. Se a localização entrar em conflito com o perfil, a abertura é interrompida e os valores divergentes são explicados.
America/New_York com um IP europeu, por isso o iphey retornava corretamente Unreliable. Agora a localização é resolvida antes do teste, para que cada perfil seja criado com configurações coerentes desde o início.Os proxies são conectados por conta própria, de qualquer um dos três tipos: HTTP, HTTPS, SOCKS5 com autorização. O adaptador liga sozinho e não requer configuração. Nenhum dos concorrentes analisados corrige proxies pendurados no cabeçalho Host: esses proxies simplesmente não funcionam para eles.
O que os testes públicos revelam · Perfis via código e assistentes de IA