VLESS vs Shadowsocks vs VMess vs Trojan: сравнение протоколов обхода под блокировками РФ в 2026

Сравнение протоколов обхода одним взглядом

Выбор удобнее вести не по «что лучше вообще», а по трём осям, которые реально решают под ТСПУ: маскировка (на что похож трафик для DPI), скорость (накладные расходы протокола) и устойчивость к DPI — переживёт ли поток пассивный анализ и активное зондирование (active probing).

Запрос vless vs shadowsocks в 2026 решается почти механически — дальше по каждому протоколу разбираем, почему таблица такая. Общую теорию про белые списки, ТСПУ и детальную настройку XHTTP здесь не пересказываю: это отдельные материалы, тут фокус на выборе протокола.

Shadowsocks под ТСПУ: почему он сыпется первым

Shadowsocks — король простоты и латентности: минимум overhead, никакого TLS-хендшейка. За это его любят, и в спокойной зоне он реально быстрее всех. Но под российским DPI это же его и топит.

Проблема №1 — энтропийный профиль. Классический SS и AEAD-шифры дают поток, который выглядит как «полностью случайные байты без структуры». Настоящий трафик так не выглядит почти никогда: там TLS-record-заголовки (0x16 0x03), ASCII, предсказуемые размеры и тайминги пакетов. Это класс fully-encrypted protocols, и пассивная классификация таких потоков по энтропии/распределению байт давно описана и воспроизводится на реальном цензорном железе.

Проблема №2 — active probing. Цензор сам стучится в порт и по реакции сервера (ответил / молча висит / как рвёт соединение) отличает прокси от веб-сервиса.

Shadowsocks-2022 (shadowsocks-rust/sing-box, шифры 2022-blake3-aes-128-gcm, 2022-blake3-aes-256-gcm, 2022-blake3-chacha20-poly1305) закрывает пробинг и replay за счёт нового формата с ключом сессии, но не добавляет маскировки — поток всё равно не похож на HTTPS. По наблюдениям, под активными волнами блокировок SS-ноды в РФ отваливаются раньше остальных. Вывод: SS-2022 держат как быстрый fallback в относительно спокойной зоне, но не как основной протокол под ТСПУ. Если нужен именно SS с камуфляжем — его заворачивают в плагин (v2ray-plugin/shadow-tls), но тогда проще сразу взять VLESS.

VMess: почему в 2026 это легаси

VMess был ядром V2Ray и в своё время — большим шагом вперёд. Сегодня в паре vless или vmess ответ почти всегда за VLESS.

• Лишние метаданные в протоколе. VMess несёт собственный зашифрованный заголовок с командой, временной меткой и (исторически) alterId. Это дополнительная сложность и лишняя поверхность для фингерпринтинга.
• Привязка ко времени. Валидация запроса завязана на timestamp с окном ±90 секунд — рассинхрон часов клиент/сервер даёт обрывы, а сам факт временного окна теоретически даёт зацепку анализу.
• alterId в архиве. Сообщество давно на alterId=0 (VMessAEAD), старый режим выпилен из ядра. Это прямой сигнал, что протокол доживает.
• Нет нативного XTLS. Главный выигрыш VLESS — работа с XTLS/Reality и flow xtls-rprx-vision — VMess не поддерживает by design.

VMess не «сломан»: связка VMess + WebSocket + TLS + CDN ещё живёт. Но он не даёт ничего, чего не даёт VLESS, и при этом тяжелее. Держат его в 2026 в основном ради старых клиентов, не умеющих Reality. Для новой инфраструктуры выбирать VMess смысла нет.

VLESS + Reality/Vision: стандарт де-факто и как поднять

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

XTLS-Reality не просто заворачивает трафик в TLS — он заставляет сервер выдавать себя за чужой реальный сайт-донор с настоящим валидным сертификатом. Для DPI это неотличимо от честного TLS 1.3-хендшейка к популярному ресурсу; активный зонд, постучавшийся не по протоколу (без нужного shortId/ключа), просто проксируется на реальный сайт-донор и видит обычный ответ. Своего домена и сертификата не нужно — это снимает целый класс проблем Trojan.

Flow xtls-rprx-vision убирает «TLS-в-TLS» для полезной нагрузки: отсюда почти нулевой overhead и, что важнее под ТСПУ, устранение паттерна «TLS внутри TLS», по которому раньше палили обёрнутые прокси. Vision работает только по TCP.

Минимальная генерация ключей на Xray-ядре (Remnawave/Marzban/3x-ui):

xray x25519 # -> privateKey (сервер) + publicKey (клиент)
openssl rand -hex 8 # -> shortId (можно несколько, до 8 байт)
xray uuid # -> UUID клиента

Параметры inbound:

• протокол vless, flow xtls-rprx-vision, транспорт tcp + security: reality
• dest + serverNames: сторонний сайт-донор
• privateKey/shortIds из команд выше

Как выбрать dest (частая ошибка): донор должен отвечать по TLS 1.3 + HTTP/2, использовать X25519, не стоять сам за CDN/Cloudflare и не быть заблокированным в РФ. Плохой донор ломает всю маскировку. Проверка: echo | openssl s_client -connect example.com:443 -tls1_3 -alpn h2 2>/dev/null | grep -E 'Protocol|ALPN'.

Честная оговорка. Reality не всесилен. Фингерпринт клиента (uTLS) должен совпадать с заявленным браузером, иначе связка палится по ClientHello. И если РКН двинется к SNI-allowlisting (пропускать только «белые» SNI), то донорский SNI Reality тоже должен попадать в белый список — иначе хендшейк режется на SNI независимо от идеальности маскировки.

Trojan и XHTTP: когда они уместны

Trojan маскируется иначе, чем Reality: он честно поднимает HTTPS на вашем домене с валидным сертификатом (Let's Encrypt) и прикидывается обычным веб-сервером. Пришёл правильный пароль — это прокси, нет — отдаётся заглушка/реальный сайт. Плюс: трафик действительно неотличим от HTTPS к вашему сайту. Минусы под РФ существенные:

• нужен свой домен + валидный сертификат — это инфраструктура, деньги и продление;
• режется по SNI: как только домен в списках, соединение рвётся на хендшейке независимо от содержимого;
• домен «светится» целиком и может быть заблокирован разом.

Reality выигрывает тем, что прячется за чужим, «неубиваемым» SNI и не палит свой домен. Поэтому в 2026 Trojan — рабочий, но нишевый вариант: он разумен, если у вас уже есть доверенный домен под легитимный сайт с реальным трафиком.

VLESS + XHTTP — история для случая, когда нода стоит за CDN. Трафик идёт как обычные HTTP(S)-запросы к домену CDN — это лучший камуфляж на уровне транспорта, когда прямые IP уже не выживают. Практический нюанс: часть CDN (например, поверх Yandex Cloud) не пропускает POST и работает через GET — тогда обязателен явный mode (packet-up), иначе «в одном приложении работает, в другом нет». Полная настройка XHTTP вынесена в отдельный материал.

Что выбрать в 2026: гайд по сценариям

Сводим сравнение протоколов обхода в решения под конкретную ситуацию:

• Прямая нода, обычная блокировка по DPI → VLESS + Reality + Vision. Дефолт без вариантов: не нужен домен, держит active probing, быстрый.
• Максимальная скорость в спокойной зоне / резервный канал → Shadowsocks-2022. Держите как fallback, а не как основу.
• Есть доверенный домен и нужен «честный» HTTPS-камуфляж → Trojan или VLESS+TLS+домен. Готовьтесь, что домен могут заблокировать по SNI.
• Старые клиенты, не умеющие Reality → VMess+WS+TLS как совместимостный костыль, не как стратегия.
• IP ноды в дата-центре блокируют пачками / нужна устойчивость к белым спискам → VLESS + XHTTP за whitelisted-CDN.

Главное, что часто упускают: выбор протокола решает задачу DPI, но не задачу блокировки IP. Reality идеально маскирует трафик, но если провайдер режет по белым спискам и айпишник вашего сервера в дата-центре просто выпал из доступа — ни один протокол на этой ноде не поможет, до неё физически не достучаться. Устойчивость даёт не протокол, а транспорт: фронт через whitelisted-CDN, где для наблюдателя вы ходите на «белый» домен, а нода спрятана за ним. На этом уровне и работает whitelist-CDN как отдельный слой (это то, что мы делаем в Clearway). Правильная связка 2026 — VLESS как протокол плюс устойчивый транспорт, а не одно вместо другого.