Az alagútja fel van állva, az állapotoldal egészséges kézfogást mutat, de egy alkalmazás mégsem tölt be semmit. Az az alkalmazás valószínűleg még mindig egy régebbi közvetítőnek küldi a kéréseit: rendszerproxynak, bővítménynek, az eszközkezelés által kikényszerített konfigurációs fájlnak vagy olyan proxyváltozónak, amelyet csak a saját folyamata olvas. A VPN-szerver cseréje nem nyúl ehhez a beállításhoz, és ez magyarázza azt a mintát, amelyben más alkalmazások ugyanarról a gépről működnek. A hibás alkalmazástól kifelé haladjon, és hagyja békén az alagutat, amíg a proxy kérdése eldől.

Melyik réteg birtokolja a proxybeállítást

Négy hely tarthat igényt az alkalmazás kérései feletti hatalomra, és általában a legszűkebb nyer. Az operációs rendszer globális proxyt és opcionális automatikus konfigurációs URL-t tart; a böngésző követheti, felülírhatja, vagy átadhatja az irányítást egy bővítménynek; a parancssori eszköz a saját környezetét olvassa; és egy felügyelt szabályzat a változtatás után újra rögzítheti bármelyiket a fentiek közül. Döntse el, melyik réteg a felelős, mielőtt bármit szerkesztene, mert a rossz réteg törlése sikeres javításnak tűnik, amely a következő bejelentkezéskor visszatér.

Hasonlítson össze két alkalmazást ugyanazon a hétköznapi webhelyen, ne egy csak VPN-hez készült tesztoldalon. Ha a böngésző elbukik, miközben egy terminálos letöltés sikerül, akkor nem az operációs rendszer a probléma, és a különbség a böngészőprofilban vagy annak bővítményeiben van. Ha mindkettő elbukik, de egy második felhasználói fiók ugyanazon a gépen sikerül, akkor a beállítás felhasználónkénti. Ez az összehasonlítás egy percbe kerül, és a legtöbb találgatást kiveszi.

Olvassa ki azt az értéket, amelyet az egyes eszközök valóban használnak

Nyomtassa ki a konfigurációt, mielőtt módosítja, és másolja a pontos proxysztringet olyan helyre, ahonnan vissza tudja állítani. A shellváltozók a leggyorsabb ellenőrzés a parancssori eszközöknél, mert a VPN-kliens általában érintetlenül hagyja őket.

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

Csak azt a sort futtassa, amelyik illik az Ön előtti platformhoz, majd olvassa ki a kimenetből a gazdagépet, a portot és a hitelesítő adatokat. Egy ilyen érték, mint http://proxy.corp.example:8080 azt jelenti, hogy az eszköz minden kérésnél ezt a gazdagépet kérdezi, míg az üres eredmény azt jelenti, hogy közvetlenül megy, és az igazi hiba máshol van. Takarja el a felhasználó és a jelszó részét, mielőtt a kimenetet jegybe illeszti, mert ezek a karakterláncok sokkal gyakrabban élő hitelesítő adatok, mint azt az emberek feltételezik.

A saját proxymotorral rendelkező eszközöknek saját bizonyíték kell. A Curl kiírja a döntést, amelyet hozott, amikor növeli a részletességet, ami jobb, mint a környezetből találgatni, és ugyanaz a kapcsoló mutatja, hogy a névfeloldás helyben vagy a proxynál történt.

Törölje a felülírást, és tesztelje újra ugyanazt a kérést

Változtasson egy rétegen, majd ismételje meg pontosan azt a kérést, amelyik elbukott, mert egy másik URL semmit sem bizonyít. Először törölje a környezeti változókat az aktuális shellben, mert ez a módosítás visszafordítható, és nem törheti el az alagutat:

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

Ha a részletes kimenet továbbra is proxyt állít, akkor a környezet nem volt a hatalom. Lépjen egy szinttel feljebb, ahelyett hogy további felülírásokat halmozna.

macOS-en ellenőrizze, hogy egy automatikus konfigurációs fájl nem szolgáltatja-e az értéket, majd kapcsolja ki a szolgáltatás proxyját, és erősítse meg a változtatást. Windowson ne feledje, hogy a WinHTTP-beállítás és a felhasználónkénti böngészőbeállítás külön objektumok, ezért egy tiszta parancssori eszköz együtt létezhet olyan böngészővel, amely még mindig egy régi szerverre mutat. A bővítmények ugyanilyen gyanút érdemelnek: egy proxybővítmény csak egy profil számára írhatja át a kéréseket, és pontosan ez a formája annak a hibának, amely egy böngészőt érint, és semmi mást.

Ellenőrizze, hogy a javítás túléli-e az újraindítást

Az a beállítás, amely csak abban a terminálban működik, amelyet szerkesztett, nincs megjavítva. Nyissa meg újra az alkalmazást az asztali indítóból, jelentkezzen ki és vissza, és figyelje, visszatér-e a régi proxy.

Két ellenőrzés választja el a valódi javítást az ideiglenestől, és mindkettőnek közvetlen kapcsolatot vagy a kívánt értéket kell jelentenie. A tiszta környezetben való futtatás megmutatja, hogy egy megtisztított folyamat még mindig átvesz-e egy rendszerbeállítást.

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

Ha a régi érték újraindítás után visszatér, a forrás egy felügyelt szabályzat vagy profil, amely újra alkalmazza, és a szabályzat tulajdonosának el kell távolítania a kivételt. Hagyja a tanúsítványok ellenőrzését végig bekapcsolva, mert egy forgalmat elfogó proxy különben megoldottnak látszik, amint kikapcsolja az ellenőrzéseket. Végül írja fel az eltávolított értéket és a dátumot a jegyzeteibe, hogy a következő ember meg tudja különböztetni a szándékos proxyt az elfelejtettől.

Kapcsolódó cikkek