Charles er lukket, men din Mac peger stadig på 127.0.0.1

Et program fejler, og VPN’en får skylden, men forespørgslen når aldrig tunnelen. Hvis macOS stadig fortæller det program at bruge en lokal proxy, er det første hop 127.0.0.1, og der lytter intet. At lukke Charles rydder ikke altid den systemproxy-indstilling, det installerede, så en sund VPN står bag en død socket. Her er rækkefølgen for at bekræfte det og kun rette den del, der er forkert.

Det første hop er denne Mac, ikke serveren

Læs adressen bogstaveligt: 127.0.0.1 er maskinen foran dig, og porten er den, proxy-værktøjet var konfigureret til at lytte på. Når den lytter er væk, fejler forbindelsen straks med en afvist forbindelse i stedet for en timeout, og det er det nyttige spor.

En VPN opretter ikke sine egne proxy-indstillinger og fjerner ikke systemets. De to konfigurationer er uafhængige, og derfor kan tunnelen være perfekt, mens browseren stadig er ubrugelig. Den uafhængighed er også grunden til, at fejlen overlever en VPN-genopkobling, en genstart og en ny profil. Intet i VPN-stien rører nogensinde proxy-lageret.

Trin 1: læs den aktuelle proxy-tilstand

Begynd med skrivebeskyttet visning, fordi den fortæller, hvad systemet tror, før nogen applikation fortolker det:

scutil --proxy

Se på HTTPEnable, HTTPProxy, HTTPPort, HTTPS-modstykkerne og enhver ProxyAutoConfigEnable med dens URL. En aktiveret proxy på en port, hvor intet lytter, er din fejl. En PAC-URL er den anden form: indstillingen kan være aktiv uden en synlig manuel adresse, fordi filen vælger proxyen på forespørgselstidspunktet.

Bekræft derefter de samme værdier i Systemindstillinger, Netværk, den tjeneste du faktisk bruger, Detaljer, Proxyer. GUI’et og kommandoen læser samme lager, så uenighed betyder, at du ser på en anden tjeneste.

Trin 2: find ud af, hvem der ejer indstillingen

Tre ejere skaber denne tilstand: et proxy-værktøj, der installerede en hjælper og ikke ryddede op, en administreret konfigurationsprofil fra din organisation og en manuel indstilling, som nogen tilføjede under fejlfinding. Hver har sin egen korrekte løsning, og kun den første kan du fjerne uden videre.

Charles dokumenterer sin browser- og systemproxy-integration, inklusive macOS-hjælperen, så brug først dets egne kontroller og nedlukningsvej. Den privilegerede hjælper findes for at ændre konfiguration; det er ikke grund til at give uvedkommende software bred adgang til maskinen.

Hvis indstillingen kommer fra en administreret profil, vil det enten fejle at deaktivere den lokalt, eller den gendannes ved næste check-in. Behandl det som et politikspørgsmål for den, der ejer profilen, ikke som en lokal fejl.

Trin 3: ændr kun det mindste

Deaktivér den specifikke utilsigtede post for den specifikke tjeneste. Slå ikke hver tjeneste til og fra, og ryd ikke hele proxy-panelet, fordi VPN-tjenesten og den underliggende Wi-Fi-tjeneste har separate indstillinger, og en af dem kan være korrekt.

Hvis proxyen er bevidst påkrævet, start dens godkendte lytter i stedet for at slette politikken. Den forskel betyder noget i organisationer, hvor proxyen er den eneste vej til internettet, og VPN’en er en anden, snævrere vej.

Prøv en enkelt frisk forespørgsel fra det berørte program. Nogle programmer læser proxyen én gang ved opstart, så at afslutte og genåbne er en del af testen, ikke overtro.

Trin 4: hvis proxyen er væk, og det stadig fejler

Så har du et andet problem, og den nye fejl er det nyttige bevis. Navneopløsning, VPN-routing, TLS-tillid og applikationsgodkendelse er fire separate kontroller, og hver giver en fejl, der kan skelnes.

Hold certifikattillid uden for denne reparation. At fjerne en betroet rod eller svække servervalideringen retter ikke en død proxy-socket og efterlader dig med to ændringer og en oprindelig fejl. Hvis en virksomhedsproxy inspicerer TLS, er det et bevidst design med sit eget tillidskrav, ikke en bivirkning, der skal fortrydes. Spørg teamet, der ejer proxyen, før du rører et certifikat, for deres svar handler om politik, og dit handler om én mislykket forespørgsel.

Skriv rollback-planen, før du begynder: notér de præcise proxy-værdier, du fandt, så gendannelse er en kopi og ikke en hukommelsesøvelse. Charles’ dokumentation for proxy-konfiguration beskriver integrationen og dens nedlukningsadfærd for den version, du kører.

Næste gang et program fejler på en VPN, tjek det første hop før tunnelen. Det koster én kommando og udelukker en hel kategori af fejldiagnose.