Почему не совпадает открытый ключ REALITY?

Если не совпадает открытый ключ REALITY, соединение отказывает, потому что клиенту нужен открытый материал, соответствующий настроенному на сервере privateKey. В современной клиентской конфигурации Project X он хранится в поле password; старые конфигурации и интерфейсы могут называть ту же роль publicKey. Если пара не соответствует, стороны не получают совместимый результат аутентификации REALITY.［1］

Полное руководство по VPN рассматривает весь путь. Здесь вопрос уже: какой ключ находится на каждой стороне, почему чужой открытый ключ не работает и чего такой отказ не говорит о сертификатах TLS или пользователях VLESS.

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

• Сервер защищает privateKey, а клиент получает только соответствующий открытый материал.
• Современный синтаксис клиента использует password; publicKey — прежнее имя поля, а не второй ключ.
• Корректно закодированный, но посторонний открытый ключ всё равно не соответствует закрытому.
• Сертификат сайта, serverName, короткий ID и UUID VLESS проверяются отдельно.
• При ротации создавайте и распространяйте новую пару по аутентифицированному каналу; никогда не копируйте закрытый ключ клиентам.

Что значит, если не совпадает открытый ключ REALITY?

Project X описывает серверный X25519 privateKey и клиентский password, содержащий соответствующий открытый ключ. Документация также отмечает прежнее имя клиентского поля — publicKey.［1］ Несовпадение появляется, когда клиент хранит ключ другого сервера, обрезанную копию, результат неверного импорта или старое значение после ротации.

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

Обозначения: 1 — открытый материал в современном клиентском поле password; 2 — отношение пары X25519; 3 — серверный privateKey, который не покидает сервер. Линии показывают связь конфигурации, а не передачу закрытого ключа и не полную трассу пакетов.

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

Система открытых ключей устроена так, чтобы по открытому значению нельзя было восстановить закрытое. REALITY включает ключевой материал в защиту и аутентификацию ожидаемого рукопожатия. Соответствующие значения позволяют сторонам получить совместимый результат без передачи закрытого ключа по сети. Проект REALITY описывает модифицированный TLS и серверную аутентификацию авторизованных клиентов без обычного сертификата.［2］

Если клиент использует открытый ключ сервера B, но подключается к серверу A, расчёты расходятся, даже когда оба сервера исправны. Повторные попытки не заставят независимые ключи совпасть. Изменение SNI, цели, UUID или настроек браузера также не исправит математическую связь.

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

Почему клиентское поле называется password?

Это имя в актуальной схеме, а не указание на пароль человека, общий секрет, пароль учётной записи или закрытый ключ сервера. Ориентируйтесь на документацию установленной версии. Интерфейс может продолжать показывать подпись «public key», хотя сгенерированный JSON уже содержит password.

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

Расположение	Современное поле	Старое имя	Роль
Сервер REALITY	privateKey	privateKey	Секретный закрытый материал X25519
Клиент REALITY	password	publicKey	Открытый материал, соответствующий серверному ключу
TLS-имя	serverName	Метка SNI	Разрешённое имя, согласованное с конфигурацией
Селектор REALITY	shortId	Короткий ID	Один элемент серверного списка
Пользователь VLESS	id	UUID	Разрешённая идентичность прокси

Название поля не доказывает, что конкретный продукт его предоставляет. URI подписки или QR-код могут скрыть отображение, поэтому сравнивайте результат импорта с авторизованным источником, а не правьте значение по догадке.

Чем это отличается от проблемы сертификата TLS?

Сертификат сайта связывает имена и открытые ключи через Web PKI. Ключевая пара конфигурации REALITY — другой вход аутентификации. Выбранные цель и serverNames влияют на внешнее TLS-поведение, но сертификат целевого сайта не является клиентским password REALITY. Его отпечаток или открытый ключ не заменит производное от серверного privateKey.

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

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

Чем это отличается от короткого ID и UUID VLESS?

Открытый ключ, короткий ID и UUID иногда называют учётными данными, но они отвечают на разные вопросы.［3］ Ключ соответствует материалу идентичности сервера REALITY. Короткий ID входит в разрешённый список REALITY. UUID соответствует пользователю VLESS после того, как внешняя обработка достигла этого уровня.

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

Материал о коротком ID REALITY объясняет проверку списка. Разбор уровней VLESS, REALITY и XTLS Vision показывает, почему нельзя заменять все значения одновременно.

Как генерировать и менять ключи?

Используйте документированную команду генерации X25519 в доверенной административной среде. Закрытое значение записывайте только в защищённое серверное хранилище, производное открытое — в авторизованную систему доставки клиентам. Избегайте общих терминалов с историей, чатов, публичных вставок, снимков и мониторинга, сохраняющего аргументы команд.

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

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

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

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

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

Получите разрешённое открытое значение для активного закрытого ключа документированным инструментом. Сравните безопасный отпечаток с эффективным клиентским password. Проверьте пробелы, обрезку, устаревшие QR-коды и подписки, импорт старого publicKey, неверную среду и случайно взятое значение другого сервера.

Если пара совпадает, переходите по порядку к serverName, короткому ID, времени, отпечатку клиента (fingerprint), версиям, идентичности VLESS и flow. Если не совпадает, исправьте только открытое значение через защищённый канал и повторите ограниченный тест. Контрольный список отказа VLESS Reality задаёт всю последовательность.

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

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

Если вы поддерживаете пару ключей REALITY только ради обычного зашифрованного соединения, подумайте, не подойдёт ли управляемый сервис лучше. В AethoVPN вход в аккаунт выполняется по коду подтверждения из письма, а документированная настройка сводится к установке клиента и выбору локации в приложении, без импорта и сверки ключей. Если на устройстве, где не работает клиент REALITY, AethoVPN подключается, значит, устройство выходит в интернет через зашифрованный туннель, и внимание остаётся на паре ключей, а не на базовой связности. В документации продукта нет ни REALITY, ни импорта ключей X25519, ни названия протокола, поэтому ожидаемый публичный ключ для вашего сервера по-прежнему должен предоставить уполномоченный владелец конфигурации. Создайте аккаунт по email, чтобы попробовать управляемый вариант.

Итоги

• Открытый материал клиента должен соответствовать активному серверному privateKey.
• Современное имя клиентского поля — password, старое — publicKey.
• Допустимо выглядящий ключ из другой пары всё равно не работает.
• Ключи REALITY, сертификаты сайтов, короткие ID и UUID VLESS являются разными входами.
• Диагностируйте по отпечаткам фактической конфигурации и меняйте ключи через защищённый канал.

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

Является ли клиентский password обычным паролем?

Нет. В текущей конфигурации REALITY в нём хранится открытый ключевой материал, соответствующий серверу. Это не пароль учётной записи человека и не закрытый ключ сервера.

Можно ли скопировать серверный privateKey клиенту?

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

Почему старая конфигурация пишет publicKey?

Это прежнее имя клиентского поля. Проверяйте схему установленной версии и эффективный импорт, а не заполняйте оба варианта.

Это ключ сертификата целевого сайта?

Нет. Проверка сертификата сайта и аутентификация конфигурации REALITY — разные процессы. Сертификат цели и разрешённое имя сервера не могут заменить пару ключей REALITY.

Может ли верный UUID исправить несовпадение ключа?

Нет. UUID VLESS относится к более позднему уровню аутентификации пользователя и не может исправить внешнюю ключевую связь 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 inbound configuration": https://xtls.github.io/en/config/inbounds/vless.html

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

---

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

• Проследить полный путь VPN
• Разделить уровни VLESS, REALITY и XTLS Vision
• Диагностировать отказ VLESS Reality
• Понять контракт target REALITY
• Понять короткий ID REALITY