VPN virker, men én app har ikke internett? Sjekk proxyen dens

Tunnelen din er oppe, statussiden viser et sunt handshake, men én applikasjon laster fortsatt ingenting. Den applikasjonen sender sannsynligvis fortsatt forespørslene sine til en eldre mellomledd: en systemproxy, en utvidelse, en konfigurasjonsfil som skyves ut av enhetsadministrasjon, eller en proxyvariabel som bare dens egen prosess leser. Å bytte VPN-server rører ikke den innstillingen, og det forklarer mønsteret der andre apper virker fra 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 proxyinnstillingen

Fire steder kan gjøre krav på autoriteten over en apps forespørsler, og det smaleste vinner vanligvis. 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 ovenstående på nytt etter en endring. Bestem hvilket lag som har ansvaret før du redigerer noe, fordi å rydde det feil laget 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 dens. Hvis begge feiler, men en annen brukerkonto på samme maskin lykkes, er innstillingen per bruker. Den 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 legitimasjon. 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 legitimasjon 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 den gjeldende shellet, 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 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 side om side 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 tilkobling 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.