Charles està tancat, però el teu Mac encara apunta a 127.0.0.1

Una aplicació falla i el VPN rep la culpa, però la petició no arriba mai al túnel. Si macOS encara diu a aquesta aplicació que faci servir un proxy local, el primer salt és 127.0.0.1 i no hi ha res escoltant-hi. Tancar el Charles no sempre neteja el paràmetre de proxy del sistema que va instal·lar, així que un VPN sa queda darrere d’un sòcol mort. Aquí tens l’ordre per confirmar-ho i arreglar només la peça que està malament.

El primer salt és aquest Mac, no el servidor

Llegeix l’adreça literalment: 127.0.0.1 és la màquina que tens al davant, i el port és el que fos que l’eina de proxy estava configurada a escoltar. Quan aquest oient desapareix, la connexió falla immediatament amb una connexió rebutjada en lloc d’un temps d’espera, i aquest és l’indicador útil.

Un VPN no crea els seus propis paràmetres de proxy ni elimina els del sistema. Les dues configuracions són independents, i per això el túnel pot ser perfecte i el navegador continuar sent inservible. Aquesta independència també explica per què la fallada sobreviu a una reconnexió del VPN, a un reinici i a un perfil nou. Res del camí del VPN no toca mai l’emmagatzematge de proxy.

Pas 1: llegeix l’estat actual del proxy

Comença per la vista de només lectura, perquè diu què creu el sistema abans que cap aplicació ho interpreti:

scutil --proxy

Mira HTTPEnable, HTTPProxy, HTTPPort, els equivalents per a HTTPS i qualsevol ProxyAutoConfigEnable amb la seva URL. Un proxy activat amb un port on no escolta res és la teva fallada. Una URL PAC és l’altra forma: el paràmetre pot estar actiu sense cap adreça manual visible, perquè el fitxer tria el proxy en el moment de la petició.

Després confirma els mateixos valors a Configuració del Sistema, Xarxa, el servei que utilitzes realment, Detalls, Proxies. La interfície gràfica i l’ordre llegeixen la mateixa base, així que un desacord vol dir que estàs mirant un altre servei.

Pas 2: troba qui és el propietari del paràmetre

Tres propietaris produeixen aquest estat: una eina de proxy que va instal·lar un assistent i no el va netejar, un perfil de configuració gestionat de la teva organització i un paràmetre manual que algú va afegir mentre depurava. Cadascun té una solució correcta diferent, i només el primer és teu per eliminar-lo sense miraments.

Charles documenta la seva integració amb el navegador i el proxy del sistema, inclòs l’assistent de macOS, així que fes servir primer els seus propis controls i la seva via d’aturada. L’assistent privilegiat existeix per canviar la configuració; no és una raó per donar a programari no relacionat accés ampli a la màquina.

Si el paràmetre ve d’un perfil gestionat, desactivar-lo localment o falla o es restaura a la propera comprovació. Tracta-ho com una qüestió de política per a qui posseeix el perfil, no com un error local.

Pas 3: canvia la cosa més estreta

Desactiva l’entrada específica no desitjada del servei específic. No commutis tots els serveis ni esborris tot el panell de proxy, perquè el servei del VPN i el servei de Wi-Fi subjacent guarden paràmetres separats i un d’ells pot ser correcte.

Si el proxy és necessari intencionadament, engega el seu oient aprovat en lloc d’esborrar la política. Aquesta distinció importa en organitzacions on el proxy és l’única ruta a internet i el VPN és un segon camí, més estret.

Torna a provar una petició nova des de l’aplicació afectada. Algunes aplicacions llegeixen el proxy una vegada en engegar-se, així que tancar-la i tornar-la a obrir forma part de la prova i no és superstició.

Pas 4: si el proxy ja no hi és i encara falla

Llavors tens un altre problema, i el nou error és l’evidència útil. La resolució de noms, l’encaminament del VPN, la confiança TLS i l’autorització d’aplicacions són quatre comprovacions separades, i cadascuna produeix una fallada distingible.

Deixa la confiança en els certificats fora d’aquesta reparació. Eliminar una arrel de confiança o debilitar la validació del servidor no arregla un sòcol de proxy mort i et deixa amb dos canvis i una fallada original. Si un proxy corporatiu inspecciona TLS, això és un disseny deliberat amb el seu propi requisit de confiança, no un efecte secundari a desfer. Pregunta a l’equip que posseeix el proxy abans de tocar un certificat, perquè la seva resposta serà sobre política i la teva sobre una petició fallida.

Escriu la reversió abans de començar: anota els valors exactes de proxy que has trobat, perquè restaurar-los sigui copiar i no un exercici de memòria. La documentació de configuració del proxy Charles descriu la integració i el seu comportament en tancar-se per a la versió que fas servir.

La propera vegada que una aplicació falli amb un VPN, comprova el primer salt abans del túnel. Costa una ordre i descarta tota una categoria de diagnòstic erroni.