VPN-ul funcționează, dar o aplicație nu are internet? Verifică proxy-ul ei

Tunelul tău este ridicat, pagina de stare arată un handshake sănătos, dar o aplicație tot nu încarcă nimic. Acea aplicație probabil încă trimite cererile către un intermediar mai vechi: un proxy de sistem, o extensie, un fișier de configurare împins de administrarea dispozitivelor sau o variabilă de proxy pe care o citește doar propriul proces. Schimbarea serverului VPN nu va atinge această setare, și asta explică tiparul în care alte aplicații funcționează de pe același calculator. Lucrează dinspre aplicația care eșuează spre exterior și lasă tunelul în pace până când problema proxy-ului este rezolvată.

Ce strat deține setarea de proxy

Patru locuri pot revendica autoritate asupra cererilor unei aplicații, iar cel mai îngust câștigă de obicei. Sistemul de operare ține un proxy global și un URL de configurare automată opțional; un browser poate să-l urmeze, să-l suprascrie sau să dea controlul unei extensii; un instrument de linie de comandă își citește propriul mediu; iar o politică administrată poate fixa din nou oricare dintre cele de mai sus după o modificare. Decide ce strat este responsabil înainte de a edita ceva, pentru că ștergerea stratului greșit arată ca o corectare reușită care revine la următoarea autentificare.

Compară două aplicații pe același site obișnuit, nu pe o pagină de test doar pentru VPN. Dacă browserul eșuează în timp ce o descărcare în terminal reușește, sistemul de operare nu este problema, iar diferența stă în profilul browserului sau în extensiile lui. Dacă ambele eșuează, dar un al doilea cont de utilizator de pe același calculator reușește, setarea este per utilizator. Acea comparație costă un minut și elimină cea mai mare parte a presupunerilor.

Citește valoarea pe care fiecare instrument o folosește de fapt

Tipărește configurația înainte de a o schimba și copiază șirul exact de proxy undeva de unde îl poți restabili. Variabilele shell sunt verificarea cea mai rapidă pentru instrumentele de linie de comandă, pentru că un client VPN le lasă de obicei neatinse.

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

Rulează doar linia care corespunde platformei din fața ta, apoi citește ieșirea pentru gazdă, port și acreditări. O valoare ca http://proxy.corp.example:8080 înseamnă că instrumentul întreabă acea gazdă pentru fiecare cerere, în timp ce un rezultat gol înseamnă că merge direct și defecțiunea reală este în altă parte. Maschează partea de utilizator și parolă înainte de a lipi ieșirea într-un tichet, pentru că acele șiruri sunt acreditări active mult mai des decât presupun oamenii.

Instrumentele cu propriul motor de proxy au nevoie de propriile dovezi. Curl indică decizia pe care a luat-o când crești verbositatea, ceea ce e mai bun decât să ghicești din mediu, iar același indicator arată dacă rezolvarea numelor a avut loc local sau la proxy.

Șterge suprascrierea și retestează aceeași cerere

Schimbă un strat, apoi repetă exact cererea care a eșuat, pentru că un alt URL nu dovedește nimic. Șterge mai întâi variabilele de mediu din shell-ul curent, fiindcă acea modificare este reversibilă și nu poate rupe tunelul:

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

Dacă ieșirea detaliată încă susține că există un proxy, mediul nu era autoritatea. Urcă un nivel în loc să stivuiască mai multe suprascrieri.

Pe macOS, verifică dacă un fișier de configurare automată nu furnizează valoarea, apoi oprește proxy-ul serviciului și confirmă modificarea. Pe Windows, ține minte că setarea WinHTTP și setarea browserului per utilizator sunt obiecte diferite, așa că un instrument de linie de comandă curat poate coexista cu un browser care încă indică un server vechi. Extensiile merită aceeași suspiciune: o extensie de proxy poate rescrie cererile doar pentru un profil, și exact aceasta este forma unei defecțiuni care afectează un browser și nimic altceva.

Verifică dacă remedierea supraviețuiește unei reporniri

O setare care funcționează doar în terminalul pe care l-ai editat nu este remediată. Deschide din nou aplicația din lansatorul desktopului, deconectează-te și reconectează-te, și urmărește dacă proxy-ul vechi revine.

Două verificări separă o remediere reală de una temporară, și ambele ar trebui să raporteze o conexiune directă sau valoarea dorită. Rularea într-un mediu curat arată dacă un proces curățat mai preia o setare de sistem.

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

Dacă valoarea veche revine după o repornire, sursa este o politică administrată sau un profil care o aplică din nou, iar proprietarul acelei politici trebuie să elimine excepția. Lasă verificarea certificatelor activă tot timpul, pentru că un proxy care interceptează traficul va părea rezolvat imediat ce dezactivezi verificările. Încheie scriind valoarea eliminată și data în notițele tale, ca următoarea persoană să poată distinge un proxy intenționat de unul uitat.