VPN fungerar, men en app har inget internet? Kontrollera dess proxy

Din tunnel är uppe, statussidan visar en sund handskakning, men en applikation laddar fortfarande ingenting. Den applikationen skickar förmodligen fortfarande sina förfrågningar till en äldre mellanhand: en systemproxy, ett tillägg, en konfigurationsfil som skjuts ut av enhetshantering, eller en proxyvariabel som bara dess egen process läser. Att byta VPN-server rör inte den inställningen, och det förklarar mönstret där andra appar fungerar från samma maskin. Arbeta utåt från appen som misslyckas, och låt tunneln vara i fred tills proxyfrågan är avgjord.

Vilket lager äger proxyinställningen

Fyra ställen kan göra anspråk på auktoriteten över en apps förfrågningar, och det smalaste vinner vanligtvis. Operativsystemet har en global proxy och en valfri automatisk konfigurations-URL; en webbläsare kan följa den, åsidosätta den eller lämna kontrollen till ett tillägg; ett kommandoradsverktyg läser sin egen miljö; och en hanterad policy kan fästa allt ovanstående igen efter en ändring. Bestäm vilket lager som ansvarar innan du redigerar något, eftersom att rensa fel lager ser ut som en lyckad rättning som återkommer vid nästa inloggning.

Jämför två applikationer mot samma vanliga webbplats i stället för mot en testsida som bara är för VPN. Om webbläsaren misslyckas medan en nedladdning i terminalen lyckas, är operativsystemet inte problemet, och skillnaden ligger i webbläsarprofilen eller dess tillägg. Om båda misslyckas men ett andra användarkonto på samma maskin lyckas, är inställningen per användare. Den jämförelsen kostar en minut och tar bort det mesta av gissandet.

Läs det värde som varje verktyg verkligen använder

Skriv ut konfigurationen innan du ändrar den, och kopiera den exakta proxysträngen till en plats där du kan återställa den. Shellvariablerna är den snabbaste kontrollen för kommandoradsverktyg, eftersom en VPN-klient vanligtvis lämnar dem orörda.

env | grep -i -E 'http_proxy|https_proxy|all_proxy|no_proxy'
scutil --proxy
gsettings get org.gnome.system.proxy mode
netsh winhttp show proxy

Kör bara den rad som passar plattformen framför dig, och läs sedan utdata för värd, port och inloggningsuppgifter. Ett värde som http://proxy.corp.example:8080 betyder att verktyget frågar den värden vid varje förfrågan, medan ett tomt resultat betyder att det går direkt och att det egentliga felet ligger någon annanstans. Dölj användar- och lösenordsdelen innan du klistrar in utdata i ett ärende, eftersom dessa strängar är levande inloggningsuppgifter mycket oftare än folk antar.

Verktyg med egen proxymotor behöver sina egna bevis. Curl anger det beslut det fattade när du ökar utförligheten, vilket är bättre än att gissa utifrån miljön, och samma flagga visar om namnmatchningen skedde lokalt eller vid proxyn.

Rensa åsidosättningen och testa samma förfrågan igen

Ändra ett lager och upprepa sedan exakt den förfrågan som misslyckades, eftersom en annan URL inte bevisar något. Rensa först miljövariablerna i det aktuella skalet, eftersom den ändringen är reversibel och inte kan bryta tunneln:

unset http_proxy https_proxy all_proxy
curl -v --max-time 10 https://example.com 2>&1 | grep -i -E 'uses proxy|connected to|http/'

Om de utförliga utdata fortfarande hävdar att det finns en proxy var miljön inte auktoriteten. Flytta ett nivå upp i stället för att stapla fler åsidosättningar.

På macOS ska du kontrollera att en automatisk konfigurationsfil inte levererar värdet, och sedan stänga av tjänsteproxyn och bekräfta ändringen. På Windows ska du komma ihåg att WinHTTP-inställningen och webbläsarinställningen per användare är olika objekt, så ett rent kommandoradsverktyg kan samexistera med en webbläsare som fortfarande pekar på en gammal server. Tillägg förtjänar samma misstanke: ett proxytillägg kan skriva om förfrågningar för bara en profil, och det är exakt formen på ett fel som drabbar en webbläsare och ingenting annat.

Bekräfta att rättningen överlever en omstart

En inställning som bara fungerar i terminalen du redigerade är inte rättad. Öppna applikationen igen från skrivbordets startprogram, logga ut och in igen, och se om den gamla proxyn kommer tillbaka.

Två kontroller skiljer en riktig rättning från en tillfällig, och båda bör rapportera en direkt anslutning eller det avsedda värdet. Körningen i en ren miljö visar om en strippad process fortfarande plockar upp en systeminställning.

env -i /usr/bin/curl -sS -o /dev/null -w '%{http_code} %{remote_ip}
' https://example.com
networksetup -getwebproxy "Wi-Fi"

Om det gamla värdet kommer tillbaka efter en omstart är källan en hanterad policy eller en profil som tillämpar det igen, och ägaren till den policyn måste ta bort undantaget. Låt certifikatvalideringen vara på hela tiden, eftersom en proxy som fångar upp trafik annars ser löst ut så snart du stänger av kontrollerna. Avsluta med att skriva den borttagna värden och datumet i dina anteckningar, så att nästa person kan skilja en avsiktlig proxy från en glömd.