O VPN funciona, mas um app não tem internet? Verifique o proxy dele

Seu túnel está ativo, a página de status mostra um handshake saudável, mas uma aplicação continua sem carregar nada. Essa aplicação provavelmente ainda envia as requisições a um intermediário mais antigo: um proxy do sistema, uma extensão, um arquivo de configuração empurrado pelo gerenciamento de dispositivos ou uma variável de proxy que só o próprio processo lê. Trocar de servidor VPN não toca nessa configuração, e isso explica o padrão em que outros apps funcionam na mesma máquina. Trabalhe da aplicação que falha para fora e deixe o túnel quieto até a questão do proxy ser resolvida.

Que camada possui a configuração do proxy

Quatro lugares podem reivindicar autoridade sobre as requisições de um app, e o mais estreito costuma vencer. O sistema operacional mantém um proxy global e uma URL de configuração automática opcional; um navegador pode segui-la, sobrepor-se a ela ou entregar o controle a uma extensão; uma ferramenta de linha de comando lê o próprio ambiente; e uma política gerenciada pode fixar novamente qualquer uma das anteriores após uma mudança. Decida qual camada é responsável antes de editar qualquer coisa, porque limpar a camada errada parece uma correção bem-sucedida que volta no próximo login.

Compare dois aplicativos contra o mesmo site comum em vez de contra uma página de teste só para VPN. Se o navegador falha enquanto um download no terminal funciona, o sistema operacional não é o problema, e a diferença está no perfil do navegador ou nas extensões dele. Se os dois falham mas uma segunda conta de usuário na mesma máquina funciona, a configuração é por usuário. Essa comparação custa um minuto e elimina a maior parte das suposições.

Leia o valor que cada ferramenta realmente usa

Imprima a configuração antes de mudá-la e copie a string de proxy exata para um lugar de onde possa restaurá-la. As variáveis do shell são a verificação mais rápida para ferramentas de linha de comando, porque um cliente VPN normalmente as deixa intactas.

env | grep -i -E 'http_proxy|https_proxy|all_proxy|no_proxy'
scutil --proxy
gsettings get org.gnome.system.proxy mode
netsh winhttp show proxy

Execute apenas a linha que corresponde à plataforma à sua frente e depois leia a saída para host, porta e credenciais. Um valor como http://proxy.corp.example:8080 significa que a ferramenta pergunta a esse host em cada requisição, enquanto um resultado vazio significa que ela vai direto e a falha real está em outro lugar. Oculte a parte de usuário e senha antes de colar a saída em um ticket, porque essas strings são credenciais vivas muito mais vezes do que as pessoas supõem.

Ferramentas com o próprio motor de proxy precisam das próprias evidências. O Curl informa a decisão que tomou quando você aumenta a verbosidade, o que é melhor do que adivinhar pelo ambiente, e a mesma opção mostra se a resolução de nomes ocorreu localmente ou no proxy.

Apague a sobreposição e teste novamente a mesma requisição

Mude uma camada e depois repita exatamente a requisição que falhou, porque outra URL não prova nada. Limpe primeiro as variáveis de ambiente no shell atual, já que essa alteração é reversível e não pode quebrar o túnel:

unset http_proxy https_proxy all_proxy
curl -v --max-time 10 https://example.com 2>&1 | grep -i -E 'uses proxy|connected to|http/'

Se a saída detalhada ainda afirma haver um proxy, o ambiente não era a autoridade. Suba um nível em vez de empilhar mais sobreposições.

No macOS, verifique se um arquivo de configuração automática não está fornecendo o valor, depois desligue o proxy do serviço e confirme a mudança. No Windows, lembre-se de que a configuração WinHTTP e a configuração do navegador por usuário são objetos diferentes, então uma ferramenta de linha de comando limpa pode conviver com um navegador que ainda aponta para um servidor antigo. As extensões merecem a mesma desconfiança: uma extensão de proxy pode reescrever requisições só para um perfil, e essa é exatamente a forma de uma falha que atinge um navegador e nada mais.

Confirme que a correção sobrevive a uma reinicialização

Uma configuração que só funciona no terminal que você editou não está corrigida. Abra o aplicativo de novo pelo lançador da área de trabalho, saia e entre outra vez, e observe se o proxy antigo volta.

Duas verificações separam uma correção real de uma temporária, e as duas devem relatar uma conexão direta ou o valor pretendido. A execução em ambiente limpo mostra se um processo depurado ainda pega uma configuração do sistema.

env -i /usr/bin/curl -sS -o /dev/null -w '%{http_code} %{remote_ip}
' https://example.com
networksetup -getwebproxy "Wi-Fi"

Se o valor antigo volta após uma reinicialização, a fonte é uma política gerenciada ou um perfil que a reaplica, e o dono dessa política precisa remover a exceção. Mantenha a verificação de certificados ativa o tempo todo, porque um proxy que intercepta tráfego vai parecer resolvido assim que você desativar as verificações. Termine escrevendo o valor removido e a data nas suas notas, para que a próxima pessoa distinga um proxy intencional de um esquecido.