Для чего нужен короткий ID REALITY?

Для чего нужен короткий ID REALITY?

Ryan Foster
12 сентября 2026 г.· 9 мин чтения

Короткий ID REALITY — это небольшое значение, которое выбирает клиент и которое должно точно совпасть с одним элементом серверного списка shortIds. По нему сервер REALITY проверяет, содержит ли входящее рукопожатие разрешённое значение конфигурации. Это лишь одна проверка: совпадение короткого ID не заменяет открытый ключ сервера, разрешённое имя сервера, совместимые версии программ или последующий ID пользователя VLESS.[1]

Полное руководство по VPN показывает весь путь соединения. Здесь мы рассматриваем только границу поля короткого ID, чтобы ошибку формата или выбора не смешивать со всеми настройками VLESS и REALITY.

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

  • Клиент использует поле shortId в единственном числе, а сервер — список shortIds.
  • Клиентское значение должно точно соответствовать одному серверному элементу и допустимому шестнадцатеричному формату.
  • Разрешено не более 16 шестнадцатеричных символов, а их количество должно быть чётным.
  • Пустое значение работает лишь тогда, когда сервер намеренно включил пустую строку.
  • Короткий ID не является ключом шифрования, но его всё равно следует защищать как чувствительные данные конфигурации.

Что такое короткий ID REALITY?

Project X определяет серверное поле shortIds как список для различения клиентов. У клиента есть один shortId, и он должен входить в серверный список.[1] Это проверка принадлежности множеству, а не переговоры: клиент не отправляет набор вариантов, из которого сервер выбирает подходящий.

Слово «ID» иногда создаёт неверное впечатление, будто поле обозначает учётную запись человека. Точнее считать его компактным селектором конфигурации внутри аутентификации REALITY. Оператор может назначить отдельные элементы разным разрешённым группам профилей и заменить одно значение, не обновляя все профили одновременно. Но смысл каждой группы задаёт администратор; протокол не гарантирует реальную личность владельца.

Обозначения: 1 — единственный клиентский shortId; 2 — проверка принадлежности серверному shortIds[] и документированного шестнадцатеричного формата; 3 — дальнейший путь аутентификации REALITY. Стрелки показывают связь настроек, а не буквальные поля пакета и не полную последовательность рукопожатия.

Как shortId сопоставляется с shortIds?

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

Официальная конфигурация допускает от нуля до шестнадцати шестнадцатеричных символов, причём длина должна быть чётной. Ядро помещает декодированные байты в начало восьмибайтового значения и дополняет остаток нулями справа. Например, aa1234 нормализуется так же, как aa12340000000000; нули слева меняют значение. Серверный список может содержать пустую строку, но клиент может использовать пустое значение лишь при наличии такой разрешённой записи.[1] Необязательность поля в одном примере не означает, что любой сервер его игнорирует.

ПроверкаКлиентСерверЗначение ошибки
Имя поляshortIdshortIdsПерепутаны число или расположение поля
ТипОдна строкаСписок строкОшибка импорта или схемы
АлфавитШестнадцатеричныйШестнадцатеричный для каждого элементаФормат не соответствует документации
ДлинаЧётная, максимум 16То же для каждого элементаЗначение повреждено или неверно скопировано
ПринадлежностьОдно нормализованное значениеТакая же нормализованная записьСелектор не проходит проверку REALITY
Пустое значениеПустой выборЕсть пустая строкаБез явного разрешения пустое значение отклоняется

Не «исправляйте» нечётную длину, угадывая место для нуля. Получите исходное значение из авторизованного источника. Короткое значение сохраняет только документированное дополнение нулями справа; нули слева или выдуманные цифры создают другой элемент.

Что доказывает несовпадение короткого ID?

Оно доказывает только невозможность пройти эту проверку в данной попытке. В зависимости от реализации клиент увидит ранний разрыв или общее сообщение об ошибке рукопожатия, а трафик после неудачной аутентификации REALITY может быть перенаправлен по настроенной ветви к цели (target).[1] Интерфейс не обязан сообщать прямо: «короткий ID не совпал».

Такой результат не доказывает блокировку REALITY сетью, ошибку открытого ключа или отклонение UUID VLESS. Это разные уровни. Порт сервера может быть доступен, но короткий ID отклонён. После его исправления может обнаружиться более поздняя проблема ключа, serverName, UUID, flow, маршрутизации или DNS.

Ищите первый различающийся этап. Если нужный слушатель видит соединение, а ключ и имя сервера сверены с разрешённым источником, проверка короткого ID обоснована. Если сервер вообще не видит попытку, изменение этого поля не исправит DNS, адрес, порт, межсетевой экран или маршрут.

Чем короткий ID отличается от UUID и ключа?

UUID VLESS обозначает разрешённого пользователя на уровне прокси-протокола.[3] Открытый материал клиента REALITY соответствует закрытому ключу сервера и участвует во внешней аутентификации. Короткий ID является отдельным селектором конфигурации REALITY. Называя все три значения «паролем», вы усложняете ротацию и лишаете диагностику границ.

ЗначениеУровеньОсновной вопросЧего оно не доказывает
REALITY shortIdREALITYЕсть ли селектор в shortIds?Личность или стойкость шифрования
REALITY passwordКлиент REALITYСоответствует ли открытый материал серверному ключу?Владение сертификатом сайта
VLESS id / UUIDVLESSРазрешён ли пользователь прокси?Владение устройством или успех REALITY
serverNameTLS-часть REALITYРазрешено ли имя и согласовано ли оно с целью (target)?Авторизацию пользователя
flowVLESS/XTLSКакой поддерживаемый алгоритм выбран?QoS или выбор маршрута

Руководство по уровням VLESS, REALITY и XTLS Vision объясняет эти различия. В реестре полезнее хранить отдельные метки полей, чем один непрозрачный «секрет профиля».

Как назначать и менять короткие ID?

Сначала определите владельца процесса и заведите реестр. Запишите, какой разрешённой группе соответствует запись, когда она выдана, в каком серверном списке находится и когда должна быть удалена. В общей инструкции оставляйте метку вроде «mobile-test-2026-09», а буквальное значение храните в защищённой системе конфигурации.

При ротации сначала добавьте новый элемент на сервер, разверните конфигурацию и прочитайте фактический список. Затем обновите нужные клиенты через аутентифицированный канал. Удаляйте старую запись после согласованного периода перекрытия. Такой порядок уменьшает простой и сохраняет точку возврата во время обновления клиентов.

Разные значения помогают понять, какая группа использует старую конфигурацию, но не образуют полноценную систему личности и отзыва.[2] Если несколько людей копируют один профиль, короткий ID не установит, кто сделал запрос. Для подотчётности используйте отдельные записи пользователей VLESS, контроль доступа и допустимые политикой журналы.

Минимизируйте данные в журналах. Частичного отпечатка, ревизии конфигурации и категории результата обычно достаточно. Не помещайте полный профиль, UUID, закрытые ключи и короткие ID в снимки экрана, публичные заявки, историю команд или аналитические события.

Как безопасно диагностировать ошибку короткого ID REALITY?

Зафиксируйте одну попытку: точное время с часовым поясом, версии клиента и сервера, ревизию конфигурации, адрес сервера и исходную категорию ошибки. Убедитесь, что клиент достиг нужного слушателя. Затем сравните разрешённые представления фактически разобранных shortId и shortIds, а не два интерфейса, которые могут скрыть или нормализовать поле.

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

Отдельно сверьте соседние поля REALITY: открытый материал в текущем клиентском password, выбранный serverName, настройки цели, системное время, отпечаток клиента (fingerprint) и совместимость версий. Статья о цели REALITY объясняет соответствующую границу, а многоуровневый список диагностики показывает, когда переходить к VLESS и маршрутизации.

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

Что делать, если не хочется вести короткие ID?

Некоторые читатели ведут списки shortIds только ради того, чтобы личное соединение продолжало работать. Для такой цели AethoVPN предлагает документированный сценарий другого рода: выберите в приложении локацию или рекомендуемый узел и подключитесь, ориентируясь на цвет индикатора нагрузки, вместо того чтобы генерировать, раздавать и ротировать короткие ID. Тот же клиент подходит для контрольной проверки: подключите его на том устройстве и в той сети, где не работает ваш клиент REALITY, и рабочий сеанс покажет, что устройство и сеть способны держать зашифрованное соединение, и ваша запись shortIds вместе с профилем клиента поднимается в списке подозреваемых. Официальный сайт не называет протокол AethoVPN, поэтому такое сравнение ничего не говорит об обработке short ID, а описанные здесь поля не являются настройками продукта. Создайте аккаунт по email для такого сравнения и никогда не придумывайте short ID для собственного сервера.

Итоги

  • Клиентский shortId должен нормализоваться в то же восьмибайтовое значение, что и одна запись shortIds сервера.
  • Допустимо чётное число шестнадцатеричных символов, максимум шестнадцать.
  • Пустая строка — явно разрешённая запись, а не универсальный шаблон.
  • Несовпадение локализует одну проверку REALITY, но ничего не доказывает о последующих слоях.
  • Храните, меняйте, сравнивайте и маскируйте короткие ID отдельно от ключей и UUID VLESS.

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

Является ли короткий ID REALITY секретом?

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

Могут ли два клиента использовать один короткий ID?

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

Обязательно ли иметь ровно шестнадцать символов?

Нет. Шестнадцать — максимум; число шестнадцатеричных символов должно быть чётным. Ядро дополняет короткое декодированное значение нулями справа до восьми байтов.

Всегда ли принимается пустой короткий ID?

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

Будет ли сообщение об ошибке однозначным?

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

Совпадает ли короткий ID с UUID VLESS?

Нет. Короткий ID относится к сопоставлению в конфигурации REALITY, а UUID обозначает разрешённого пользователя на уровне VLESS. Это разные значения на разных уровнях.

Следует ли менять короткий ID, если не открывается сайт?

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

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

Источники:

  1. Project X, "REALITY configuration": https://xtls.github.io/en/config/transports/reality.html
  2. XTLS, "REALITY README": https://github.com/XTLS/REALITY/blob/main/README.en.md
  3. Project X, "VLESS protocol": https://xtls.github.io/en/development/protocols/vless.html

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


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

Начните бесплатный 3-дневный пробный период

Зарегистрируйтесь и попробуйте все премиум-функции бесплатно.

*Только для новых пользователей. Один пробный период на пользователя.

Для чего нужен короткий ID REALITY? | AethoVPN