O Charles foi fechado, mas o seu Mac continua a apontar para 127.0.0.1

Uma aplicação falha e a VPN leva a culpa, mas o pedido nunca chega ao túnel. Se o macOS continua a dizer a essa aplicação para usar um proxy local, o primeiro salto é 127.0.0.1 e não há nada a escutar nesse endereço. Fechar o Charles nem sempre limpa a definição de proxy do sistema que ele instalou, por isso uma VPN saudável fica atrás de um socket morto. Eis a ordem para confirmar isso e corrigir apenas a peça errada.

O primeiro salto é este Mac, não o servidor

Leia o endereço à letra: 127.0.0.1 é a máquina à sua frente, e a porta é aquela em que a ferramenta de proxy foi configurada para escutar. Quando esse listener desaparece, a ligação falha imediatamente com uma ligação recusada em vez de um timeout, e essa é a pista útil.

Uma VPN não cria as suas próprias definições de proxy nem remove as do sistema. As duas configurações são independentes, e é por isso que o túnel pode estar perfeito e o navegador continuar inutilizável. Essa independência também explica por que a falha sobrevive a uma reconexão da VPN, a um reinício e a um perfil novo. Nada no percurso da VPN toca alguma vez no armazenamento do proxy.

Passo 1: leia o estado atual do proxy

Comece pela vista só de leitura, porque ela diz o que o sistema acredita antes de qualquer aplicação o interpretar:

scutil --proxy

Veja HTTPEnable, HTTPProxy, HTTPPort, os equivalentes HTTPS e qualquer ProxyAutoConfigEnable com o respetivo URL. Um proxy ativo com uma porta onde nada escuta é a sua falha. Um URL PAC é a outra forma: a definição pode estar ativa sem endereço manual visível, porque o ficheiro escolhe o proxy no momento do pedido.

Depois confirme os mesmos valores em Definições do Sistema, Rede, no serviço que está realmente a usar, Detalhes, Proxies. A interface gráfica e o comando leem o mesmo armazenamento, por isso uma divergência significa que está a olhar para outro serviço.

Passo 2: descubra quem é o dono da definição

Três donos produzem este estado: uma ferramenta de proxy que instalou um auxiliar e não o limpou, um perfil de configuração gerido da sua organização e uma definição manual que alguém acrescentou durante a depuração. Cada um tem uma correção correta diferente, e só o primeiro é seu para remover sem cuidado.

O Charles documenta a integração com o navegador e com o proxy do sistema, incluindo o auxiliar do macOS, por isso use primeiro os seus próprios controlos e o caminho de encerramento. O auxiliar privilegiado existe para alterar configuração; isso não é razão para dar a software não relacionado acesso amplo à máquina.

Se a definição veio de um perfil gerido, desativá-la localmente ou falha ou é reposta no check-in seguinte. Trate isso como uma questão de política para o dono do perfil, não como um bug local.

Passo 3: altere a coisa mais estreita

Desative a entrada específica indesejada para o serviço específico. Não alterne todos os serviços e não limpe o painel inteiro de proxy, porque o serviço VPN e o serviço Wi-Fi subjacente guardam definições separadas e uma delas pode estar correta.

Se o proxy for intencionalmente necessário, inicie o listener aprovado em vez de apagar a política. Essa distinção importa em organizações onde o proxy é a única rota para a internet e a VPN é um segundo caminho, mais estreito.

Repita um pedido novo a partir da aplicação afetada. Algumas aplicações leem o proxy uma vez no arranque, por isso sair e reabrir faz parte do teste e não é superstição.

Passo 4: se o proxy desapareceu e ainda falha

Então tem outro problema, e o novo erro é a evidência útil. Resolução de nomes, Encaminhamento VPN, confiança TLS e autorização da aplicação são quatro verificações separadas, e cada uma produz uma falha distinguível.

Mantenha a confiança dos certificados fora desta reparação. Remover uma raiz fidedigna ou enfraquecer a validação do servidor não corrige um socket de proxy morto, e deixa-o com duas alterações e uma falha original. Se um proxy empresarial inspeciona TLS, isso é um desenho deliberado com o seu próprio requisito de confiança, não um efeito secundário a desfazer. Pergunte à equipa que detém o proxy antes de tocar num certificado, porque a resposta deles será sobre política e a sua sobre um pedido falhado.

Escreva o rollback antes de começar: anote os valores exatos de proxy que encontrou, para que restaurar seja uma cópia e não um exercício de memória. Documentação de configuração do proxy do Charles descreve a integração e o comportamento de encerramento para a versão que executa.

Da próxima vez que uma aplicação falhar numa VPN, verifique o primeiro salto antes do túnel. Custa um comando e elimina uma categoria inteira de diagnóstico errado.