Рабочее соединение и корректно настроенное соединение — разные вещи. Туннель может подниматься, страницы открываться, а DNS, IPv6 и WebRTC жить своей жизнью.
Сначала цель проверки
- Маршрут: какой внешний адрес видит endpoint и не расходится ли он с ожидаемым выходом.
- DNS: какой resolver реально спросил имя.
- WebRTC: какие ICE-кандидаты отдаёт этот браузер.
- Устойчивость: держится ли сессия десять минут, а не три секунды speedtest.
- Отказ: что происходит, когда клиент падает.
Порядок, который не врёт чаще других
- Зафиксировать клиент, ОС, сеть.
- Снять baseline без туннеля.
- Включить конфигурацию и повторить те же измерения.
- Проверить DNS leak контролируемым именем, не только DoH-галочкой.
- Открыть WebRTC в том же браузере.
- Короткий простой и повтор — ловит «отвалился и потёк напрямую».
ИнструментыНабор браузерных проверок для внешнего адреса, IPv6, DNS, WebRTC и среды выполнения собран в Network Lab. Это снимок текущего браузера и текущей сети, не сертификат «всё хорошо навсегда».
Как читать результаты
Зелёный IP при живом системном DNS — плохая конфигурация, а не успех. «Быстрый» тест при пробитом WebRTC — то же самое. Расхождение IPv4/IPv6 — отдельный баг, его часто пропускают.
Если конкретный клиент после обновления начинает врать HWID или игнорировать системный прокси, это уже не сетевая магия, а совместимость приложения. Тогда меняют клиент, а не «ещё один протокол в том же окне».