VLESS
Проблема касается только клиентов с uTLS-fingerprint = chrome. Firefox, Edge, Safari, Random — работают нормально. Хронология:
- Июль 2025 — первые жалобы на Chrome-fp в v2rayNG (Xray issue #4852)
- 17 февраля 2026 — первая массовая волна на проводных операторах (Dom.ru, Skynet, Ростелеком). Паттерн: первые ~16 KB проходят, дальше заморозка. SSH и обычный трафик — живые (Habr 1000694)
- Март 2026 — волна расширилась, часть пользователей полностью потеряли VLESS
- 25 мая 2026 — DPI-блокировка VLESS в Сибири и Москве (Techora)
- Начало июня 2026 — правило пришло и на мобильных провайдеров (Билайн/МТС/Мегафон). Именно тогда почти у всех отлетел Chrome-fp (Habr 1047442, anti-malware.ru 08.06.2026)
Что делает ТСПУ (по данным ресёрчей hyperion_cs, XTLS issue #6293):
- Смотрит на клиентский JA4/JA3-отпечаток TLS ClientHello
- Массовое правило нацелено на устаревший Chrome-fp из uTLS (то же что бьёт по MTProto-прокси Телеги)
- Дополнительно оценивает AS/подсеть сервера + поведение трафика первых 15-20 пакетов
- Если fp «chrome» + подозрительная подсеть + поведенческий паттерн — заморозка
Простой фикс — сменить uTLS-fingerprint в конфиге:
"realitySettings": {
...
"fingerprint": "firefox" // было "chrome" — заменить
}firefox, edge, random, randomized, safari, ios. Про эту массовую блокировку никак не касаются Firefox-fp (лучший вариант для 3x-ui/v2rayN на данный момент).
Другие меры, если смена fp не помогла (мобильные региональные случаи):
Что это
VLESS (V-Less) — современный прокси-протокол от Project X (команда Xray). Название означает «V-Less» — то есть без встроенного шифрования (в отличие от предшественника VMess). Идея: пусть шифрованием занимается транспорт (TLS / Reality), а протокол будет максимально простым.
Отличия от VMess
| VMess | VLESS | |
|---|---|---|
| Шифрование в протоколе | да (AES-CFB/128-GCM) | нет (полагается на TLS) |
| Overhead | больше | минимальный |
| Аутентификация | UUID + Alter ID | UUID |
| Timestamp | требуется (±30 сек) | не нужен |
| Flow control | нет | XTLS-Vision |
| Статус | полу-legacy | актуально |
Аутентификация
Всё, что нужно клиенту — UUID из конфига сервера. Пример:
{
"id": "b831381d-6324-4d53-ad4f-8cda48b30811",
"encryption": "none",
"flow": "xtls-rprx-vision"
}XTLS-Vision
Специальный flow-механизм для VLESS. Позволяет:
- Прокидывать TLS-фреймы напрямую («inner TLS» без двойного шифрования)
- Скрывать сигнатуру прокси-трафика от ТСПУ
- Даёт скорость близкую к нативному TCP
Работает только в связке с Reality или классическим TLS-сертификатом. С другими транспортами (WebSocket, gRPC) — не используется.
Транспорты для VLESS
VLESS работает поверх многих транспортов, каждый со своими плюсами:
- TCP + Reality — топ на 2025-2026, невидим для ТСПУ
- TCP + TLS + XTLS-Vision — на своём домене с валидным сертификатом
- WebSocket + TLS — прокидка через CDN (Cloudflare)
- gRPC + TLS — хорошо на нестабильных сетях
- xHTTP — новый транспорт Project X (2024)
- HTTPUpgrade — как WebSocket, но без WS-фрейминга
- mKCP — UDP-транспорт, для плохих сетей
В РФ
С Reality — практически незаметен для ТСПУ, работает свободно. Без Reality (на голом TLS) — может ловиться по behavioral-анализу, но в целом жив. VLESS — сейчас (2026) «золотой стандарт» для обхода блокировок.