VPN показывает статус «Подключено», сайт видит другой IP — значит, всё работает правильно? Не обязательно. Это подтверждает только то, что конкретное соединение вышло в интернет через другой адрес. Чтобы понять, действительно ли трафик идёт так, как вы ожидаете, нужно проверить несколько вещей отдельно.
Для обычного полного туннеля важны пять вопросов: скрыт ли исходный публичный IP, не уходит ли IPv6 напрямую, как работает DNS, что показывает WebRTC и что происходит в момент разрыва VPN. Если используется split tunneling, к этому добавляется проверка исключённых приложений.
Начните с состояния без VPN
Перед тестами отключите VPN и зафиксируйте исходные параметры соединения. Посмотрите внешний IPv4, наличие публичного IPv6, DNS-резолверы и название сети или провайдера.
Эти данные нужны как точка сравнения. Без них легко принять обычный адрес локальной сети или публичный DNS за утечку.
Геолокацию IP лучше использовать только как дополнительный ориентир. Базы геолокации обновляются не синхронно и могут ошибаться. Для проверки важнее сам адрес и его принадлежность, а не точка на карте.
Проверка внешнего IP
Подключите VPN и снова откройте сервис определения IP.
При полном туннеле внешний IPv4 должен отличаться от адреса, который был виден до подключения. Обычно сайт увидит IP VPN-сервера или другого выходного узла инфраструктуры сервиса.
Если отображается тот же публичный IPv4 вашего провайдера, что и без VPN, это уже серьёзный сигнал: проверяемое соединение не проходит через ожидаемый туннель.
Но одной такой проверки всё равно мало. Современное устройство может одновременно использовать IPv4 и IPv6.
Не забудьте про IPv6
Распространённая ошибка — проверить только IPv4 и сделать вывод, что защита работает полностью.
Возможен другой сценарий: IPv4 направляется через VPN, а IPv6 остаётся на обычном интерфейсе. Тогда сайт или приложение, умеющее работать по IPv6, может установить соединение в обход ожидаемого маршрута.
После включения VPN проверьте, виден ли публичный IPv6. Если сервис не поддерживает выход по IPv6, допустим вариант, при котором IPv6 на время работы VPN блокируется. Опасен не сам факт отсутствия IPv6, а неожиданное появление вашего исходного публичного адреса.
Отключать IPv6 навсегда ради «исправления» не стоит. Если проблема возникает только с ним, лучше проверить настройки клиента и поддержку IPv6 у конкретного сервиса.
Проверьте DNS отдельно
Следующий вопрос — куда уходят DNS-запросы.
DNS помогает приложениям получать IP-адреса по доменным именам. При полном туннеле его поведение должно соответствовать конфигурации VPN и операционной системы.
Если после подключения тест по-прежнему показывает DNS вашего интернет-провайдера, хотя VPN должен использовать другой резолвер или направлять DNS внутри туннеля, это повод разобраться с маршрутизацией.
Но вывод «любой сторонний DNS = утечка» неверен. Браузер может использовать DNS over HTTPS, система — Private DNS, а VPN — публичный резолвер вроде Cloudflare. Важен не только его адрес, но и путь соединения до него.
Поэтому полезно сравнить результат в двух браузерах и посмотреть, включён ли отдельный DoH/Secure DNS.
Что на самом деле показывает WebRTC-тест
WebRTC часто фигурирует в инструкциях по поиску VPN-утечек, но его результаты нередко трактуют неправильно.
Для установления прямых соединений WebRTC использует ICE. Этот механизм может собирать несколько типов сетевых кандидатов: адрес локального интерфейса, адрес, полученный через STUN, либо адрес TURN-сервера.
Поэтому появление в тесте 192.168.x.x, 10.x.x.x или другого частного адреса ещё не означает, что сайт узнал ваш публичный IP.
Сравнивать нужно с исходным адресом, записанным до включения VPN. Если WebRTC раскрывает именно публичный адрес обычного провайдера, который должен быть скрыт туннелем, это уже значимый результат.
Полностью отключать WebRTC «на всякий случай» не обязательно: это может нарушить работу видеозвонков, конференций и других браузерных функций.
Самая полезная проверка — разрыв туннеля
Статичный тест показывает состояние только в момент, когда VPN уже подключён. На практике критический момент часто возникает иначе: соединение с сервером потерялось, а обычный интернет ещё работает.
Здесь проверяется Kill Switch.
Если эта функция включена, нежелательный трафик не должен автоматически перейти на обычный сетевой интерфейс до восстановления VPN.
Ручное нажатие кнопки «Отключить» не всегда подходит для проверки. Некоторые клиенты считают это осознанным действием пользователя и специально возвращают обычный доступ в интернет.
Полезнее смоделировать обычный сбой: переключиться с Wi-Fi на мобильную сеть, кратко потерять подключение к точке доступа или дождаться переподключения VPN. В этот момент следите, не появляется ли обычный интернет раньше туннеля.
После восстановления ещё раз проверьте IP и DNS.
На Android системный режим Always-on VPN может работать вместе с функцией блокировки соединений без VPN. В таком режиме система не должна выпускать обычный сетевой трафик, если туннель недоступен. Реализация стороннего Kill Switch зависит от конкретного приложения и платформы, поэтому её лучше проверять, а не считать гарантированной по названию настройки.
Проверьте смену Wi-Fi и мобильной сети
Это особенно важно для смартфона.
При переходе с домашнего Wi-Fi на LTE или 5G меняются сетевой интерфейс, адреса, маршруты и DNS. Клиент должен перестроить VPN-соединение под новую сеть.
Простой тест выглядит так: подключите VPN по Wi-Fi, проверьте IP и DNS, затем отключите Wi-Fi и дождитесь мобильного соединения. После восстановления VPN повторите проверку.
Если до переподключения на короткое время становится виден исходный IP или DNS провайдера, защита при смене сети работает не так, как ожидалось.
Split tunneling меняет смысл теста
При раздельной маршрутизации часть приложений специально работает без VPN. В таком случае разные программы на одном устройстве могут показывать разные внешние адреса, и это не обязательно ошибка.
Перед проверкой посмотрите список исключений. Если браузер добавлен в split tunneling как приложение, которому разрешён обычный интернет, бессмысленно ожидать от него IP VPN-сервера.
Для проверки полного туннеля временно уберите тестируемое приложение из исключений или отключите split tunneling.
Почему одного сайта проверки недостаточно
Онлайн-тест видит только соединения, которые создаёт конкретная страница в конкретном браузере. Он не проверяет весь трафик устройства.
Фоновое обновление приложения, системная синхронизация или программа из списка исключений могут использовать другой маршрут. Браузерный DoH также способен дать DNS-результат, отличающийся от системного.
Поэтому лучше собрать несколько наблюдений: внешний IPv4, IPv6, DNS, WebRTC и поведение во время разрыва соединения.
Что считать нормальным результатом
Для полного туннеля картина должна быть последовательной. Исходный публичный IPv4 не появляется, публичный IPv6 либо проходит через ожидаемый VPN-маршрут, либо корректно блокируется, DNS работает согласно выбранной конфигурации, а WebRTC не раскрывает исходный публичный адрес.
При потере VPN нежелательный трафик не должен незаметно переключаться на обычный интернет, если включён Kill Switch. После смены сети соединение должно восстановиться без неожиданного обходного маршрута.
Если один из пунктов не совпадает с ожидаемым поведением, сначала найдите источник: настройки браузера, IPv6, DNS, split tunneling, операционная система или сам VPN-клиент. Один необычный результат ещё не доказывает, что весь сервис небезопасен.
Что такие тесты доказать не могут
Даже идеально пройденная проверка не отвечает на вопрос, что происходит после того, как трафик дошёл до VPN-сервера.
По внешним тестам нельзя подтвердить отсутствие логов, проверить срок хранения технических журналов, оценить внутреннюю защиту серверов или убедиться, что приложение не собирает лишнюю телеметрию.
Это уже другая часть оценки VPN: политика конфиденциальности, техническая документация, история обновлений, открытость разработчика и независимые аудиты — если они проводились и доступны для проверки.
VPN также не заменяет HTTPS. VPN защищает маршрут между устройством и VPN-инфраструктурой, а TLS/HTTPS защищает соединение приложения с конечным сайтом. Эти механизмы дополняют друг друга, но решают разные задачи.
Частые ошибки
«IP изменился — значит всё защищено». Нет. Это подтверждает только маршрут конкретного соединения. DNS, IPv6 или другое приложение могут вести себя иначе.
«WebRTC показал локальный IP — это утечка». Не обязательно. Частный адрес локальной сети не равен публичному адресу провайдера.
«В тесте появился Google DNS — VPN сломан». Не обязательно. Нужно понять, почему выбран этот резолвер и идёт ли соединение к нему через туннель.
«Kill Switch включён в настройках, значит его можно не тестировать». Название функции не гарантирует одинаковое поведение на всех платформах и при всех видах разрыва.
Проверять VPN лучше не одной зелёной галочкой, а последовательностью коротких тестов.
Сначала запишите исходные IPv4, IPv6 и DNS. После подключения сравните внешний IP, отдельно проверьте IPv6 и DNS, затем посмотрите WebRTC. После этого испытайте поведение при разрыве туннеля и переходе между Wi-Fi и мобильной сетью. Если включён split tunneling, учитывайте его правила для каждого приложения.
Так можно обнаружить основные ошибки маршрутизации и очевидные утечки. Но эти проверки оценивают поведение соединения на вашем устройстве, а не честность политики логирования или внутреннюю безопасность инфраструктуры VPN-провайдера.