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"

Якщо старе значення повертається після перезапуску, джерелом є керована політика або профіль, що застосовує його знову, і власник цієї політики має прибрати виняток. Залишайте перевірку сертифікатів увімкненою весь час, бо проксі, що перехоплює трафік, інакше виглядатиме вирішеним, щойно ви вимкнете перевірки. Наприкінці запишіть видалене значення й дату у свої нотатки, щоб наступна людина могла відрізнити навмисний проксі від забутого.