У VLESS Reality чаще всего ломается не сам ключ, а связка параметров вокруг него: serverName, shortId, публичный ключ сервера, транспорт и клиент. В начале страницы есть кнопка с альтернативным официальным вариантом подключения — это разумный сценарий, когда не хочется разбираться с чужими ключами, случайными конфигами и ручной сверкой каждого поля.
Что именно обычно ломается
Когда пользователь говорит, что «не работает Reality ключ», проблема обычно не в одном поле, а в несовпадении клиентской и серверной конфигурации. В Xray для REALITY на сервере важны target или старое имя dest, список допустимых serverNames, приватный ключ сервера и список shortIds. На клиенте важны serverName, shortId, публичный ключ сервера и поддерживаемый отпечаток TLS-клиента. Эти параметры должны соответствовать друг другу, иначе соединение не пройдет проверку.
Официальная документация Xray прямо указывает, что REALITY работает только при security: reality, а клиентский serverName должен быть одним из серверных serverNames. Также клиентский shortId должен совпадать с одним из значений на сервере, а публичный ключ клиента берется из серверного приватного ключа через x25519. Старое имя поля publicKey в документации переименовано в password, что тоже нередко путает пользователей.
Как связаны TLS, SNI и Reality
Reality не отменяет логику TLS, а использует ее как основу. Поэтому ошибки с SNI и серверным именем всплывают очень часто. В Xray поле serverName в TLS означает имя сервера, которое должно присутствовать в SAN сертификата; если это домен, он отправляется в SNI, а IP-адрес не отправляет SNI вовсе. Для REALITY логика похожая: клиентский serverName должен совпадать с тем, что сервер разрешает в serverNames.
Отдельный важный момент: в REALITY сервер может принимать подключения без SNI только если в серверном списке serverNames есть пустая строка "". В таком режиме клиент не оставляет поле пустым, а указывает IP-адрес как заполнитель, чтобы Xray отправил Client Hello без SNI. Если на сервере пустого значения нет, а клиент пытается работать без SNI, соединение, как правило, не проходит.
Еще одна частая причина путаницы — смешение обычного TLS и REALITY. В Xray это разные режимы транспорта: security: tls и security: reality. Они не взаимозаменяемы. Документация также указывает, что REALITY можно использовать только с транспортами RAW, XHTTP и gRPC. Если одна сторона настроена на WebSocket или другой транспорт, а вторая — на RAW/Reality, соединение не поднимется.
Быстрая диагностика по симптомам
| Симптом | Вероятная причина | Первое действие |
|---|---|---|
| Ключ вставлен, но подключения нет | Не совпадает public key, password или private key/public key пара | Сгенерировать публичный ключ заново из серверного приватного ключа и сверить клиент |
| Подключение висит или сразу обрывается | Неверный serverName или SNI | Проверить, входит ли client serverName в serverNames на сервере |
| Работает у одного клиента и не работает у другого | Разный fingerprint, версия клиента или несовместимый формат конфига | Сверить тип клиента, формат полей и актуальность приложения |
| Ошибка после импорта ссылки | Клиент неправильно разобрал shortId, flow или transport | Открыть конфиг вручную и проверить поля по одному |
| Подключение идет, но трафик не проходит | Проблема в target, маршрутизации или серверной схеме | Проверить серверный target и базовую доступность сервера |
| Не работает только на части сетей | Сетевая фильтрация, нестабильный маршрут, особенности провайдера | Проверить работу с другой сети и без чужих конфигов |
Какие поля проверить в конфиге в первую очередь
1. Публичный и приватный ключ
На сервере в REALITY используется privateKey, а на клиенте — соответствующий ему публичный ключ. В Xray этот клиентский параметр сейчас описан как password, а старое имя publicKey оставлено как прежнее обозначение, из-за чего многие считают, что документация противоречит самой себе. На деле это один и тот же смысл: клиент должен получить публичный ключ, сгенерированный из приватного ключа сервера.
2. serverName и serverNames
Клиентский serverName должен быть одним из значений серверного массива serverNames. Подстановка похожего домена, другого поддомена или случайного имени часто приводит к тому, что ключ формально выглядит правильным, но рукопожатие не проходит. Документация Xray отдельно подчеркивает, что шаблоны со звездочкой не поддерживаются.
3. shortId
shortId должен совпадать с одним из серверных shortIds. Для Xray длина shortId — до 8 байт, то есть до 16 шестнадцатеричных символов, при этом число символов должно быть четным. Значение может быть короче 16 символов, а ядро дополнит его нулями справа, но нечетная длина вызывает ошибку. Это одна из самых частых мелких поломок после ручного редактирования или кривого импорта ссылки.
4. transport и security
Обе стороны должны использовать совместимый транспорт. Для REALITY это не любой режим, а только те, что перечислены в документации: RAW, XHTTP и gRPC. Если в клиенте остался WebSocket, HTTPUpgrade или другой режим из старого профиля, ключ может выглядеть рабочим, но подключение не состоится.
5. Совместимость клиента
Часть ошибок связана не с сервером, а с конкретным приложением. Официальная документация REALITY для Xray описывает текущие поля и даже отмечает переименование некоторых параметров. Поэтому старые клиенты, старые шаблоны ссылок и готовые профили из случайных каналов могут использовать устаревшие названия или неполный набор полей. Если импорт «ссылкой» не работает, лучше открыть JSON или профиль вручную и сверить содержимое по документации используемого ядра.
Частые ошибки и как их исправить
| Ошибка | Что значит | Как исправить |
|---|---|---|
| Неверный public key / password | Клиент получил не тот публичный ключ от серверного privateKey | Пересоздать ключевую пару и заменить значение в клиенте |
| Неправильный SNI | client serverName не совпадает с serverNames на сервере | Указать ровно одно из разрешенных имен |
| Неверный shortId | Клиентский shortId отсутствует в shortIds сервера или имеет нечетную длину | Сверить значение посимвольно, проверить длину и формат hex |
| Смешан TLS и Reality | Одна сторона ожидает tlsSettings, другая realitySettings | Привести обе стороны к одному режиму security |
| Неверный transport | Одна сторона работает не на том типе транспорта | Проверить network: raw, xhttp или grpc на обеих сторонах |
| Проблемный target/dest | Серверный target задан неудачно или ведет себя нестабильно | Проверить target отдельно и убедиться, что схема вообще жизнеспособна |
Особенно часто пользователи ломаются на том, что считают поля serverName и адрес сервера одним и тем же. Это не всегда так. Адрес, к которому подключается клиент, и имя, которое он отправляет в TLS/REALITY, могут отличаться. Поэтому копирование только IP и ключа без проверки SNI почти всегда рискованно.
Есть и более тонкий момент: Xray различает серверную и клиентскую сторону REALITY по наличию поля target. Документация прямо предупреждает, что на клиентской стороне его указывать не нужно, иначе ядро может неверно определить тип конфигурации. Это редкая, но очень неприятная ошибка при ручной сборке профиля.
Нюансы Xray и sing-box
Если сервер собран на Xray, а клиент — на sing-box, нужно особенно внимательно сверять названия и смысл полей. У Xray в актуальной документации клиентский публичный ключ REALITY описан как password, а многие готовые материалы и генераторы до сих пор используют старое обозначение publicKey. Это не обязательно ошибка, но при переносе настроек между разными клиентами и панелями нужно смотреть, какое имя поля ожидает именно ваш клиент.
Документация sing-box показывает, что VLESS — это отдельный тип outbound, а конкретные детали транспорта и TLS/REALITY зависят от схемы конфигурации выбранной версии. Из-за этого старые примеры из репозиториев и скриптов легко расходятся с актуальным форматом. Если профиль импортировался из стороннего генератора, а потом перестал работать после обновления приложения, это вполне может быть следствием изменения структуры настроек.
Практический вывод здесь простой: не доверяйте слепо одной ссылке или QR-коду. Для диагностики важнее увидеть реальные поля: адрес сервера, порт, network, security, serverName, shortId, fingerprint и публичный ключ.
Безопасный порядок проверки
- Убедитесь, что сервер вообще доступен по IP и нужному порту.
- Проверьте, что на сервере и клиенте используется именно REALITY, а не обычный TLS.
- Сверьте transport: для REALITY это должен быть raw, xhttp или grpc, в зависимости от вашей схемы.
- Сверьте клиентский serverName с одним из serverNames на сервере.
- Проверьте shortId: он должен быть из серверного списка и иметь четную hex-длину.
- Пересоздайте публичный ключ из server privateKey и замените значение на клиенте.
- Проверьте, не попал ли на клиент лишний target или другой серверный параметр.
- Если профиль взят из чужого источника, соберите минимальную конфигурацию вручную и исключите все лишнее.
Если проблема именно в нестабильных чужих ключах или случайных конфигах, логичнее не тратить время на бесконечную ручную переборку. В таком сценарии кнопка в начале страницы выглядит более предсказуемым вариантом подключения на разных устройствах.
Можно ли использовать IP вместо serverName?
В обычном TLS IP не отправляет SNI. В REALITY клиент тоже может использовать IP как заполнитель для режима без SNI, но только если серверная сторона это допускает через пустое значение в serverNames. Иначе такая схема не сработает.
Почему ключ работал раньше, а потом перестал?
Обычно причина в обновлении клиента, замене серверного privateKey, изменении shortId, serverName или формата профиля. Иногда ломается не ключ, а импорт из устаревшей ссылки.
Можно ли оставить shortId пустым?
Да, но только если серверный список shortIds содержит пустую строку. В Xray это допускается, поскольку нулевая длина считается четной.
Что важнее проверить в первую очередь?
Сначала связку public key, serverName и shortId. Именно эти три поля чаще всего дают ощущение, что «ключ не работает», хотя сервер на самом деле жив.
Вывод
Когда VLESS Reality не подключается, не стоит упираться только в слово «ключ». На практике чаще всего ломаются SNI, shortId, публичный ключ, transport или совместимость клиента. Начинайте с минимальной сверки полей, не смешивайте TLS и Reality, не доверяйте слепо чужим конфигам и проверяйте, что клиент и сервер говорят на одном языке. Такой порядок обычно находит ошибку быстрее, чем бесконечный импорт новых ссылок.
Нет комментариев.