VLESS Reality работает в одной сети, но не в другой

Если VLESS Reality работает в одной сети, но не в другой, профиль не обязательно повреждён. Зафиксируйте клиент, сервер, конфигурацию, устройство и короткое окно времени, а затем по одному сравните TCP и порт, семейство IP, DNS, MTU, SNI, локальную политику и фильтрацию пути. Первый воспроизводимый различающийся этап полезнее случайной смены настроек.

Полное руководство по VPN показывает весь путь. Эта инструкция предполагает, что один и тот же профиль уже доказан в сети A, и рассматривает только контролируемое сравнение сетей.

Ключевые выводы

• Сначала сохраните чистый результат в рабочей сети A, не меняя профиль.
• Отделяйте доступность TCP от авторизации REALITY и последующего прокси-трафика.
• Сравнивайте IPv4/IPv6, DNS, порт, MTU, SNI, политику и фильтрацию как отдельные гипотезы.
• Не ослабляйте сертификаты и идентификаторы и не обходите правила владельца сети.
• Записывайте время и очищенные ошибки, чтобы стороны анализировали одно событие.

Сначала зафиксируйте переменные, если VLESS Reality работает в одной сети, но не в другой

Используйте одно устройство, версию клиента, профиль, адрес и порт сервера, serverName, открытый ключ, short ID, нижний транспорт и контрольный сайт. Проведите два теста близко по времени, иначе обновление сервера, DNS или сертификата станет скрытой переменной.

Полный экспорт профиля не нужен и опасен. Запишите только несекретные поля и версии; удалите идентификаторы пользователей, ключи, URI подписки, токены и точные частные адреса. Не публикуйте строку подключения.

Доказательство	Рабочая сеть A	Проблемная сеть B
Время и часовой пояс	Точное значение	Точное значение
Тип и владелец доступа	Wi-Fi/мобильная/Ethernet	Wi-Fi/мобильная/Ethernet
Обычный HTTPS	Результат	Результат
Хост и порт сервера	Одинаковые, очищенные	Одинаковые, очищенные
DNS A/AAAA	Записаны	Записаны
TCP	Успех/тайм-аут/отказ	Успех/тайм-аут/отказ
REALITY	Этап, ошибка, время	Этап, ошибка, время
Малый запрос после связи	Результат	Результат

Доступен ли сервер VLESS Reality из обеих сетей?

Шаг 1. Проверьте обычный доступ

В сети B отключите профиль и откройте обычную разрешённую HTTPS-страницу. Завершите вход на портале авторизации через его законную страницу. Не принимайте предупреждение сертификата: перехваченный TLS не является чистой исходной точкой.

Запишите наличие DNS, маршрута по умолчанию и стабильного сигнала. Если обычный интернет не работает, сначала исправьте доступ. Ошибка VLESS Reality не укажет причину туннеля, пока нижний путь недоступен.

Повторите небольшой запрос в сети A. Это не тест скорости, а подтверждение, что обе сети в данный момент способны переносить обычный трафик.

Шаг 2. Найдите первый этап сбоя

Сообщение «не удалось подключиться» скрывает разные стадии:

1. DNS разрешает имя сервера.
2. Устройство выбирает IPv4 или IPv6.
3. TCP достигает нужного порта.
4. REALITY проверяет serverName, ключ и short ID.
5. VLESS проверяет сессию пользователя.
6. Клиент направляет трафик приложения.
7. Удалённый выход достигает контрольного назначения.

Project X определяет VLESS как лёгкий транспортный протокол без хранения состояния и описывает поля адреса и идентичности.［1］ У REALITY есть отдельные target, serverNames, ключ и short ID.［2］ Поэтому отсутствие TCP нельзя называть ошибкой VLESS-аутентификации.

Шаг 3. Сравните порт и TCP

Если B не завершает TCP, а A завершает, проверьте ровно тот же адрес и порт. Гостевой Wi-Fi, офисная сеть или оператор могут разрешать обычные веб-сайты, но запрещать неизвестные точки или порты. Такой же симптом создаёт локальный межсетевой экран.

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

Другой разрешённый оператором адрес сервера можно сравнить позже как одну переменную. Не маскируйте сервис под запрещённый порт и не обходите явную политику.

Сравните адресацию, рукопожатие, передачу и политику

Шаг 4. Сравните IPv4 и IPv6

Одно имя может иметь записи A и AAAA. Сеть A может использовать IPv4, а B — предпочесть IPv6. Сеть только с IPv6 иногда зависит от DNS64/NAT64, которые не помогают буквальному IPv4-адресу без DNS. Отдельное руководство по сетям только с IPv6 разбирает эту границу.

Запишите реально выбранное клиентом семейство, а не только наличие IPv6 на устройстве. Сравните DNS-ответы и выясните, указано ли в профиле имя узла или буквальный IP-адрес. Убедитесь, что сервер слушает те семейства, которые обещает оператор.

Не выключайте IPv6 глобально. Это изменит исходную сеть и может сломать обычный доступ, не доказав совместимость профиля.

Шаг 5. Сравните DNS

Если в профиле указано имя узла, получите A/AAAA в обеих сетях и отметьте время. Разные ответы могут быть нормальны из-за географии, кэша, раздельного DNS или политики резолвера. Неудача также может быть обычной поломкой DNS.

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

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

Шаг 6. Проверьте SNI и REALITY

REALITY принимает SNI из serverNames; имя должно подходить сертификатному поведению цели.［2］ Руководство проекта также относит поддержку протоколов и маршрут цели к условиям совместимости.［3］ Посредник сети может по-разному обрабатывать SNI, но опечатка, старый профиль или изменение цели дают похожий результат.

Сравните точный несекретный serverName и версию клиента. Если TCP в B проходит, а неизменное рукопожатие нет, сохраните ошибку и время. Не подставляйте случайный известный домен: цель и разрешённое имя связаны на сервере.

Обычный HTTPS к целевому имени, заблокированный в B, поддерживает гипотезу о политике пути, но не доказывает идентичную обработку REALITY.

Шаг 7. Проверьте симптом MTU

Проблема MTU часто проявляется после видимого старта: маленький запрос проходит, большая страница зависает, отдача данных ломается раньше загрузки или соединение сбрасывается при росте обмена. Это не похоже на TCP, который вообще не открылся.

Сравните один малый и один умеренный разрешённый запрос. Запишите порог и потери, не создавая нагрузку. Если клиент предлагает документированный MTU, измените только его в допустимых пределах и верните обратно при отсутствии улучшения.

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

Шаг 8. Проверьте локальную и сетевую политику

Ищите управляемые профили, средства защиты конечных точек, родительский контроль, принудительный частный DNS, фильтры контента и правила гостевой сети. Рабочий ноутбук подчиняется политике устройства даже дома, а личный телефон — политике корпоративного Wi-Fi.

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

Если вам нужно соединение, которое работает в обеих сетях, а не починка профиля, управляемый клиент — более короткий путь. Установите AethoVPN, в каждой разрешённой сети подключитесь к одной и той же локации из приложения, а если в более строгой сети она зависает, выберите другую, отмеченную зелёным индикатором нагрузки. Начните 3-дневный бесплатный пробный период, чтобы сравнить сети бок о бок. Эти результаты описывают управляемый сервис в ваших двух сетях; если нужно исправить собственный профиль VLESS, проверкой остаются шаги с рукопожатием REALITY выше: в опубликованной настройке AethoVPN не назван ни один протокол.

Шаг 9. Отделите фильтрацию от сбоя сервера

После ошибки в B снова проверьте A, не меняя профиль. Если теперь не работает и A, могли измениться сервер, учётная запись, сертификат или состояние сервиса. Если A стабильно успешна, а B ломается на одном этапе, переменная пути становится сильнее.

Второе разрешённое устройство в B используйте только для подтверждения. Два одинаковых сбоя TCP направляют анализ к сети; разный результат требует сравнения ОС, семейства IP, версии клиента, межсетевого экрана и разрешения на VPN.

Один симптом не доказывает обнаружение. Перегрузка, IPv6, DNS, порт, MTU и политика способны дать одинаковую картину. Выбирайте самое узкое объяснение, подтверждённое данными.

Шаг 10. Передайте данные владельцу этапа

Оператору сервиса отправьте очищенные версии, время, семейство адреса, результат TCP, ошибку REALITY, ошибку VLESS при её наличии и итоги однофакторных тестов. Владельцу сети достаточно категории адреса и порта, времени и результата обычного HTTPS; не раскрывайте ключи.

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

Руководство по проверке VPN поможет оценить маршрут после успешной связи, но не объяснит сбой до рукопожатия.

Итоги

• Зафиксируйте профиль, устройство, сервер и временное окно.
• Найдите первый различающийся этап: DNS, IP, TCP, REALITY, VLESS, маршрут или сайт.
• Проверяйте порт, IPv4/IPv6, DNS, MTU, SNI, политику и фильтрацию отдельно.
• Повторно проверьте сеть A, чтобы исключить изменение сервера.
• Тесты должны быть разрешёнными, ограниченными, обратимыми и без секретов.

Часто задаваемые вопросы (FAQ)

Работа по мобильной сети доказывает блокировку REALITY в Wi-Fi?

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

Нужно изменить serverName в проблемной сети?

Нет. Имя должно совпадать с серверным serverNames и целью. Случайная замена создаёт другую, обычно неверную конфигурацию.

Может ли сеть только с IPv6 достичь сервера только с IPv4?

Иногда через DNS64/NAT64 при использовании имени узла, но не всегда. Буквальный IPv4-адрес обходит DNS-синтез и может быть недоступен.

Почему связь начинается, но большие страницы зависают?

Так выглядит проблема MTU или потерь после рукопожатия. Сравните малый и умеренный запрос перед документированным изменением MTU.

Тайм-аут TCP доказывает цензуру?

Нет. Он показывает лишь отсутствие ответа. Потеря маршрута, правила межсетевого экрана, сбой сервера, перегрузка и намеренная фильтрация выглядят одинаково.

Можно отключить антивирус или управление устройством?

Нет. Используйте журналы и разрешённые временные настройки только на управляемом вами устройстве; не снимайте организационные защиты.

Что безопасно отправить поддержке, если VLESS Reality работает только в одной сети?

Версии, время, типы сетей, DNS и семейство IP, первый этап ошибки и итоги A/B. Не отправляйте полный профиль, ключи, токены или URI подписки.

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

Источники:

1. Project X, "VLESS": https://xtls.github.io/en/config/outbounds/vless.html
2. Project X, "REALITY": https://github.com/XTLS/Xray-docs-next/blob/main/docs/en/config/transports/reality.md
3. XTLS, "REALITY README": https://github.com/XTLS/REALITY/blob/main/README.en.md

Sources checked 9 сентября 2026 г.

---

Рекомендуемые статьи:

• Разобрать полный путь VPN
• Диагностировать сбой VLESS Reality
• Проверить общий сбой соединения
• Проверить маршрут после подключения
• Диагностировать сеть только с IPv6