todo/protocols/vmess.md

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

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

> [!info] О чём заметка
> Разбор протокола **VMess** — основного протокола V2Ray, который в 2010-х был стандартом обхода блокировок, а сегодня почти вытеснен [[xray/vless|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|VLESS]]: он проще, быстрее и активно развивается.

## Как устроен VMess

VMess появился вместе с V2Ray как замена [[protocols/shadowsocks|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|Trojan]], который на неверный пароль отдаёт настоящий сайт).

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

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

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

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

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

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

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

## 📚 См. также

- [[protocols/00-overview|Обзор протоколов]] — какое ядро что поддерживает и чем протоколы отличаются по задачам.
- [[xray/vless|Протокол VLESS]] — прямой наследник VMess и рекомендуемая замена.
- [[xray/authors-v2ray-xray|Кто стоит за V2Ray и Xray]] — история проектов, в которых родились оба протокола.
- [[xray/v2fly-vs-xray|v2fly против Xray]] — почему у VMess два развивающихся дома и чем они отличаются.
- [[protocols/shadowsocks|Shadowsocks]] — протокол, на смену которому VMess когда-то и пришёл.
- [[VLESS/dpi-tls-june-2026|VLESS + TLS: DPI-почерк]] — как обнаруживают «прокси внутри TLS».
- 🔗 [Описание протокола VMess на v2fly.org](https://www.v2fly.org/en_US/developer/protocols/vmess.html) — первоисточник по формату.

---

> [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ
> При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/protocols/vmess.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main).