VPN virker, men en app har ikke nettilgang? Sjekk proxyen til appen

Tunnelen din er oppe, statussiden viser en sunn handshake, men en applikasjon laster fortsatt ingenting. Applikasjonen sender trolig fortsatt forespørslene sine til en eldre mellommann: en systemproxy, en utvidelse, en konfigurasjonsfil som skyves ut av enhetsstyring, eller en proxyvariabel som bare dens egen prosess leser. Å bytte VPN-server berører ikke denne innstillingen, og det forklarer mønsteret der andre apper virker på samme maskin. Arbeid utover fra appen som feiler, og la tunnelen være i fred til proxy-spørsmålet er avklart.

Hvilket lag eier proxy-innstillingen

Fire steder kan hevde autoritet over en apps forespørsler, og det smaleste vinner som regel. Operativsystemet har en global proxy og en valgfri automatisk konfigurasjons-URL; en nettleser kan følge den, overstyre den eller overlate kontrollen til en utvidelse; et kommandolinjeverktøy leser sitt eget miljø; og en administrert policy kan feste alt det ovennevnte på nytt etter en endring. Bestem hvilket lag som har ansvaret før du redigerer noe, fordi å fjerne feil lag ser ut som en vellykket rettelse som kommer tilbake ved neste innlogging.

Sammenlign to applikasjoner mot det samme vanlige nettstedet i stedet for mot en testside som bare er for VPN. Hvis nettleseren feiler mens en nedlasting i terminalen lykkes, er ikke operativsystemet problemet, og forskjellen ligger i nettleserprofilen eller utvidelsene. Hvis begge feiler, men en annen brukerkonto på samme maskin lykkes, er innstillingen per bruker. Denne sammenligningen koster ett minutt og fjerner det meste av gjettingen.

Les verdien hvert verktøy faktisk bruker

Skriv ut konfigurasjonen før du endrer den, og kopier den nøyaktige proxystrengen til et sted der du kan gjenopprette den. Shellvariablene er den raskeste kontrollen for kommandolinjeverktøy, fordi en VPN-klient vanligvis lar dem være urørt.

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

Kjør bare linjen som passer til plattformen foran deg, og les deretter utdataene for vert, port og påloggingsinformasjon. En verdi som http://proxy.corp.example:8080 betyr at verktøyet spør den verten for hver forespørsel, mens et tomt resultat betyr at det går direkte og at den egentlige feilen ligger et annet sted. Skjul bruker- og passorddelen før du limer utdataene inn i en sak, fordi disse strengene er levende påloggingsinformasjon langt oftere enn folk antar.

Verktøy med sin egen proxymotor trenger sine egne bevis. Curl oppgir beslutningen det tok når du øker detaljnivået, noe som er bedre enn å gjette ut fra miljøet, og det samme flagget viser om navneoppslaget skjedde lokalt eller ved proxyen.

Fjern overstyringen og test den samme forespørselen på nytt

Endre ett lag, og gjenta deretter nøyaktig den forespørselen som feilet, fordi en annen URL ikke beviser noe. Fjern først miljøvariablene i gjeldende shell, siden den endringen er reversibel og ikke kan ødelegge tunnelen:

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/'

Hvis de detaljerte utdataene fortsatt hevder at det er en proxy, var ikke miljøet autoriteten. Flytt ett nivå opp i stedet for å stable flere overstyringer.

På macOS må du kontrollere at en automatisk konfigurasjonsfil ikke leverer verdien, og deretter slå av tjenesteproxyen og bekrefte endringen. På Windows må du huske at WinHTTP-innstillingen og nettleserinnstillingen per bruker er forskjellige objekter, så et rent kommandolinjeverktøy kan eksistere sammen med en nettleser som fortsatt peker på en gammel server. Utvidelser fortjener samme mistanke: en proxyutvidelse kan skrive om forespørsler for bare én profil, og det er nøyaktig formen på en feil som rammer én nettleser og ingenting annet.

Bekreft at rettelsen overlever en omstart

En innstilling som bare virker i terminalen du redigerte, er ikke rettet. Åpne applikasjonen på nytt fra skrivebordets startprogram, logg ut og inn igjen, og se om den gamle proxyen kommer tilbake.

To kontroller skiller en ekte rettelse fra en midlertidig, og begge bør rapportere en direkte forbindelse eller den tiltenkte verdien. Kjøringen i et rent miljø viser om en strippet prosess fortsatt plukker opp en systeminnstilling.

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

Hvis den gamle verdien kommer tilbake etter en omstart, er kilden en administrert policy eller en profil som bruker den på nytt, og eieren av den policyen må fjerne unntaket. La sertifikatvalideringen være slått på hele tiden, fordi en proxy som fanger opp trafikk ellers vil se løst ut når du slår av kontrollene. Avslutt med å skrive den fjernede verdien og datoen i notatene dine, slik at neste person kan skille en bevisst proxy fra en glemt.