Протокол VLESS + Reality

Почему у VLESS нет собственного шифрования

VLESS вырос из VMess как сознательное упрощение. Из протокола убрали собственную криптографию, встроенную маскировку и привязку ко времени: остался минимальный слой, который умеет только аутентифицировать клиента по UUID и объявить, куда направить поток. Такой транспорт называют stateless — сервер не хранит состояния между сессиями сверх необходимого.

На первый взгляд это выглядит как потеря. На деле шифровать данные дважды бессмысленно: внешний слой TLS 1.3 уже даёт конфиденциальность и целостность, а второй проход по AEAD только съедает такты процессора. Разница заметна на скоростях от 500 Мбит/с — примерно 8–12% нагрузки на ядро уходит впустую.

Есть и вторая причина. У VMess было собственное рукопожатие со своей структурой пакета, и именно эта структура становилась опознавательным признаком. Убрав её, разработчики оставили снаружи только TLS, у которого нет ничего специфичного. Отсюда правило: VLESS без внешнего защищённого слоя использовать нельзя, он для этого не предназначен.

Что Reality делает с рукопожатием TLS

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

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

Ключевое отличие от схемы «TLS внутри TLS» — отсутствие второго рукопожатия. У вложенного TLS характерна временная картина: два рукопожатия подряд, второе внутри зашифрованного канала, с узнаваемым распределением размеров пакетов. У Reality рукопожатие ровно одно, и оно подлинное.

Устойчивость к активной проверке

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

Сервер Reality на посторонний запрос ведёт себя как прозрачный посредник к тому самому стороннему сайту. Проверяющий получает настоящий ответ настоящего ресурса: правильные заголовки, правильный сертификат, правильное содержимое. Отличить такой ответ от прямого обращения к сайту по одному соединению нельзя.

Оговорка честная: неотличимость не абсолютна. Она держится на том, что выбранный внешний сайт популярен и обращение к нему выглядит естественно, а сервер не выдаёт себя объёмом или ритмом трафика. Если с одного адреса круглые сутки идёт поток в сотни гигабайт «к сайту-визитке», статистика заговорит раньше, чем криптография.

Честная цена такого решения

Самая частая проблема — настройка. В профиле полтора десятка параметров, и большинство из них не имеет значений по умолчанию: публичный ключ, short id, имя внешнего сайта, отпечаток клиента. Ошибка в одном символе не даёт осмысленного сообщения. Соединение просто не поднимается, а лог показывает обрыв рукопожатия без причины.

Второе ограничение — зрелость. WireGuard принят в ядро Linux и прошёл независимый аудит; у Reality за плечами существенно меньше лет и всего два основных ядра, Xray-core и sing-box. Это не делает решение ненадёжным, но означает, что запас проверенных реализаций у него меньше.

Третье — транспорт TCP. При потере пакета останавливается весь поток до повторной передачи, поэтому на канале с 3–5% потерь связка проигрывает решениям поверх UDP по фактической пропускной способности. В спокойной сети разница не видна, в мобильной на краю покрытия — видна отчётливо.