Autenticação de proxy de navegador sem cabeça não é uma rota VPN

Uma VPN pode transportar o tráfego de um navegador para um servidor proxy e ainda assim deixar o navegador incapaz de usar esse proxy, porque uma rota e uma credencial são coisas diferentes. A automação sem cabeça torna a lacuna mais difícil de ver, uma vez que não há janela nem aviso para perceber. A falha geralmente aparece como um travamento ou um erro genérico de navegação, e o primeiro instinto é culpar o túnel. A lista de verificação abaixo separa as quatro coisas que devem ser verdadeiras antes que uma solicitação headless por meio de um proxy autenticado possa ser bem-sucedida.

Duas conversas, duas credenciais

Duas conversas acontecem e pertencem a partes diferentes. O navegador primeiro se conecta ao ouvinte do proxy, que pode contestá-lo em busca de credenciais; o proxy então faz ou permite a conexão direta com o destino. Uma VPN pode realizar a primeira etapa sem ser o endpoint que desafia o navegador, e não tem nada a dizer sobre a segunda.

HTTP 407 é o sinal de que o cliente deve se autenticar para a solicitação de proxy, realizada em Proxy-Authenticate com a resposta esperada em Proxy-Authorization. Esse não é o login do site de destino, e misturar os dois é a fonte mais comum de confusão aqui.

Portanto, as quatro verificações são: qual proxy o navegador realmente selecionou, quem responde ao 407, em qual rede o processo do navegador está e como a credencial é entregue sem um humano. Cada um pode falhar independentemente e cada falha parece semelhante vista de fora. Trabalhe-os em ordem, porque uma verificação posterior não pode compensar uma anterior. Um proxy que nunca foi selecionado não pode ser autenticado e uma credencial que existe apenas no seu laptop não pode alcançar um contêiner.

Verifique 1: qual proxy está realmente selecionado

Comece com a seleção, porque um navegador que ignora sua configuração de proxy nunca alcança o desafio. No Chrome a flag é --proxy-server=proxy.example:3128 , com --proxy-bypass-list para exclusões, e o Selenium expõe a mesma coisa através das opções do navegador. Um arquivo PAC é um mecanismo diferente com seus próprios modos de falha.

Em seguida, confirme dentro do ambiente do navegador em execução, e não no shell. Uma análise independente com o mesmo proxy é curl -x http://proxy.example:3128 -v https://example.com e sua saída detalhada mostra se o CONNECT foi bem-sucedido, o que Proxy-Authenticate retornou e se um 407 foi retornado. Se curl obtiver 407 e o navegador travar, o caminho da credencial é o problema, e não a rede. Se o curl for bem-sucedido e o navegador não, o navegador não está usando o proxy que você pensa que está.

Verifique 2: quem responde o 407

Um 407 tem um proprietário e nomeá-lo decide para onde vai a correção. Se o desafio vier do proxy corporativo, a correção será uma credencial que o navegador poderá apresentar sem supervisão. Se vier de um proxy upstream para o qual o primeiro encaminha, a credencial pertencerá a esse segundo salto e o primeiro proxy poderá estar retransmitindo o desafio inalterado. Leia o escopo de autenticação e o host no cabeçalho Proxy-Authenticate, pois eles nomeiam a caixa que está perguntando.

Preserve essa distinção em tudo o que você registrar. Um desafio de proxy, uma conexão recusada, um login no site e um tempo limite de transporte VPN são quatro falhas diferentes com quatro proprietários diferentes, e uma mensagem de erro genérica destrói as informações que você precisa.

Verifique 3: o caminho da credencial

A credencial em si é onde a maioria das configurações autônomas falha. O Selenium pode definir um host e uma porta proxy, mas a autenticação proxy HTTP não é uma parte portátil dessa configuração e as credenciais na URL do proxy não são um mecanismo no qual você pode confiar em navegadores e versões de driver. As opções suportadas são aquelas que sua pilha real documenta: uma extensão de navegador que responde ao desafio, um proxy de encaminhamento local que adiciona o cabeçalho e é acessível apenas a partir do trabalho ou um proxy que autentica a carga de trabalho por outros meios. Escolha um deliberadamente e compare-o com as versões exatas do navegador, driver e Selenium que você executará.

Mantenha a credencial fora de locais que a vazem. As linhas de comando são visíveis nas listagens de processos, as capturas de tela acabam em relatórios de teste, os rastreamentos do navegador e os arquivos HAR capturam os cabeçalhos e a configuração de teste confirmada é para sempre. Use o mecanismo de entrega secreta do trabalho e suas regras de redação e defina o escopo da conta proxy para os destinos ou a função necessária.

Se a organização oferecer uma rota VPN direta permitida em vez de um proxy obrigatório, compare os dois designs explicitamente. Não desative silenciosamente o proxy ou imite a autenticação de outro cliente para contornar a política.

Verifique 4: o próprio contexto de rede do processo do navegador

Esta é a verificação que as pessoas ignoram. Um navegador iniciado por um trabalhador, um contêiner ou um nó remoto do Selenium Grid usa a rede desse ambiente, portanto, a conexão VPN do seu laptop e as variáveis proxy do seu shell descrevem um caminho que o navegador nunca poderá tocar.

Registre cinco fatos para o trabalho com falha: o host do navegador, o proxy configurado, o caminho inicial do resolvedor, a rota selecionada e o proprietário da autenticação. Em seguida, faça uma solicitação autorizada inofensiva desse contexto exato, com a verificação TLS de destino normal e a autorização do aplicativo ativadas. Um navegador headless iniciado com sucesso não prova nem a admissão de proxy nem a cobertura VPN, e uma captura de tela de uma página em branco não prova absolutamente nada. A solicitação que retorna 200 através de toda a cadeia é a única evidência que conta.

O fluxo de trabalho finalizado possui três propriedades que vale a pena verificar como um conjunto. Há uma rota suportada do host do navegador para o proxy, uma política intermediária explícita que nomeia o proxy e os destinos e um ciclo de vida de credencial que não depende de um operador responder a um prompt invisível. Se algum dos três depender de uma pessoa, o trabalho ainda não está abandonado, independentemente do código de saída. Anote os cinco fatos antes que a próxima pessoa herde o pipeline.