VLESS и IPv6: почему часть сайтов не открывается и как проверить проблему

Иногда VLESS выглядит полностью исправным:

HAPP показывает Connected;
Google открывается;
Telegram работает;
внешний IP изменился;

но часть сайтов:

долго загружается;
открывается через раз;
зависает на несколько секунд;
вообще не отвечает.

Одна из возможных причин — IPv6.

Но важно сразу уточнить:

IPv6 сам по себе не является проблемой VLESS.

IPv6 — нормальная современная версия Internet Protocol и полноценная часть сегодняшнего интернета.

Проблемы возникают тогда, когда устройство, DNS, VPN или провайдер считают IPv6 рабочим, а реальный IPv6-маршрут:

отсутствует;
нестабилен;
работает только частично;
неправильно проходит через VPN.

В результате один сайт открывается через IPv4 мгновенно, а другой сначала пытается использовать проблемный IPv6 и долго ждёт.

Разберём, как это работает и как диагностировать проблему без бессмысленного отключения половины сетевого стека.

Что такое IPv4 и IPv6

IPv4 — привычная версия Internet Protocol с адресами вроде:

203.0.113.10

IPv6 использует 128-битные адреса, например:

2001:db8:1234::10

IPv6 был создан как преемник IPv4 и значительно расширяет адресное пространство. RFC 8200 является основной спецификацией IPv6.

Современное устройство часто умеет работать одновременно с обоими протоколами.

Такой режим называется:

dual-stack.

Что такое dual-stack

Устройство может иметь одновременно:

IPv4
+
IPv6

Когда пользователь открывает сайт, DNS способен вернуть адреса обоих типов.

Например:

example.com
↓
A     → 203.0.113.10
AAAA  → 2001:db8::10

Дальше клиент выбирает, какой адрес использовать.

И именно здесь иногда начинается проблема.

Что такое A и AAAA

В DNS:

A record содержит IPv4-адрес.

Например:

example.com → 203.0.113.10

AAAA record содержит IPv6-адрес.

Например:

example.com → 2001:db8::10

Если домен имеет только A — используется IPv4.

Если только AAAA — нужен IPv6.

Если есть оба — приложение может выбирать между ними.

Почему один сайт работает, а другой нет

Представим:

Сайт A

имеет только IPv4.

Он сразу открывается.

Сайт B

имеет IPv4 и IPv6.

Устройство сначала пытается использовать IPv6.

Но IPv6-маршрут через текущую сеть работает плохо.

Получается:

AAAA → попытка IPv6 → timeout
↓
IPv4 → работает

Пользователь видит:

сайт открывается очень долго.

И думает:

VLESS тормозит.

Хотя сам VLESS-сервер может быть совершенно исправен.

Почему современные клиенты не должны просто ждать IPv6 timeout

Именно для этого существует механизм Happy Eyeballs.

RFC 8305 описывает ситуацию, когда hostname имеет несколько адресов, а IPv4 или IPv6 на конкретной сети могут быть:

недоступны;
сломаны;
неоптимальны.

Вместо последовательного ожидания полного timeout клиент может запускать попытки соединения с несколькими адресами с небольшой разницей во времени и использовать тот, который первым успешно подключился.

Упрощённо:

IPv6 ──────── попытка
      ↓
IPv4 ───── попытка
      ↓
кто первый успешно подключился

Пользователь при этом почти не замечает проблему одной address family.

Есть ли Happy Eyeballs в Xray

Да.

В актуальной документации Xray для sockopt присутствует отдельный объект:

happyEyeballs

Он реализует Happy Eyeballs по RFC 8305 для TCP.

Когда целью является доменное имя, Xray может проверять разрешённые адреса и использовать первый успешно подключившийся.

Но здесь есть важный нюанс.

Happy Eyeballs не работает при любом domainStrategy

Документация Xray указывает, что механизм работает, когда:

sockopt.domainStrategy

не равен:

AsIs

То есть Xray должен сам участвовать в разрешении домена и получить список IP, между которыми можно выбирать.

Для обычного пользователя готовой HAPP-подписки вручную редактировать это обычно не нужно.

Но механизм важен для понимания того, почему разные конфигурации могут по-разному вести себя на dual-stack-сетях.

Что такое domainStrategy в Xray

domainStrategy определяет, как Xray поступает, когда outbound должен подключиться к доменному имени, а не к уже готовому IP.

Например, VLESS-сервер указан так:

server.example.com

а не:

203.0.113.10

Xray должен решить:

оставить домен системному resolver;
самостоятельно получить IP;
использовать только IPv4;
только IPv6;
разрешить оба семейства.

Что делает AsIs

При AsIs Xray не выполняет собственное принудительное разрешение адреса в рамках этой стратегии.

Домен передаётся дальше сетевому стеку.

Тогда поведение сильнее зависит от:

операционной системы;
системного DNS;
реализации TCP;
выбора IPv4/IPv6 самой системой.

Это не плохо.

Во многих конфигурациях такой режим прекрасно работает.

Что делает UseIP

При UseIP Xray разрешает доменное имя через свой DNS-механизм и получает IP-адреса.

Если доступны несколько подходящих адресов, уже появляется возможность работать с ними на уровне самого Xray.

Актуальная документация отмечает, что при включённом happyEyeballs несколько адресов могут конкурировать между собой вместо случайного выбора одного.

Есть и IPv4/IPv6-specific стратегии

Xray поддерживает варианты вроде:

IPv4
IPv6
IPv4v6
IPv6v4

и соответствующие стратегии семейства Use / Force.

Но здесь есть важная тонкость.

Документация Project X отдельно предупреждает, что варианты вроде UseIPv4v6 фактически сначала ограничивают список IPv4-адресами и переходят к IPv6 только если разрешение IPv4 не вернуло адресов.

Если IPv4-адрес найден, но само соединение с ним потом не удалось, автоматического перехода на IPv6 не происходит.

Именно поэтому Xray рекомендует для настоящего dual-stack-поведения использовать UseIP или ForceIP вместе с Happy Eyeballs.

Почему это важно

Представим:

example.com
A    → IPv4 существует, но маршрут сломан
AAAA → IPv6 отлично работает

Если конфигурация жёстко говорит:

сначала IPv4, IPv6 только если A вообще не существует,

клиент может застрять на неработающем IPv4.

Happy Eyeballs решает другую задачу:

проверяет реальные попытки соединения и использует успешную.

Может быть и наоборот

Например:

A    → работает отлично
AAAA → существует, но IPv6-маршрут сломан

Слишком агрессивное предпочтение IPv6 способно добавить задержку.

Именно поэтому RFC 8305 появился как практический механизм уменьшения пользовательских задержек на dual-stack-сетях.

Почему IPv6 особенно часто всплывает на мобильном интернете

Мобильные сети активно используют IPv6.

У некоторых операторов клиентская сеть может быть:

dual-stack;
IPv6-first;
IPv6-only с механизмами совместимости для IPv4.

RFC 8305 отдельно рассматривает IPv6-only сети с NAT64/DNS64 и необходимость корректной поддержки таких сетей клиентскими приложениями.

Поэтому сценарий:

Wi-Fi → всё работает

LTE → часть сайтов зависает

может действительно быть связан с различиями IPv4/IPv6.

Но это нужно проверять, а не угадывать.

Что такое NAT64 и DNS64

В IPv6-only сети устройство может не иметь обычного IPv4-подключения.

При этом интернет всё ещё содержит огромное количество IPv4-only серверов.

Для совместимости используются механизмы вроде:

DNS64 + NAT64.

Упрощённо:

IPv6-only телефон
↓
NAT64
↓
IPv4-сайт

Пользователь при этом может вообще не замечать, что собственного обычного IPv4 у телефона нет.

Почему literal IPv4 иногда ведёт себя иначе

Если приложение использует не домен:

server.example.com

а конкретный адрес:

198.51.100.20

в IPv6-only сети для него может потребоваться специальная NAT64-совместимость.

RFC 8305 отдельно обсуждает обработку IPv4 literals на IPv6-only сетях.

Это одна из причин, почему доменное имя сервера иногда гибче жёстко прописанного IP.

Значит ли это, что VLESS-сервер лучше всегда задавать доменом

Не обязательно.

IP имеет свои преимущества:

не зависит от DNS для самого endpoint;
проще диагностируется.

Домен удобен тем, что:

можно менять IP без смены клиентской ссылки;
система может выбирать address family;
проще использовать некоторые TLS-схемы.

Зависит от архитектуры сервиса.

Как выглядит типичная IPv6-проблема в VLESS

Например:

HAPP подключился.
Часть сайтов работает.
Некоторые сайты открываются только через 10–20 секунд.
После временного отключения IPv6 они начинают открываться мгновенно.

Это не доказывает, что IPv6 «плохой».

Это доказывает:

проблема каким-то образом связана с IPv6-path.

Дальше нужно понять — где именно.

IPv6 может ломаться до VLESS-сервера

Например сам endpoint VLESS имеет:

A
AAAA

но AAAA ведёт на сервер, где:

Xray не слушает IPv6;
firewall закрывает IPv6;
routing неправильный.

Клиент выбирает IPv6 и получает ошибку.

Или после VLESS-сервера

Сам VLESS-сервер может подключаться нормально.

Но пользователь открывает сайт, у которого есть IPv6.

А серверный outbound:

не имеет рабочего IPv6;
имеет плохой IPv6-route;
DNS возвращает AAAA, который невозможно нормально использовать.

Тогда туннель существует, но конкретный destination не открывается.

Это два разных IPv6

Очень важно различать:

IPv6 до VLESS

клиент
↓ IPv6
VLESS server

IPv6 после VLESS

VLESS server
↓ IPv6
destination website

Проблема в одном направлении ничего не говорит о другом.

Клиент может подключаться к VLESS по IPv4, а сайты выходить по IPv6

Да.

Например:

Телефон
↓ IPv4
VLESS server
↓ IPv6
Website

И наоборот:

Телефон
↓ IPv6
VLESS server
↓ IPv4
Website

Это совершенно нормальные схемы.

Поэтому фраза:

«мой VPN работает по IPv4»

не всегда означает:

весь дальнейший трафик тоже IPv4.

Что проверить первым

Если подозреваете IPv6, не отключайте его сразу навсегда.

Сначала классифицируйте проблему.

Проверьте:

Работают ли другие VLESS-серверы.
Есть ли разница Wi-Fi/LTE.
Проблема у всех сайтов или нескольких.
Работает ли сайт без VLESS.
Есть ли у проблемного домена AAAA.

После этого уже можно делать тест с IPv6.

Как посмотреть A и AAAA на Windows

Можно использовать:

Resolve-DnsName example.com

или:

nslookup -type=A example.com

и:

nslookup -type=AAAA example.com

Если есть только A:

сайт IPv4-only.

Если есть AAAA:

доступен IPv6 endpoint.

На Linux и macOS

Можно использовать:

dig A example.com

и:

dig AAAA example.com

или:

host example.com

Это помогает понять, какие адреса DNS вообще предлагает клиенту.

AAAA существует — это ещё не значит, что IPv6 реально работает

DNS может прекрасно возвращать:

2001:db8::10

Но пакет до этого адреса должен ещё пройти весь маршрут.

Поэтому два разных теста:

DNS

Есть ли AAAA?

Connectivity

Можно ли реально подключиться к этому IPv6?

Не смешивайте их.

Как проверить IPv4 и IPv6 отдельно

На системах, где доступны соответствующие параметры:

curl -4 https://example.com

и:

curl -6 https://example.com

Если:

curl -4 → работает
curl -6 → timeout

получаем очень сильный диагностический признак.

IPv4-path работает.

IPv6-path — нет.

Но curl нужно запускать в правильной сетевой схеме

Если вы проверяете проблему через VLESS, убедитесь, что curl действительно идёт через тот же TUN/proxy.

Иначе можно случайно сравнить:

Browser → VLESS
curl → Direct

и получить бессмысленный результат.

На Windows с HAPP TUN обычно проще проверять при включённом системном туннеле.

В браузере проверить сложнее

Современные браузеры сами используют:

Happy Eyeballs;
DNS cache;
Secure DNS;
QUIC.

Они могут довольно хорошо скрыть неисправность одной address family.

Поэтому command-line тест иногда даёт более понятный результат.

Почему сайт иногда открывается через несколько секунд

Это типичный fallback-сценарий.

Например:

IPv6 → попытка
↓
несколько секунд ожидания
↓
IPv4 → успех

В результате сайт в итоге работает, но чувствуется задержка.

Happy Eyeballs как раз предназначен для уменьшения такого пользовательского ожидания.

Почему один браузер работает лучше другого

Разные приложения могут иметь:

разные Happy Eyeballs implementations;
разные DNS;
собственный DoH;
разный connection cache.

Поэтому:

Safari работает

а:

какое-то приложение timeout

не исключает IPv6-проблему.

Просто браузер мог быстрее переключиться на IPv4.

HAPP/Xray тоже может выбирать IP самостоятельно

Если конфигурация использует соответствующую domainStrategy, Xray может сам разрешить endpoint и выбрать IP.

Если нет — больше решения остаётся системному network stack.

Оба подхода могут быть рабочими.

Главное, чтобы стратегия соответствовала реальной сети.

Почему жёсткий ForceIPv4 иногда «чинит всё»

Потому что полностью исключает IPv6 из выбора.

Получается:

AAAA → игнорируется
A → используется

Если проблема была в плохом IPv6, симптомы исчезают.

Но это не обязательно правильное окончательное решение.

Почему не стоит оставлять IPv4-only без причины

Сегодня существуют:

dual-stack сети;
IPv6-first сети;
IPv6-only мобильные инфраструктуры;
сервисы, где IPv6 работает лучше.

Полное отключение IPv6 может:

убрать более удачный маршрут;
усложнить работу в IPv6-only среде;
скрыть настоящую неисправность.

Поэтому ForceIPv4 хорош как тест, а не универсальная настройка для каждого пользователя.

То же относится к ForceIPv6

Принудительный IPv6 тоже не является автоматической оптимизацией.

Если destination:

IPv4-only;
плохо доступен через IPv6;
находится за неудачным IPv6 peering,

получится обратная проблема.

Для обычного dual-stack пользователя автоматический выбор обычно разумнее.

Что рекомендует Xray для dual-stack

Актуальная документация Project X отдельно отмечает, что конструкции вроде:

UseIPv4v6

или:

ForceIPv4v6

не являются полноценной заменой Happy Eyeballs.

Если IPv4 успешно разрешился в DNS, но потом подключение к нему не удалось, такой режим не обязан перейти к IPv6.

Project X рекомендует использовать UseIP или ForceIP совместно с:

happyEyeballs.interleave

для более корректной работы с несколькими address families.

Обычному пользователю HAPP нужно это настраивать?

Чаще всего — нет.

Если VPN-сервис выдаёт готовую подписку, серверные и клиентские настройки должны быть подготовлены оператором.

Не нужно открывать JSON и вставлять domainStrategy только потому, что вы прочитали об IPv6.

Сначала проведите простые тесты.

Что делать, если один сервер работает, а другой нет

Например:

France → все сайты открываются

Netherlands → часть сайтов зависает.

Это намного сильнее указывает на:

server outbound;
routing;
DNS конкретного сервера;

чем на IPv6 вашего телефона.

Используйте рабочую локацию и сообщите оператору о проблемной.

Что делать, если через все VLESS-серверы одинаково

Тогда общая клиентская часть становится более вероятной.

Проверяйте:

сеть;
системный IPv6;
DNS;
HAPP;
routing profile.

Что делать, если проблема только через LTE

Очень полезный сценарий:

Wi-Fi → IPv4/IPv6 всё работает

LTE → часть сайтов висит.

Попробуйте:

4G вместо 5G.
Другой сервер.
Другую SIM.
Временно IPv4-only, если клиент позволяет.

Если другая SIM исправляет проблему, искать неисправность VLESS-сервера уже менее логично.

Что делать, если проблема только через Wi-Fi

Проверьте:

домашнего ISP;
роутер;
IPv6 WAN;
DNS.

Иногда роутер раздаёт клиентам IPv6-префикс, хотя upstream IPv6 работает неправильно.

Получается особенно неприятная схема:

устройство считает IPv6 доступным
↓
получает AAAA
↓
отправляет пакет
↓
маршрута реально нет

«Полуживой IPv6» хуже полного отсутствия IPv6

Если IPv6 вообще отсутствует, система быстро использует IPv4.

Намного хуже:

IPv6 формально есть, но реальная connectivity нестабильна.

Тогда клиент сначала считает этот путь рабочим.

И только после неудачи переключается.

Именно такие проблемы Happy Eyeballs старается скрыть от пользователя.

DNS тоже может влиять

Если DNS:

не возвращает AAAA;
возвращает неправильный AAAA;
ведёт себя по-разному direct/proxy,

результат также изменится.

Поэтому при сложной VLESS-конфигурации нужно рассматривать:

DNS + address family + routing

вместе.

Private DNS на Android

Android Private DNS может использовать отдельный resolver.

Если после изменения Private DNS появилась IPv4/IPv6-проблема:

верните Automatic и проведите тест ещё раз.

Не потому, что Private DNS несовместим с VLESS.

А потому что другой resolver может возвращать другой набор адресов или CDN endpoint.

Почему разные DNS могут отдавать разные адреса

Современные CDN используют сложное распределение.

DNS-ответ может зависеть от:

resolver;
региона;
сети;
инфраструктуры сервиса.

Поэтому:

DNS A → один набор IP

DNS B → другой набор IP.

Это относится и к IPv4, и к IPv6.

FakeDNS — это не IPv6

Не путайте эти две темы.

FakeDNS Xray может возвращать виртуальные адреса для transparent routing.

Это внутренний механизм сопоставления:

домен ↔ synthetic IP.

Он не означает, что конечный сайт действительно работает по IPv6 или IPv4.

Это отдельный слой.

Может ли TUN потерять IPv6

Да, если системная маршрутизация настроена только частично.

Например:

IPv4 → TUN
IPv6 → Direct

Тогда пользователь может получить:

IPv4 сайты через VLESS;
IPv6 соединения напрямую.

Это уже потенциальный leak и источник странного поведения.

Xray TUN умеет IPv6

В нормальной dual-stack-конфигурации виртуальный интерфейс может работать с обоими address families.

Но конкретная реализация клиента и routing profile определяют итоговое поведение.

Если проблема появилась только после включения TUN, сравните:

Proxy Mode;
TUN Mode.

Proxy работает, TUN нет

Если:

Proxy → сайты работают

TUN → часть IPv6-сайтов нет,

это сильнее указывает на:

системные routes;
TUN;
DNS;

чем на VLESS server credentials.

Не меняйте UUID.

Как проверить на сервере, есть ли IPv6

Администратор Linux-сервера может посмотреть:

ip -6 addr

и:

ip -6 route

Наличие IPv6-адреса ещё не гарантирует рабочий интернет.

Проверка исходящего IPv6 сервера

Например:

curl -6 https://example.com

или:

ping -6 ipv6.google.com

Если:

IPv4 → работает
IPv6 → Network unreachable

сервер явно не имеет нормального IPv6 outbound.

Если сервер не имеет IPv6 — это проблема?

Не обязательно.

VLESS-сервер прекрасно может работать полностью по IPv4.

Тогда конечные сайты тоже будут доступны через их IPv4 endpoints.

Проблема возникает, если конфигурация пытается использовать IPv6, которого реально нет.

Нужно ли вообще включать IPv6 на VPS

Если дата-центр предоставляет нормальный IPv6 — его вполне можно использовать.

Но включать его только ради галочки не нужно.

Хороший рабочий IPv4 лучше:

формально настроенного, но сломанного IPv6.

Проверьте firewall IPv6

На Linux иногда администратор правильно настроил IPv4 firewall и забыл про IPv6.

В результате:

IPv4 traffic работает;
IPv6 ведёт себя иначе.

Проверьте реальные правила используемого firewall:

nftables;
ip6tables;
firewalld;
security groups дата-центра.

Не предполагает ли firewall, что IPv6 «сам как-нибудь»

Нет.

IPv6 является отдельным address family.

Правила безопасности должны учитывать его явно.

Если сервер принимает соединения по IPv6, firewall должен быть настроен соответственно.

Сервер может слушать только IPv4

Проверьте:

ss -lntup

Например:

0.0.0.0:443

и:

[::]:443

могут означать разное поведение в зависимости от приложения и ОС.

Если DNS публикует AAAA, убедитесь, что сервис действительно доступен по IPv6.

Опасная комбинация: AAAA есть, сервиса по IPv6 нет

Например:

vpn.example.com
A    → рабочий IPv4
AAAA → IPv6 сервера

но Xray слушает только рабочий IPv4.

Клиент получает оба адреса.

Попытка IPv6 проваливается.

Это классическая причина странных задержек.

Если IPv6 сервиса не настроен, неправильный AAAA лучше не публиковать.

Как проверить endpoint VLESS

С клиента можно посмотреть DNS:

nslookup vpn.example.com

Если есть:

A;
AAAA,

проверяйте оба пути отдельно.

Не обязательно проблема находится в конечных сайтах — она может быть именно в адресе самого VPN-сервера.

Почему ping IPv6 не всегда доказывает работу VLESS

Как и с IPv4:

ICMP

и:

TCP/TLS/VLESS

— разные вещи.

IPv6 ping может прекрасно отвечать, а порт VLESS быть закрыт firewall.

Поэтому проверяйте именно нужный port/service.

Не публикуйте VLESS endpoint без необходимости

Если диагностируете проблему публично, можно показать:

есть ли A;
есть ли AAAA;
результаты без чувствительных данных.

Не нужно публиковать полный:

vless://...

с credential.

Что делать обычному пользователю: пошагово

Если VLESS и IPv6 подозреваются в проблеме:

Шаг 1

Попробуйте другой VLESS-сервер.

Шаг 2

Попробуйте другую сеть.

Шаг 3

Проверьте, есть ли проблема у всех сайтов или только нескольких.

Шаг 4

Посмотрите A/AAAA проблемного домена, если умеете.

Шаг 5

Временно проверьте IPv4-only.

Шаг 6

Если это исправило проблему — не останавливайтесь на выводе «IPv6 плохой».

Сообщите результат поддержке.

Что написать поддержке

Плохо:

с IPv6 что-то не работает.

Хорошо:

Windows 11, HAPP TUN. Через сервер NL часть сайтов открывается с задержкой 10–15 секунд. curl -4 работает сразу, curl -6 timeout. Через сервер FR оба варианта работают нормально.

Это уже очень полезные данные.

Или:

Android, по Wi-Fi всё работает. Через мобильного оператора сайты с AAAA периодически зависают, а после временного IPv4-only проблема исчезает. Другие VLESS-серверы ведут себя одинаково.

Здесь уже стоит смотреть мобильную сеть.

Когда временное отключение IPv6 оправдано

Именно как диагностический A/B-тест.

Например:

Тест A

IPv4 + IPv6:

сайт не открывается.

Тест B

только IPv4:

сайт сразу заработал.

Теперь известно:

неисправность каким-то образом связана с IPv6.

Это очень полезный результат.

Когда оставлять IPv6 выключенным

Если вам нужно быстро получить рабочее соединение, а исправить upstream прямо сейчас невозможно, временный IPv4-only режим вполне практичен.

Но долгосрочно лучше понять причину.

Особенно если устройство регулярно используется в:

мобильных IPv6-first сетях;
разных Wi-Fi;
путешествиях.

Не отключайте IPv6 во всей Windows ради одного сервера

Если:

VLESS NL → проблема

а:

VLESS FR → работает,

отключать IPv6 глобально на компьютере — слишком широкое решение.

Проще использовать исправный сервер и сообщить оператору о проблемном.

Не редактируйте domainStrategy наугад

Плохой сценарий:

AsIs
→ IPv4
→ IPv6
→ ForceIPv4
→ UseIPv6v4

и после десятой настройки VPN случайно заработал.

Вы не узнаете причину и легко сломаете что-то другое.

Для готовой подписки параметры лучше менять оператору, который видит серверную сторону.

Администратору своего Xray — наоборот, это полезно

Если инфраструктура ваша, стоит проверить:

какие A/AAAA опубликованы;
есть ли реальный IPv6 у VPS;
Xray listen;
firewall;
domainStrategy;
DNS;
server outbound.

Тогда выбор IPv4/IPv6 уже можно настраивать осознанно.

Happy Eyeballs не лечит сломанную инфраструктуру

Это тоже важно.

Happy Eyeballs способен скрыть проблему:

IPv6 сломан → быстро используем IPv4

но сам IPv6 от этого исправным не становится.

Это механизм повышения пользовательской доступности, а не замена правильной настройки сети.

RFC 8305 именно так рассматривает его: как способ уменьшить видимые пользователю задержки, когда один из доступных путей работает хуже другого.

Что лучше: IPv4 или IPv6 для VLESS

Нет универсального победителя.

Хороший:

IPv6 route

может быть лучше плохого:

IPv4 route.

И наоборот.

Важны:

peering;
провайдер;
дата-центр;
маршрут;
стабильность.

Поэтому сам номер версии IP не говорит о качестве соединения.

Нужно ли покупать VPN с поддержкой IPv6

Для современного долгосрочного сервиса полноценная IPv6-совместимость полезна.

Но важнее не наличие красивой надписи:

IPv6 supported,

а корректное поведение:

нет утечки мимо tunnel;
сайты работают;
dual-stack не создаёт timeout;
routing предсказуем.

IPv6 leak

Если VPN проксирует только IPv4, а IPv6 устройства продолжает выходить напрямую, сайт потенциально может видеть:

VPN IPv4;
реальный IPv6.

Это уже не просто вопрос доступности, а вопрос архитектуры tunnel/routing.

Если сервис заявляет полный системный VPN, обе address families должны обрабатываться предсказуемо.

Split tunneling и IPv6

Если routing специально отправляет часть трафика Direct, реальный IP для этих направлений является ожидаемым результатом.

Не каждое direct IPv6-соединение — leak.

Нужно различать:

намеренный Direct

и:

случайный обход VPN.

Как понять разницу

Смотрите routing profile.

Если:

local sites → Direct

и они используют реальный IPv6 — всё работает по плану.

Если:

proxy site → должен идти VLESS

но IPv6 обходит tunnel напрямую — это уже проблема.

Почему диагностика по одному IP-check сайту ограничена

IP-check показывает путь только самого этого сайта.

Он не доказывает, как маршрутизируются:

Discord;
YouTube;
другие домены;
IPv4;
IPv6.

Для серьёзной диагностики нужно несколько тестов.

Быстрая таблица диагностики

Симптом	Возможная причина
IPv4 работает, IPv6 timeout	IPv6 route
AAAA есть, сайт долго грузится	Плохой IPv6 / fallback
Один VLESS-сервер проблемный	Server IPv6/routing
Все серверы проблемные только на LTE	Mobile IPv6 path
Wi-Fi проблемный, LTE нормально	Router/ISP IPv6
Proxy работает, TUN нет	TUN IPv6 routing
A работает, AAAA нет	IPv6 connectivity
VLESS endpoint имеет плохой AAAA	VPN server IPv6
VPS `curl -4` работает, `curl -6` нет	Server outbound IPv6
IPv4-only временно всё исправляет	IPv6 участвует в проблеме
Один сайт проблемный	Destination/CDN/DNS
Всё работает кроме IPv6-only ресурса	Нет рабочего IPv6

Самая короткая последовательность проверки

Если через VLESS часть сайтов не открывается:

Попробуйте другую VLESS-локацию.
Сравните Wi-Fi и LTE.
Проверьте A и AAAA.
Сравните IPv4 и IPv6.
Временно протестируйте IPv4-only.
Если помогло — сообщите результат оператору.
Не оставляйте глобальные костыли без необходимости.

Так намного проще найти настоящий проблемный участок.

Если нужен готовый VLESS

На VLESS.ART используется готовая подписка для HAPP и совместимых клиентов с несколькими серверными локациями.

Это полезно и при сетевых проблемах:

если один маршрут ведёт себя плохо, можно переключиться на другую локацию без ручного изменения VLESS-конфигурации.

Посмотреть тарифы:
https://vless.art/#tarif

Если проблема явно зависит от IPv4/IPv6, при обращении в поддержку полезно указать:

устройство;
сеть;
сервер;
какой address family работает;
какой даёт timeout.

Итог

Если VLESS и IPv6 начинают странно взаимодействовать, не стоит сразу делать вывод:

IPv6 нужно отключить.

Чаще реальная проблема звучит точнее:

устройство видит рабочий IPv6-адрес, но путь до него работает хуже IPv4.

Современные dual-stack-системы должны уметь справляться с такими ситуациями.

RFC 8305 определяет Happy Eyeballs именно для случаев, когда hostname имеет несколько IPv4/IPv6-адресов, а одна из address families оказывается заблокированной, сломанной или неоптимальной.

Xray также поддерживает Happy Eyeballs для TCP через sockopt. При разрешении домена клиент может конкурирующе проверять несколько адресов и использовать первый успешно подключившийся. Project X отдельно рекомендует для dual-stack-сценариев сочетать UseIP/ForceIP с Happy Eyeballs вместо некоторых жёстких IPv4-first/IPv6-first конструкций.

Для обычного пользователя диагностика значительно проще:

другой сервер → другая сеть → A/AAAA → IPv4 против IPv6 → временный IPv4-only тест.

Если после отключения IPv6 сайт заработал — вы нашли направление поиска.

Но это ещё не означает, что IPv6 нужно удалить из системы навсегда.

Проверьте:

сервер;
маршрутизацию;
DNS;
TUN;
провайдера.

Очень часто достаточно исправить один плохой IPv6-path или использовать другую VLESS-локацию.

Хорошая dual-stack-конфигурация должна позволять IPv4 и IPv6 сосуществовать так, чтобы пользователь вообще не задумывался, какой именно протокол сейчас доставил его пакет.