VLESS+TCP+Reality в мае 2026: почему перестал работать в России и переход на gRPC

В мае 2026 года российские пользователи VPN-сервисов, работающих на VLESS+TCP+Reality с дефолтными настройками, начали массово сталкиваться с одной проблемой: соединение с сервером устанавливается (пинг проходит, тест в клиенте проходит), но при попытке реально передать трафик клиент выдаёт TLS handshake error.

Это не баг конкретного сервиса и не сбой одного хостинга. ТСПУ выкатил сигнатуру, которая детектит наивный VLESS+TCP+Reality по форме трафика, и в зависимости от региона и провайдера сейчас режет такие соединения ещё до рукопожатия Reality. В статье — что это значит технически, как понять, что у вас именно эта проблема, и два пути её решения: закалить TCP-Reality или мигрировать на gRPC/XHTTP с готовым конфигом.

Краткий контекст: что такое VLESS+TCP+Reality

VLESS — лёгкий VPN-протокол поверх ядра Xray/V2Ray. Reality — слой маскировки поверх него: когда клиент подключается, Xray на сервере «заимствует» настоящее TLS-рукопожатие у заданного в конфиге сайта-донора (dest). Снаружи (для DPI) это выглядит как обычный HTTPS-трафик к легитимному сайту с настоящим сертификатом.

Транспорт tcp — самый простой: VLESS-пакеты идут прямо поверх TCP. Альтернативы — grpc (поверх HTTP/2), xhttp(HTTP/2 с дополнительной нормализацией заголовков), ws (WebSocket).

Связка VLESS+TCP+Reality несколько лет считалась золотым стандартом обхода: маскируется под TLS, переживает активное зондирование DPI, не палится самосгенерированным сертификатом, низкий overhead. Именно её ставят по умолчанию в большинстве туториалов и панелей (Marzban, X-UI, Hiddify).

Что изменилось в мае 2026

ТСПУ давно умеет смотреть не только на сертификаты и SNI, но и на форму трафика — характерные размеры первых пакетов после рукопожатия, тайминги между ними, ритм запрос-ответ. У голого VLESS+TCP без флоу xtls-rprx-vision и без паддинга есть узнаваемый «отпечаток» — паттерн, по которому можно отличить его от настоящего HTTPS даже без расшифровки.

Технически это работает так: на зеркальных бэкбонах магистральных провайдеров собирается выборка трафика, размечается («вот это VLESS+TCP+Reality, вот это обычный HTTPS»), обучается ML-классификатор. На выходе — сигнатура, которая с приемлемой точностью отличает один от другого даже на зашифрованном трафике. В мае 2026 такая сигнатура для голого VLESS+TCP+Reality пошла в продакшен ТСПУ.

Симптомы — как понять, что это именно ваш случай

Конкретные признаки того, что вы попали под детект по форме трафика:

• VPN перестал работать «вдруг», без изменений на сервере
• Сервер пингуется, проверка соединения в клиенте проходит
• При реальной попытке передачи трафика — TLS handshake error(в Happ, V2RayNG, Streisand, NekoBox — везде одинаково)
• На стационарном интернете (Ростелеком, Дом.ру, МГТС, Билайн-домашний) лежит, на мобильном LTE того же оператора работает (либо наоборот — по региону)
• Логи Xray на сервере пустые в момент попытки подключения — это значит, трафик режется до того, как пакеты долетят до сервера

Если совпадает 3-4 пункта из списка — почти наверняка детект по форме трафика. Это не уникальная история одного сервиса, а массовое явление, фиксируемое десятками VPN-провайдеров в РФ в течение мая 2026.

Региональный выкат сигнатур

Один из неприятных моментов работы с ТСПУ: сигнатуры катятся неравномерно по провайдерам и регионам. Пользователь у Ростелекома в Москве жалуется, что не работает; пользователь у того же Ростелекома в Новосибирске спокойно сидит в VPN. Через неделю расклад может измениться.

Поэтому если вы администратор сервиса и сами не видите проблемы — это не значит, что её нет. Это значит, что до вашего провайдера в момент тестирования сигнатура ещё не доехала.

Что НЕ помогает

Прежде чем переходить к рабочим решениям — типовые тупиковые ходы, на которые легко потратить часы:

Смена IP сервера

Если бы блокировали IP, перенос сервиса на новый адрес помог бы. В случае детекта по форме трафика — нет. На новом IP ТСПУ увидит тот же отпечаток и так же его срежет. Смена IP осмысленна только при комплексной блокировке (форма трафика и чёрный список IP) или если конкретный IP попал в чёрный список отдельно.

Смена SNI и dest

serverNames и dest влияют на то, под какой сайт маскируется TLS-рукопожатие. Но раз сама форма трафика после рукопожатия выдаёт VLESS — перебор десятка SNI ничего не даст. Все будут падать одинаково.

Смена fingerprint клиента

Fingerprint (chrome, firefox, safari) отвечает за то, как клиентский ClientHello выглядит снаружи — JA3/JA4 отпечаток. Если детект идёт на ClientHello, fingerprint критически важен. Но если детект происходит позже, по форме потока трафика, fingerprint только улучшает маскировку первого шага, проблему целиком не решает. Тем не менее, fingerprint: chromeставить всё равно надо — без него ClientHello выглядит как у голого Go-клиента, и это палится в первую очередь.

Ротация криптографических ключей

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

Что помогает: два пути

Путь 1: Закалить VLESS+TCP+Reality

Сам TCP-транспорт не умер — умер дефолтный конфиг без защитных мер. Чтобы продлить жизнь TCP+Reality:

• Флоу xtls-rprx-vision — обязательно. Добавляет случайный паддинг и сбивает паттерн размеров пакетов. Без vision голый VLESS+TCP палится с высокой вероятностью.
• Редкие SNI-доноры — вместо популярных в туториалах сайтов (yahoo.com, amd.com) выбрать менее палевные домены, под которые не маскируется половина рунета.
• Ротация параметров по нодам — однообразные конфиги на всех серверах = одна сигнатура валит всё разом. Разные SNI, разные порты, разные shortIds по разным нодам.

Это лечит большинство случаев, но не на 100%. ML-классификатор со временем дообучается, и закалённые конфиги тоже могут попасть под детект — просто позже. Закаливание — стратегия отсрочки, не финального решения.

Путь 2: Сменить транспорт

Более радикальное решение — поменять сам транспорт. Reality как маскировочный слой остаётся, меняется только то, что внутри:

• VLESS+gRPC+Reality — HTTP/2 + grpc-фреймы, форма трафика принципиально другая, под текущую сигнатуру на TCP-VLESS не попадает. Самый распространённый и поддерживаемый клиентами вариант.
• VLESS+XHTTP+Reality — самый свежий транспорт, с дополнительной нормализацией заголовков HTTP/2. Поддерживается новыми версиями клиентов.
• Hysteria2 — вообще другой протокол поверх UDP. Под сигнатуры для TCP-VLESS не попадает в принципе, плюс отдельная плоскость детекции (UDP против TCP). Хорошо как резервный транспорт.

Пошаговая миграция на VLESS+gRPC+Reality

Предполагается Marzban + Xray. Для других панелей принцип тот же — отличаются только пути к конфигу.

Шаг 1. Добавить новый инбаунд

В /var/lib/marzban/xray_config.json, в массив inbounds:

{
  "tag": "vless_grpc_reality",
  "listen": "0.0.0.0",
  "port": 8447,
  "protocol": "vless",
  "settings": {
    "clients": [],
    "decryption": "none"
  },
  "streamSettings": {
    "network": "grpc",
    "security": "reality",
    "grpcSettings": {
      "serviceName": "grpc",
      "multiMode": false
    },
    "realitySettings": {
      "dest": "www.amd.com:443",
      "xver": 0,
      "serverNames": ["www.amd.com"],
      "privateKey": "ВАШ_PRIVATE_KEY",
      "shortIds": ["", "1a2b3c4d"]
    }
  },
  "sniffing": {
    "enabled": true,
    "destOverride": ["http", "tls", "quic"]
  }
}

Ключевые отличия от TCP-варианта:

• network: "grpc" вместо "tcp"
• grpcSettings.serviceName — путь, должен дословно совпадать с клиентским
• dest обязан поддерживать HTTP/2 (gRPC ходит поверх HTTP/2). Проверить: curl -sI --http2 https://www.amd.com -o /dev/null -w '%{http_version}\n' — должно вернуть 2

Шаг 2. Сгенерировать свежий keypair

Базовая гигиена — на новый инбаунд новые ключи. Для Marzban в Docker:

sudo docker exec -it marzban-marzban-1 xray x25519

Private key вставить в инбаунд, Public key — в настройки хоста в панели на следующем шаге.

Шаг 3. Перезапустить и добавить хост

sudo marzban restart

В панели Marzban: Host Settings → Add, привязать к инбаунду vless_grpc_reality. Поля:

• Address — IP или домен сервера
• Port — 8447 (или тот, что указали в инбаунде)
• SNI — www.amd.com
• Path — grpc (это и есть serviceName из инбаунда)
• Fingerprint — chrome
• ALPN — h2
• Public Key / Short ID — свежие, из шага 2

Шаг 4. Открыть порт на firewall

sudo ufw allow 8447/tcp

После этого пользователи обновляют подписку — и автоматически получают новый конфиг с gRPC-транспортом.

Критические моменты, где ломаются

• Flow для gRPC должен быть пустым. xtls-rprx-vision работает только с TCP. Если у пользователя в настройках Marzban стоит flow xtls-rprx-vision, на gRPC-инбаунде он не подключится.
• serviceName на сервере (в JSON) и Path в Marzban-хосте должны совпадать дословно.
• multiMode на сервере и клиенте должны совпадать. Безопаснее оставить false — старые клиенты могут не поддерживать true.
• Порт 443 для gRPC идеален с точки зрения маскировки, но если его уже занимает nginx (или другой web-сервер), берите 8443/8447/2087 — gRPC функционально работает на любом порту, маскировки чуть меньше, но проблема конфликта серьёзнее.

Архитектурные выводы для админов

Главный вывод: не делать ставку на один транспорт. Сервисы с единственным инбаундом VLESS+TCP+Reality в мае 2026 потеряли часть пользователей разом; сервисы с диверсифицированной инфраструктурой пережили волну с минимальными потерями.

Микс-транспорты в подписке с авто-фейловером

В подписке каждого пользователя должно быть несколько конфигов разных типов:

• 2× VLESS+gRPC+Reality (на разных нодах, разные SNI)
• 1× VLESS+TCP+Reality с vision-флоу и паддингом (для разнообразия)
• 1× Hysteria2 (UDP — другая плоскость детекции)

Современные клиенты (Happ, V2RayNG, Streisand) умеют URL-test и автоматически переключаются на работающий конфиг. Когда прилетает волна на один транспорт — клиент молча уходит на другой, пользователь даже не замечает.

Вариативность по нодам

Одинаковые дефолтные настройки на всех серверах — главный системный риск. Если все ваши ноды используют один SNI-донор, один порт, один shortId, одну версию ядра Xray — одна сигнатура валит все ноды сразу. Лечится только вариативностью.

Мониторинг изнутри РФ

Узнать о блокировке от потока жалоб — это всегда поздно. Регулярные проверки доступности нод из 3-4 точек внутри РФ (разные регионы и провайдеры) дают сигнал за десятки минут до того, как первый пользователь напишет в поддержку. Минимум — cron-скрипт с попыткой реального HTTPS-запроса через VPN.

Разделение control plane и data plane

Сервер с панелью + БД не должен одновременно проксировать пользовательский трафик. Панель остаётся изолированной (никаких публичных VPN-инбаундов на её IP), ноды — расходники: попали под блокировку — заменили за минуты, не теряя при этом доступа к управлению.

Что делать пользователю, если VPN перестал работать

1. Обновите подписку. В Happ — кнопка «Обновить подписку», в V2RayNG — Update Subscription. Если ваш сервис уже добавил gRPC-конфиги, после обновления VPN заработает автоматически.
2. Попробуйте мобильный интернет. Если на 4G/5G работает, а на домашнем нет — это блокировка у конкретного провайдера, не у вас.
3. Если не работает после обновления подписки — пишите в поддержку сервиса. Технически на стороне сервиса нужно либо добавить gRPC/XHTTP инбаунды, либо закалить существующие TCP-инбаунды через vision-флоу. Если в ответ говорят «у нас всё работает, это у вас проблема» — это плохой ответ, имейте в виду.

Часто задаваемые вопросы

Почему перестал работать VLESS+TCP+Reality в России в мае 2026?

ТСПУ выкатил сигнатуру, которая детектит VLESS+TCP+Reality с дефолтными настройками по форме трафика — характерным размерам первых пакетов и таймингам между ними. Сигнатура распространяется неравномерно по провайдерам, поэтому соединение падает у части пользователей и продолжает работать у других.

Что значит ошибка TLS handshake error в Happ / V2RayNG?

При работающем пинге это означает, что TCP-соединение до сервера установилось, но рукопожатие Reality не прошло. В мае 2026 основная причина у российских пользователей одна — ТСПУ режет рукопожатие на уровне DPI до того, как пакеты долетят до Xray.

Заблокировали ли VLESS как протокол целиком?

Нет. Заблокирована конкретно дефолтная конфигурация VLESS+TCP+Reality без флоу vision и без паддинга. Закалённый TCP-Reality продолжает работать. Альтернативные транспорты — VLESS+gRPC+Reality, VLESS+XHTTP+Reality, Hysteria2 — работают полностью.

Помогает ли смена IP сервера?

Нет, если детект по сигнатуре трафика. На новом IP ТСПУ увидит тот же отпечаток и так же его срежет. Смена IP осмысленна только при поэтапной блокировке самих адресов — это другой сценарий.

Помогает ли смена SNI или dest в Reality?

Нет. SNI и dest влияют на TLS-рукопожатие, но не на форму трафика после него. Перебор десятка SNI ничего не даст — все будут детектиться одинаково.

Это конец эпохи VLESS Reality?

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

Итог

VLESS+TCP+Reality в России в мае 2026 — не умер, но перестал быть инвариантом «настроил и забыл». ТСПУ научился детектить наивную конфигурацию по форме трафика, и этот навык будет только улучшаться. Жить долго будут сервисы с диверсифицированной инфраструктурой: несколько транспортов, несколько хостингов, вариативность параметров, мониторинг.

Для пользователя практический критерий: выбирайте сервис, у которого в подписке несколько разных транспортов с автоматическим переключением. Это не маркетинговая фишка — это базовая инженерная практика для VPN в 2026 году. В TrayVPN подписка по умолчанию включает VLESS+gRPC+Reality, VLESS+TCP+Reality с vision-флоу и Hysteria2 на разных нодах с авто-фейловером в клиенте.

Послесловие про сигнатуры

Точную сигнатуру, по которой ТСПУ ловит VLESS, публично не знает никто — Роскомнадзор её не публикует, и она меняется. Всё, что есть — эмпирические наблюдения «что валится» и «что чинит», плюс реверс-инжиниринг профильных исследователей на форумах NTC и в чатах AmneziaVPN.

Если кто-то говорит «я точно знаю, как ТСПУ детектит VLESS» — это либо инсайдер (что маловероятно), либо продавец инфоцыганщины (что вероятнее). Реальная защита — не «знать сигнатуру», а строить инфраструктуру так, чтобы ни одна сигнатура не уносила всё разом.