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"

Если старое значение возвращается после перезапуска, источник — управляемая политика или профиль, который применяет его снова, и владелец этой политики должен убрать исключение. Оставляйте проверку сертификатов включённой всё время, потому что прокси, перехватывающий трафик, иначе будет выглядеть решённым, как только вы отключите проверки. В конце запишите удалённое значение и дату в заметки, чтобы следующий человек мог отличить намеренный прокси от забытого.