VPN работи, но една апликација нема интернет? Проверете го нејзиниот прокси

Вашиот тунел е кренат, страницата за состојба покажува здраво ракување, но една апликација сѐ уште не вчитува ништо. Таа апликација веројатно сѐ уште ги праќа барањата до постар посредник: системски прокси, екстензија, конфигурациска датотека што ја турка управувањето со уреди, или променлива за прокси што ја чита само нејзиниот сопствен процес. Менувањето на VPN серверот нема да ја допре таа поставка, и тоа го објаснува образецот каде други апликации работат од истиот компјутер. Работете од апликацијата што не успева кон надвор и оставете го тунелот на мира додека прашањето за прокси не се реши.

Кој слој ја поседува поставката за прокси

Четири места можат да полагаат право на власт над барањата на апликацијата, и обично победува најтесното. Оперативниот систем држи глобален прокси и опционална URL за автоматска конфигурација; прелистувачот може да го следи, да го надмине или да ја предаде контролата на екстензија; алатката за командна линија ја чита сопствената околина; а управуваната политика може повторно да го закачи било што од наведеното по промена. Одлучете кој слој е одговорен пред да уредите нешто, бидејќи бришењето на погрешниот слој изгледа како успешно поправање што се враќа при следното најавување.

Споредете две апликации на истата обична веб-страница, а не на тест-страница само за VPN. Ако прелистувачот не успее додека преземањето во терминал успее, оперативниот систем не е проблемот, и разликата е во профилот на прелистувачот или неговите екстензии. Ако двете не успеат, но втора корисничка сметка на истиот компјутер успее, поставката е по корисник. Тоа споредување чини една минута и отстранува повеќето претпоставки.

Прочитајте ја вредноста што секоја алатка навистина ја користи

Испечатете ја конфигурацијата пред да ја смените и копирајте ја точната низа за прокси на место од каде што можете да ја вратите. Променливите на shell се најбрзата проверка за алатките за командна линија, бидејќи VPN клиентот обично ги остава недопрени.

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

Извршете само линијата што одговара на платформата пред вас, потоа прочитајте го излезот за хост, порта и акредитиви. Вредност како http://proxy.corp.example:8080 значи дека алатката го прашува тој хост за секое барање, додека празен резултат значи дека оди директно и вистинската грешка е на друго место. Заматете го делот со корисник и лозинка пред да го залепите излезот во тикет, бидејќи тие низи се многу почесто живи акредитиви отколку што луѓето претпоставуваат.

Алатките со сопствен прокси-мотор бараат сопствени докази. Curl го соопштува решението што го донел кога ја зголемувате деталноста, што е подобро од погодување од околината, и истото знаменце покажува дали разрешувањето на имиња се случило локално или на проксито.

Исчистете го надминувањето и повторно тестирајте го истото барање

Сменете еден слој, потоа повторете го точно тоа барање што не успеа, бидејќи друг URL не докажува ништо. Прво исчистете ги променливите на околината во тековниот shell, бидејќи таа измена е повратна и не може да го скрши тунелот:

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

Ако деталниот излез сѐ уште тврди дека има прокси, околината не беше власта. Качете се едно ниво погоре наместо да натрупувате повеќе надминувања.

На macOS проверете дали автоматската конфигурациска датотека не ја дава вредноста, потоа исклучете го проксито на услугата и потврдете ја промената. На Windows запомнете дека поставката WinHTTP и поставката на прелистувачот по корисник се различни објекти, па чиста алатка за командна линија може да постои покрај прелистувач што сѐ уште покажува на стар сервер. Екстензиите заслужуваат исто сомневање: прокси-екстензија може да ги препишува барањата само за еден профил, и тоа е точно формата на дефект што погодува еден прелистувач и ништо друго.

Проверете дали поправката преживува рестартирање

Поставка што работи само во терминалот што сте го уредиле не е поправена. Отворете ја апликацијата повторно од стартувачот на работната површина, одјавете се и најавете се повторно, и гледајте дали стариот прокси се враќа.

Две проверки го делат вистинското поправање од привременото, и двете треба да пријават директна врска или предвидената вредност. Извршувањето во чиста околина покажува дали исчистен процес сѐ уште презема системска поставка.

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

Ако старата вредност се врати по рестартирање, изворот е управувана политика или профил што ја применува повторно, и сопственикот на таа политика мора да го отстрани исклучокот. Оставете ја проверката на сертификати вклучена цело време, бидејќи прокси што го пресретнува сообраќајот инаку ќе изгледа решено штом ги исклучите проверките. Завршете со тоа што отстранетата вредност и датумот ќе ги запишете во вашите белешки, за да може следниот човек да разликува намерно прокси од заборавено.