todo/protocols/vmess.md

date	tags	aliases	link
2026-07-25	протоколы vmess v2ray обход-блокировок	VMess VMess AEAD alterId	https://www.v2fly.org/en_US/developer/protocols/vmess.html

📮 VMess: протокол V2Ray, который проиграл собственному наследнику

[!info] О чём заметка Разбор протокола VMess — основного протокола V2Ray, который в 2010-х был стандартом обхода блокировок, а сегодня почти вытеснен xray/vless. Здесь: как он устроен, что означает загадочное поле alterId, какие уязвимости в нём находили и стоит ли его использовать в 2026 году. Карта протоколов целиком — в protocols/00-overview.

TL;DR

• VMess — протокол проекта V2Ray: пользователь опознаётся по UUID, каждое соединение шифруется, а в заголовке передаются время, случайные данные и адрес назначения.
• Ключевая идея времён создания — привязка к времени: заголовок аутентифицировался хешем от UUID и метки времени, поэтому часы клиента и сервера должны совпадать (расхождение больше пары минут ломает подключение).
• alterId — рудимент старой схемы с «дополнительными идентификаторами». В современных реализациях он должен быть 0, что включает VMess AEAD — правильный режим аутентификации заголовка.
• Старый режим (alterId больше нуля, аутентификация на MD5) объявлен устаревшим, а в Xray-core поддержку старой схемы убрали вовсе.
• В 2020 году в реализации V2Ray нашли уязвимость к активному зондированию: по реакции сервера можно было опознать VMess. Проблему закрыли переходом на AEAD-заголовки.
• Сегодня VMess держат в основном ради совместимости со старыми серверами. Для новых установок используют xray/vless: он проще, быстрее и активно развивается.

Как устроен VMess

VMess появился вместе с V2Ray как замена protocols/shadowsocks — с расширяемым заголовком, поддержкой разных транспортов и учётом пользователей. Соединение выглядит так.

Клиент знает UUID пользователя (строка вида b831381d-6324-4d53-ad4f-8cda48b30811) — это и есть учётные данные. Он формирует заголовок запроса, куда кладёт версию протокола, ключ и вектор инициализации для шифрования данных, выбранный метод шифрования, тип команды (TCP или UDP), адрес назначения и случайную набивку. Заголовок аутентифицируется так, чтобы сервер мог понять «это наш пользователь» ещё до расшифровки полезной нагрузки. Дальше идут зашифрованные данные, разбитые на блоки.

Привязка к времени — характерная деталь: в исходной схеме аутентификатор строился от UUID и текущей метки времени с допуском в несколько десятков секунд. Это давало защиту от повторов, но породило самую известную бытовую проблему протокола: если на клиенте сбились часы, подключение просто не устанавливается. Симптом узнаваемый — сервер жив, ключ верный, а соединение отваливается; проверка системного времени решает вопрос.

Что такое alterId и почему он должен быть 0

alterId — поле, которое до сих пор встречается в старых конфигах и вызывает больше всего вопросов. Исторически оно задавало число дополнительных идентификаторов, порождённых от основного UUID: клиент брал один из них для каждого соединения, чтобы аутентификаторы не повторялись и сервер не мог быть опознан по однообразию заголовков.

Схема оказалась и громоздкой, и уязвимой: аутентификация в ней опиралась на MD5, а сама конструкция давала наблюдателю материал для анализа. Её заменили на VMess AEAD — заголовок аутентифицируется и шифруется современным AEAD-примитивом. Включается это ровно одним способом: alterId: 0.

Правило простое: в 2026 году alterId в конфиге либо равен нулю, либо его нет вовсе. Старый режим (alterId больше нуля) объявлен устаревшим в V2Ray, а Xray-core поддержку прежней MD5-схемы удалил — конфиг с ненулевым alterId там просто не заработает.

Уязвимости и обнаружение

Активное зондирование (2020). В реализации VMess в V2Ray обнаружили уязвимость, позволявшую опознать VMess-сервер активной проверкой: причина была в том, как разбирался зашифрованный заголовок и как реализация реагировала на некорректные данные — по различиям в поведении сервер выдавал себя. Проблему нашли пользователи GitHub p4gefau1t и studentmain; современный режим с AEAD-заголовками ей не подвержен.

Проще говоря: цензору не нужно было расшифровывать трафик — достаточно было постучаться на подозрительный порт особым образом и посмотреть, чем сервер ответит. Это общий приём против прокси-протоколов, и устойчивость к нему сегодня — обязательное требование к дизайну (сравните с логикой protocols/trojan, который на неверный пароль отдаёт настоящий сайт).

Пассивное обнаружение. Как и Shadowsocks, VMess без обёртки не выглядит ничем легальным. Поэтому его почти всегда заворачивают в TLS и транспорт — WebSocket, gRPC, HTTP/2 — чтобы соединение походило на обычный веб-трафик. Но у связки «прокси внутри TLS» есть собственный узнаваемый почерк: шифрованное рукопожатие внутри шифрованного канала даёт характерные размеры и тайминги пакетов. Этот класс детекта разобран в VLESS/dpi-tls-june-2026 — и именно против него придуманы XTLS Vision и protocols/anytls.

[!warning] «Работает» не значит «незаметен» VMess с корректным AEAD-заголовком криптографически в порядке, и подключение через него устанавливается. Но по устойчивости к современному DPI он проигрывает связкам с xray/reality и XTLS Vision, потому что не решает задачу «TLS внутри TLS». Если узел на VMess у вас регулярно отваливается волнами — дело обычно не в сервере, а в том, что схему научились отбирать.

Стоит ли использовать VMess в 2026 году

Практический ответ: для новых установок — нет, для совместимости — да, с оговорками.

Причина вытеснения не в том, что VMess «плохой», а в том, что его наследник делает то же самое дешевле. xray/vless сознательно убрал из протокола собственное шифрование и привязку ко времени: раз соединение и так идёт внутри TLS, второй слой шифрования — это лишний расход процессора и лишний слой, который и создаёт заметный почерк. Отсюда и XTLS Vision, и REALITY — они возможны именно потому, что VLESS не шифрует данные повторно.

Если VMess у вас всё же используется, минимальный набор требований такой:

• alterId: 0 — то есть режим AEAD; ненулевое значение означает мёртвую MD5-схему.
• Актуальная версия ядра на клиенте и сервере — старые сборки несут исправленные с тех пор ошибки реализации.
• Обёртка TLS плюс транспорт (WS/gRPC/HTTP2) — голый VMess в сети с DPI живёт недолго.
• Синхронные часы на обеих сторонах.

📚 См. также

• protocols/00-overview — какое ядро что поддерживает и чем протоколы отличаются по задачам.
• xray/vless — прямой наследник VMess и рекомендуемая замена.
• xray/authors-v2ray-xray — история проектов, в которых родились оба протокола.
• xray/v2fly-vs-xray — почему у VMess два развивающихся дома и чем они отличаются.
• protocols/shadowsocks — протокол, на смену которому VMess когда-то и пришёл.
• VLESS/dpi-tls-june-2026 — как обнаруживают «прокси внутри TLS».
• 🔗 Описание протокола VMess на v2fly.org — первоисточник по формату.

---

[!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: исходник этой заметки · весь репозиторий.