Charles är stängt, men din Mac pekar fortfarande på 127.0.0.1

Ett program misslyckas och VPN:en får skulden, men begäran når aldrig tunneln. Om macOS fortfarande säger åt programmet att använda en lokal proxy är första hoppet 127.0.0.1 och inget lyssnar där. Att stänga Charles rensar inte alltid systemproxyinställningen det installerade, så en frisk VPN sitter bakom en död socket. Här är ordningen för att bekräfta det och bara reparera den felaktiga delen.

Första hoppet är den här Macen, inte servern

Läs adressen bokstavligt: 127.0.0.1 är maskinen framför dig, och porten är den som proxyverktyget konfigurerades att lyssna på. När lyssnaren är borta misslyckas anslutningen omedelbart med en nekad anslutning i stället för en timeout, och det är den användbara ledtråden.

En VPN skapar inte egna proxyinställningar och tar inte bort systemets. De två konfigurationerna är oberoende, vilket är varför tunneln kan vara perfekt och webbläsaren ändå oanvändbar. Det oberoendet är också varför felet överlever en återanslutning av VPN:en, en omstart och en ny profil. Inget i VPN-vägen rör någonsin proxylagret.

Steg 1: läs det aktuella proxytillståndet

Börja med den skrivskyddade vyn, eftersom den berättar vad systemet tror innan något program tolkar det:

scutil --proxy

Titta på HTTPEnable, HTTPProxy, HTTPPort, HTTPS-motsvarigheterna och eventuell ProxyAutoConfigEnable med sin URL. En aktiverad proxy med en port där inget lyssnar är ditt fel. En PAC-URL är den andra formen: inställningen kan vara aktiv utan synlig manuell adress, eftersom filen väljer proxyn vid begäran.

Bekräfta sedan samma värden i Systeminställningar, Nätverk, tjänsten du faktiskt använder, Information, Proxyservrar. Gränssnittet och kommandot läser samma lager, så en avvikelse betyder att du tittar på en annan tjänst.

Steg 2: ta reda på vem som äger inställningen

Tre ägare skapar detta tillstånd: ett proxyverktyg som installerade en hjälpare och inte städade, en hanterad konfigurationsprofil från din organisation och en manuell inställning som någon lade till under felsökning. Var och en har en annan korrekt åtgärd, och bara den första är din att ta bort lättvindigt.

Charles dokumenterar sin integration med webbläsare och systemproxy, inklusive macOS-hjälparen, så använd först dess egna kontroller och avstängningsväg. Den privilegierade hjälparen finns för att ändra konfiguration; det är inte skäl att ge orelaterad programvara bred åtkomst till maskinen.

Om inställningen kom från en hanterad profil misslyckas lokal avaktivering eller återställs vid nästa incheckning. Behandla det som en policyfråga för den som äger profilen, inte som en lokal bugg.

Steg 3: ändra det minsta

Inaktivera den specifika oönskade posten för den specifika tjänsten. Växla inte varje tjänst och töm inte hela proxypanelen, eftersom VPN-tjänsten och den underliggande Wi-Fi-tjänsten har separata inställningar och en av dem kan vara korrekt.

Om proxyn är avsiktligt nödvändig, starta dess godkända lyssnare i stället för att radera policyn. Den skillnaden spelar roll i organisationer där proxyn är den enda vägen till internet och VPN:en är en andra, smalare väg.

Försök igen med en ny begäran från det drabbade programmet. Vissa program läser proxyn en gång vid start, så att avsluta och öppna igen är en del av testet och inte vidskepelse.

Steg 4: om proxyn är borta och det fortfarande misslyckas

Då har du ett annat problem, och det nya felet är det användbara beviset. Namnuppslagning, VPN-routing, TLS-förtroende och programauktorisering är fyra separata kontroller, och var och en ger ett urskiljbart fel.

Håll certifikatförtroende utanför den här reparationen. Att ta bort en betrodd rot eller försvaga servervalideringen reparerar inte en död proxysocket, och det lämnar dig med två ändringar och ett ursprungligt fel. Om en företagsproxy inspekterar TLS är det en medveten design med sitt eget förtroendekrav, inte en bieffekt att ångra. Fråga teamet som äger proxyn innan du rör ett certifikat, eftersom deras svar handlar om policy och ditt om en misslyckad begäran.

Skriv återställningen innan du börjar: anteckna de exakta proxyvärden du hittade, så att återställningen blir en kopia och inte en minnesövning. Charles dokumentation om proxykonfiguration beskriver integrationen och dess avstängningsbeteende för den version du kör.

Nästa gång ett program misslyckas på en VPN, kontrollera första hoppet före tunneln. Det kostar ett kommando och utesluter en hel kategori feldiagnos.