Главная → Блог → VLESS, Reality и JSON-конфиг: как это устроено

VLESS, Reality и JSON-конфиг: как это устроено

Опубликовано: 1 октября 2026 Обновлено: 1 октября 2026 Команда VPN Просто

JSON — обычный текстовый формат, в котором клиентские движки хранят настройки подключения: сервер, порт, uuid, публичный ключ Reality. Наш ключ приходит уже готовой ссылкой — редактировать JSON руками не нужно.

Что такое JSON-конфиг

Формат появился в 2000-х годах как способ обмена данными между веб-страницей и сервером и с тех пор стал одним из самых распространённых способов записи настроек вообще — его используют далеко не только программы, связанные с VPN. Если открыть настройки многих приложений на компьютере, велика вероятность, что внутри окажется файл именно в этом формате: понятный человеку, но предназначенный в первую очередь для программ.

JSON (JavaScript Object Notation) — формат хранения структурированных данных, придуманный задолго до VPN и используемый везде: от настроек приложений до ответов интернет-сервисов. Ничего специфичного для защищённых соединений в нём нет — это просто способ записать набор пар «название параметра — значение» так, чтобы его одинаково понимали разные программы.

Движки xray-core и v2ray-core, на которых работает протокол VLESS, хранят в таком формате все параметры одного подключения: куда обращаться, каким способом шифроваться, как маскировать соединение под Reality. Когда человек говорит «настроить VLESS через JSON», он имеет в виду именно этот файл — набор полей, из которых движок собирает рабочее соединение.

Важно сразу разделить два разных сценария. Первый — самостоятельная установка xray-core на собственном сервере с нуля: там конфиг действительно пишут и правят руками, это стандартная практика для тех, кто поднимает VPN-сервер сам. Второй — обычное использование готового ключа от сервиса: там JSON существует, но им никто, кроме клиентской программы, не занимается. Путаница между этими двумя случаями и рождает вопрос «мне тоже нужно редактировать JSON?».

Отсюда же берутся и обучающие материалы, которые находятся по запросу вроде «настроить VLESS через JSON»: почти все они написаны именно для первого сценария — для тех, кто арендует сервер и разворачивает xray-core сам, с нуля. Это осмысленная и рабочая инструкция, но она отвечает не на тот вопрос, который обычно волнует человека с уже готовым ключом от сервиса. Разница в исходной задаче, а не в ошибочности одного из подходов.

Что хранится внутри: сервер, порт, uuid и другие поля

Не вдаваясь в точные названия конкретных полей (они отличаются между версиями движков и клиентов), в конфиге любого подключения VLESS + Reality есть данные одного и того же смысла:

• адрес сервера — куда клиент устанавливает соединение;
• порт — на каком номере сервер слушает подключения;
• uuid — уникальный идентификатор конкретного клиента, по нему сервер отличает одного пользователя от другого;
• публичный ключ Reality — часть криптографической пары, которая нужна для маскировки под чужой сайт;
• shortId — короткий дополнительный идентификатор, который использует Reality при проверке рукопожатия;
• sni — доменное имя сайта, под который маскируется соединение.

Это стандартная терминология самого протокола, а не что-то придуманное конкретным сервисом или клиентом — те же понятия встречаются в документации xray-core и в любом клиенте, который поддерживает Reality, независимо от того, кто выдал ключ.

Полезно и понимание порядка величин: полный набор этих параметров — буквально несколько строк текста, а не громоздкий документ. Опасение, что «настройка VLESS через JSON» — это сложная многостраничная процедура, обычно происходит из смешения самого формата хранения данных с процессом развёртывания сервера целиком, где кроме параметров подключения приходится настраивать ещё операционную систему, сетевые правила и автозапуск службы. К обычному подключению по готовому ключу это отношения не имеет.

Ссылка-ключ и ручной JSON: в чём разница

Ключ, который выдаёт бот, выглядит как одна строка, начинающаяся с vless://. Внутри этой строки уже закодированы все те же данные: сервер, порт, uuid, публичный ключ, shortId, sni — просто записанные компактно, одной последовательностью символов, а не отдельным файлом.

Когда вы вставляете такую ссылку в клиент — через кнопку «добавить профиль», через сканирование QR-кода или простой вставкой из буфера обмена, — программа сама разбирает строку на составляющие и строит из них рабочий JSON-конфиг внутри себя, за долю секунды. Вы этот процесс не видите и участия в нём не принимаете.

Ручное редактирование JSON — это другой сценарий: администратор сервера сам создаёт uuid, сам генерирует пару ключей Reality, сам прописывает порт и адрес в текстовом файле настроек сервера, а потом вручную формирует такую же структуру для клиентской стороны. Это работа уровня развёртывания сервера, а не уровня «подключиться к уже работающему сервису».

Что делать, если клиент просит поля отдельно

Некоторые продвинутые клиенты дают выбор: вставить одну ссылку целиком или ввести параметры по отдельности — для тех редких случаев, когда ссылку неудобно передать целиком (например, диктуют голосом). Тогда пригодится знание из списка выше: там, где клиент просит «адрес» — это то же самое значение, что и в ссылке после протокола, там, где просит uuid — идентификатор оттуда же, и так далее по каждому полю. Достаточно скопировать значения из ссылки в нужные поля формы, никаких новых данных придумывать не нужно.

Как в этом конфиге устроена Reality

В обычном TLS-соединении сертификат, который подтверждает подлинность сайта, выдаёт тот же сервер, к которому вы подключаетесь. При внимательной проверке видно, что сертификат выпущен именно для этого адреса — и именно по такой проверке фильтрующее оборудование отличает VPN-сервер от обычного сайта.

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

Из этого следует практический вывод: набор полей в конфиге VLESS + Reality длиннее, чем у простого TLS-подключения, именно из-за этой маскировки. Дополнительные строки — не усложнение ради усложнения, а именно тот механизм, который делает протокол устойчивым к блокировкам.

Ещё один параметр, который иногда встречается в более подробных конфигурациях Reality, — короткая настройка транспорта (в нашем случае — XTLS-Vision, вариант, оптимизированный по скорости для этого протокола). Разбираться в её значении обычному пользователю не нужно: это техническая деталь того, как именно клиент передаёт данные внутри уже установленного маскированного соединения, а не то, что влияет на порядок подключения ключом.

Как это устроено у нас

Мы не выдаём JSON-файл — мы выдаём готовую ссылку. Всё, что должно быть в конфиге — сервер, порт, uuid, публичный ключ Reality, shortId, sni, — уже закодировано в ней самим сервисом. Открывать текстовый редактор и вписывать что-либо руками не нужно ни на каком этапе обычного использования.

Ключ подходит для любого клиента, который понимает протокол. Поскольку данные внутри ссылки стандартные, тот же ключ работает и в Hiddify, и в Happ, и в любом другом клиенте на движке xray-core или совместимом с ним — привязки к одной конкретной программе нет.

Оба наших протокола — VLESS + Reality (XTLS-Vision) и Hysteria2. У Hysteria2 формат настроек внутри свой, потому что он устроен иначе технически, но принцип тот же: клиент получает всё нужное из одной ссылки, а не из набора значений, которые нужно вводить руками.

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

Если что-то не подключается, дело обычно не в конфиге. Ссылка либо целиком корректна, либо клиент выдаст явную ошибку при добавлении. Гораздо чаще причина в неполном копировании ключа (обрезан конец строки) или в устаревшей версии клиента — это стоит проверить в первую очередь, прежде чем подозревать проблему в самих данных подключения.

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

Если клиент устарел и не понимает свежий формат ссылки, мы говорим об этом прямо. Изредка старые версии некоторых клиентов действительно не справляются с разбором актуального формата ключа — тогда решение не в ручной правке JSON, а в обновлении самого клиента до текущей версии с официальной страницы проекта. Инструкции «поправить конфиг руками, чтобы обойти устаревший клиент» мы сознательно не даём: это временное решение, которое создаёт куда больше проблем, чем решает.

Когда JSON всё-таки может понадобиться

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

Первая — диагностика. Если клиент показывает подробности подключения (иногда это отдельный экран с техническими деталями), понимание того, что означают сервер, порт, uuid, publicKey, shortId и sni, помогает быстрее понять, что именно не сработало: например, если один из параметров окажется пустым или явно повреждённым при копировании.

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

Для подавляющего большинства пользователей ни одна из этих ситуаций не возникает: клиент из проверенного списка принимает ссылку целиком и справляется с разбором сам. Разбор самого протокола — зачем нужна Reality, чем VLESS отличается от других протоколов и как устроена вся эта система маскировки — отдельная тема: на странице про сам протокол VLESS + Reality она разобрана подробно, а эта статья намеренно ограничена конкретно форматом конфигурации.

Что почитать дальше: какой клиент выбрать — сравнение по возможностям, и что видит провайдер — как именно выглядит замаскированное соединение со стороны сети.

Частые вопросы