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

Тунелът ви е вдигнат, страницата за състояние показва здраво ръкостискане, а едно приложение все още не зарежда нищо. Това приложение вероятно още изпраща заявките си към по-стар посредник: системен прокси, разширение, конфигурационен файл, изпратен от управлението на устройства, или променлива за прокси, която чете само собственият му процес. Смяната на VPN сървър няма да пипне тази настройка и това обяснява модела, при който други приложения работят от същата машина. Работете от сгрешеното приложение навън и не пипайте тунела, докато въпросът с проксито не е решен.

Кой слой притежава настройката за прокси

Четири места могат да претендират за власт над заявките на приложението и обикновено печели най-тясното. Операционната система държи глобален прокси и незадължителен URL за автоматична конфигурация; браузърът може да го следва, да го замества или да предаде контрола на разширение; инструмент от командния ред чете собствената си среда; а управлявана политика може да закрепи отново всяко от изброените след промяна. Решете кой слой отговаря, преди да редактирате нещо, защото изчистването на грешния слой изглежда като успешно поправяне, което се връща при следващото влизане.

Сравнете две приложения на един и същ обикновен сайт, а не на тестова страница само за VPN. Ако браузърът се проваля, докато изтегляне в терминала успява, операционната система не е проблемът и разликата е в профила на браузъра или в разширенията му. Ако и двете се провалят, но втори потребителски акаунт на същата машина успява, настройката е за потребителя. Това сравнение струва една минута и премахва повечето догадки.

Прочетете стойността, която всеки инструмент наистина използва

Отпечатайте конфигурацията, преди да я промените, и копирайте точния низ за прокси някъде, откъдето можете да го възстановите. Променливите на обвивката са най-бързата проверка за инструменти от командния ред, защото 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 не доказва нищо. Първо изчистете променливите на средата в текущата обвивка, тъй като тази промяна е обратима и не може да счупи тунела:

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"

Ако старата стойност се върне след рестарт, източникът е управлявана политика или профил, който я прилага отново, и собственикът на тази политика трябва да премахне изключението. Оставете проверката на сертификатите включена през цялото време, защото прокси, което прихваща трафик, иначе ще изглежда решено, щом изключите проверките. Накрая запишете премахнатата стойност и датата в бележките си, за да може следващият човек да различи умишлено прокси от забравено.