Charles pechou, pero o teu Mac segue apuntando a 127.0.0.1

Unha aplicación falla e a culpa cae no VPN, pero a petición nunca chega ao túnel. Se macOS segue dicíndolle a esa aplicación que use un proxy local, o primeiro salto é 127.0.0.1 e non hai nada escoitando nel. Pechar Charles non sempre borra o axuste de proxy do sistema que instalou, así que un VPN san queda detrás dun socket morto. Velaquí a orde para confirmalo e arranxar só a peza que está mal.

O primeiro salto é este Mac, non o servidor

Le o enderezo ao pé da letra: 127.0.0.1 é a máquina que tes diante, e o porto é o que a ferramenta de proxy tivese configurado para escoitar. Cando ese oínte desaparece, a conexión falla de inmediato cunha conexión rexeitada en lugar dun tempo de espera, e esa é a pista útil.

Un VPN non crea os seus propios axustes de proxy nin elimina os do sistema. As dúas configuracións son independentes, por iso o túnel pode ser perfecto e o navegador seguir inservible. Esa independencia tamén explica por que o fallo sobrevive a unha reconexión do VPN, a un reinicio e a un perfil novo. Nada na ruta do VPN toca xamais o almacén de proxy.

Paso 1: le o estado actual do proxy

Comeza pola vista de só lectura, porque di o que cre o sistema antes de que o interprete calquera aplicación:

scutil --proxy

Mira HTTPEnable, HTTPProxy, HTTPPort, os equivalentes de HTTPS e calquera ProxyAutoConfigEnable co seu URL. Un proxy activado nun porto onde nada escoita é o teu fallo. Un URL PAC é a outra forma: o axuste pode estar activo sen un enderezo manual visible, porque o ficheiro escolle o proxy no momento da petición.

Despois confirma os mesmos valores en Axustes do Sistema, Rede, o servizo que usas de verdade, Detalles, Proxies. A interface gráfica e a orde len o mesmo almacén, así que un desacordo significa que estás mirando outro servizo.

Paso 2: averigua quen é o dono do axuste

Tres donos producen este estado: unha ferramenta de proxy que instalou un asistente e non o limpou, un perfil de configuración xestionado da túa organización e un axuste manual que alguén engadiu mentres depuraba. Cada un ten unha solución correcta distinta, e só o primeiro é teu para quitalo sen máis.

Charles documenta a súa integración co navegador e o proxy do sistema, incluído o asistente de macOS, así que usa primeiro os seus propios controis e a súa ruta de apagado. O asistente privilexiado existe para cambiar a configuración; iso non é razón para darlle a software sen relación acceso amplo á máquina.

Se o axuste veu dun perfil xestionado, desactivalo localmente ou falla ou se restaura na seguinte comprobación. Trátao como unha cuestión de política para quen posúe o perfil, non como un fallo local.

Paso 3: cambia o máis estreito

Desactiva a entrada concreta non desexada do servizo concreto. Non alternes todos os servizos nin borres todo o panel de proxy, porque o servizo do VPN e o servizo de Wi-Fi subxacente gardan axustes separados e un deles pode ser correcto.

Se o proxy é necesario a propósito, arrinca o seu oínte aprobado en lugar de borrar a política. Esa distinción importa en organizacións onde o proxy é a única ruta a internet e o VPN é un segundo camiño, máis estreito.

Volve tentar unha petición nova desde a aplicación afectada. Algunhas aplicacións len o proxy unha vez ao arrincar, así que pechala e volvela abrir forma parte da proba e non é superstición.

Paso 4: se o proxy xa non está e segue fallando

Entón tes outro problema, e o novo erro é a evidencia útil. A resolución de nomes, o encamiñamento do VPN, a confianza TLS e a autorización de aplicacións son catro comprobacións separadas, e cada unha produce un fallo distinguible.

Mantén a confianza nos certificados fóra desta reparación. Quitar unha raíz de confianza ou debilitar a validación do servidor non arranxa un socket de proxy morto e déixache con dous cambios e un fallo orixinal. Se un proxy corporativo inspecciona TLS, iso é un deseño deliberado co seu propio requisito de confianza, non un efecto secundario que desfacer. Pregunta ao equipo dono do proxy antes de tocar un certificado, porque a súa resposta será sobre política e a túa sobre unha petición fallida.

Escribe a reversión antes de comezar: anota os valores exactos de proxy que atopaches, para que restaurar sexa copiar e non un exercicio de memoria. A documentación de configuración do proxy Charles describe a integración e o seu comportamento ao apagarse para a versión que executas.

A próxima vez que unha aplicación falle cun VPN, comproba o primeiro salto antes do túnel. Custa unha orde e descarta toda unha categoría de diagnóstico erróneo.