GoLiveBypass v1.1.0

Suporte a proxy com usuário e senha, pedido por quem tentou usar um proxy da AWS com login e não conseguiu.

Como usar

No campo Proxy do plugin, ou no settings.json do standalone:

socks5://usuario:senha@host:porta
http://usuario:senha@host:porta

Funciona para SOCKS5 (método 2 do RFC 1929) e para proxy HTTP (Proxy-Authorization: Basic).

Se a sua senha tiver @ ou :, codifique esses caracteres — @ vira %40, : vira %3A. Sem isso não há como saber onde a senha termina e o endereço começa.

A senha nunca aparece no registro. O arquivo de log é colado em relato de problema, e o endereço aparecia cru em nove pontos dele.

O que estava faltando

Nenhum dos dois modos aceitava credencial. O endereço era recusado já na validação, e a negociação SOCKS5 anunciava apenas o método 0, "sem autenticação" — então um proxy que exige login respondia 0xFF e a conexão morria ali.

Tem uma peça que só aparece no uso real e que é fácil de esquecer: a regra que instalamos no Chromium não carrega usuário e senha, ela só diz o endereço. Quem responde ao pedido de autenticação é o próprio Chromium. Sem tratar isso, o proxy com senha passaria nos nossos testes — que negociam na mão — e falharia no Discord.

O tratador só responde quando o pedido é de proxy e quando o host e a porta batem com a saída em uso. Sem essas duas checagens, a sua credencial iria para qualquer site que a pedisse.

Testado

Contra um servidor SOCKS5 que exige autenticação:

credencial certa:   CONECTOU
credencial errada:  recusado
sem credencial:     recusado

E o endereço socks5://user:se%40nha%3Acom%40roba@proxy.aws.com:1080 é lido como usuário user, senha se@nha:com@roba, host proxy.aws.com:1080.

Atualizar

Baixe o instalador aqui embaixo. Quem usa proxy sem senha não precisa mudar nada — o formato antigo continua valendo igual.

Também na instalação

Os instaladores recusavam o endereço com login na própria pergunta, então o suporte não existia para quem instala pelo caminho normal. Agora os quatro aceitam, e a pergunta explica o formato.

Três detalhes que só aparecem quando a senha é real:

• O instalador do standalone no Linux gravava o settings.json interpolando o valor direto. Uma senha com " ou \ produzia um arquivo inválido, e o bypass voltava ao padrão em silêncio. Agora é escapado, e o arquivo nasce com permissão 600.
• O endereço aparecia na tela no fim da instalação — justamente a parte que as pessoas fotografam para mostrar que deu certo. A senha some do que é exibido.
• O -Proxy e o --proxy do standalone não validavam nada: um erro de digitação virava configuração, e o bypass caía para a lista gratuita sem dizer por quê.