Домашним подключениям сегодня почти всегда выдают IPv6, тогда как у многих узлов есть только выход по IPv4. Когда стороны расходятся, сбои выглядят совершенно случайными: большинство сайтов открывается, отдельные — нет; или прокси очевидно работает, а проверка IP всё равно показывает ваш настоящий адрес.
Симптом 1: не открывается только часть сайтов
Машина получила запись AAAA, но у узла нет выхода по IPv6, и соединение просто отваливается по таймауту. Поставьте domainStrategy в значение UseIPv4 у исходящего freedom, чтобы использовались только результаты IPv4 — обычно это чинится сразу.
Симптом 2: проверка IP показывает реальный адрес
Классическая утечка двойного стека: IPv4 идёт через прокси, а IPv6 уходит напрямую. Откройте что-нибудь вроде test-ipv6.com и посмотрите на строку IPv6 — если там ваш локальный адрес, этот стек вообще не перехватывается. Проверьте, не пропущены ли диапазоны IPv6 в правилах маршрутизации; про разрешение имён см. защиту от утечек DNS.
Симптом 3: ломается только в режиме TUN
TUN перехватывает трафик на уровне адаптера, и если у виртуального адаптера прописаны только маршруты IPv4, трафик IPv6 обходит туннель и уходит через локальный интерфейс. В настройках TUN у v2rayN есть параметры IPv6: либо перехватывайте оба стека, либо отключайте IPv6 в системе. Наполовину оставлять нельзя.
Симптом 4: не подключиться к серверу только с IPv6
Обратная ситуация: узел работает исключительно по IPv6, а у вас IPv6 нет или провайдер выдаёт его в урезанном виде. Со стороны клиента это не обходится — нужен другой узел или слушатель IPv4 на сервере.
Грубый, но действенный приём
На время диагностики снимите галочку IPv6 в свойствах сетевого адаптера, чтобы свести задачу к одной переменной. Убедившись, что дело действительно в IPv6, вернитесь и настройте всё как следует: если оставить его выключенным навсегда, перестанут работать локальные сервисы и доступ во внутреннюю сеть, которые на него опираются.