VLESS vs WireGuard
WireGuard, вероятно, лучший VPN-протокол, когда-либо спроектированный для неограниченных сетей. VLESS Reality, вероятно, лучший протокол для сетей, где кто-то активно пытается тебя остановить. Это разные задачи, и протоколы, решающие их, не похожи.
Большинство сравнительных статей выбирают победителя. Не будем, потому что ответ зависит от того, где ты, и как выглядит сеть между тобой и сервером. Поставляем оба в Fexyn и автопереключаем между ними по этой причине. (Для общего обзора что такое VPN-протокол — начни там.)
Вот что реально важно при выборе.
WireGuard: почему стал дефолтом
WireGuard заслужил репутацию. Весь протокол — примерно 4000 строк kernel-кода. Для сравнения: OpenVPN — 100000+ строк. Реализации IPsec ещё длиннее. Меньшая кодовая база значит меньше мест для багов, что огромно важно для security-критичного ПО.
Криптографические выборы opinionated и фиксированы: ChaCha20-Poly1305 для симметричного шифрования, Curve25519 для обмена ключами, BLAKE2s для хеширования. Нет переговоров шифров, нет конфигурационной матрицы, нет меню «выбери любимый алгоритм». Это намеренное решение Jason Donenfeld, и оно устраняет целый класс downgrade-атак, мучающих протоколы с конфигурируемыми шифр-сюитами.
Производительность следует из архитектуры. WireGuard работает на уровне ядра (или userspace через boringtun), обрабатывая пакеты с минимальным переключением контекста. UDP-транспорт полностью избегает проблемы head-of-line блокировки TCP. На 500 Mbps оптике WireGuard стабильно даёт около 480 Mbps в наших тестах. Это 96% baseline пропускной. Едва платишь за шифрование.
Установка соединения тоже быстрая. Handshake WireGuard — один round trip: инициатор шлёт зашифрованное сообщение, респондер шлёт одно в ответ, и туннель живёт. В реализации Fexyn на Windows полная последовательность подключения от «пользователь нажимает Connect» до «трафик через туннель» в среднем 611 мс. Большая часть времени — настройка TUN-адаптера и конфиг маршрутов, не ожидание протокола.
Для большинства пользователей на большинстве сетей WireGuard — правильный выбор. Быстр, прост, имеет годы production-закалки на Linux, Windows, macOS, iOS, Android.
Проблема 148 байт
У WireGuard есть слабость, которую никакая хитрая инженерия не пофиксит, потому что она прямое следствие философии дизайна.
Каждое сообщение инициации handshake WireGuard ровно 148 байт. Первый байт — 0x01 (тип сообщения 1: handshake initiation). Следующие три — 0x00 0x00 0x00 (зарезервированные нули). Дальше 4-байтовый sender index и 32-байтовый незашифрованный эфемерный Curve25519 публичный ключ.
Эта структура не варьируется. Не может; спецификация протокола требует.
DPI-системы это эксплуатируют. Логика детекта стыдно проста. Вот что nDPI, open-source DPI-библиотека, реально проверяет:
if (message_type == 1 && packet_length == 148)
→ классифицировать как WireGuard
Всё. Один conditional. 148-байтовый handshake с ведущим 0x01 0x00 0x00 0x00 — уникальный фингерпринт, который не производит ни один другой протокол. Не нужно machine learning или статистического анализа. Первокурсник по сетям написал бы этот фильтр.
ТСПУ России блокирует WireGuard с почти 100% точностью с середины 2024. Не троттлит, не деградирует. Блокирует. UDP-пакеты, несущие handshakes WireGuard, просто исчезают. GFW Китая делает то же. Иран блокирует. Любое правительство с современным DPI-железом может добавить WireGuard в blocklist за полдня.
Проект WireGuard в курсе. Это не баг. Протокол спроектирован для скорости и простоты, не для скрытности. Сделать handshake переменной длины или добавить паддинг усложнит протокол и нарушит ключевой принцип минимальной сложности. Это разумные tradeoffs для модели угроз WireGuard. Просто значат, что WireGuard — неправильный инструмент, если ты на сети, где кто-то активно инспектирует трафик.
AmneziaWG: частичный фикс
AmneziaWG 2.0 пытается адресовать проблему фингерпринтинга, добавляя случайный паддинг к WireGuard-пакетам, используя динамические заголовки и вставляя junk-пакеты. Делает детект сложнее. Но всё ещё работает в UDP-рамках WireGuard, и цензоры могут применять статистический анализ к распределению размеров, интервалам таймингов и энтропии. UDP-трафик, не совпадающий с известным протоколом, подозрителен по умолчанию в сильно цензурированных средах.
AmneziaWG — шаг вперёд. Не решение фундаментальной проблемы.
VLESS Reality: прятаться на виду
VLESS берёт противоположный подход к WireGuard почти во всём. Где WireGuard — purpose-built VPN-протокол с уникальным wire format, VLESS — proxy-протокол, делегирующий шифрование TLS 1.3 целиком. VLESS-заголовок добавляет 25–50 байт оверхеда, содержа байт версии, UUID для аутентификации и информацию маршрутизации.
Протокол имеет смысл только внутри TLS-соединения. Сними TLS, и у VLESS нет шифрования, целостности, ничего. Эта зависимость от TLS часто критикуется как слабость. Реально это источник величайшей силы VLESS.
VLESS Reality с Vision flow расширяет базовый протокол системой камуфляжа, делающей соединение по-настоящему неотличимым от нормального HTTPS-трафика. Когда подключаешься к серверу Fexyn, используя Reality+Vision, сервер делает настоящий TLS-handshake с реальным сайтом вроде www.microsoft.com и форвардит легитимный сертификат сайта клиенту. Клиент использует библиотеку uTLS, чтобы произвести ClientHello, байт-в-байт идентичный тому, что отправили бы Chrome или Firefox.
Если цензор зондирует сервер, форвардятся к настоящему microsoft.com. Настоящий сертификат. Настоящий контент. Настоящие HTTP-заголовки. Нет симуляции. Сервер функционирует как прозрачный reverse proxy для неаутентифицированных соединений и как VLESS-туннель для аутентифицированных.
Результат: ни одна пассивная DPI не может отличить VLESS Reality сессию от того, как кто-то браузит сайт Microsoft. Активное зондирование тоже проваливается, потому что проба получает настоящие ответы от настоящего сайта. Детект потребовал бы от цензора как-то различить «пользователя, посещающего microsoft.com» и «Reality-сервер, проксирующий к microsoft.com», что с сетевой перспективы — одно и то же.
Это работает в России. Работает в Китае. Работает в Иране. Не теоретически. Прямо сейчас, в production, для реальных пользователей.
Что VLESS отдаёт
VLESS Reality не бесплатен. Меняешь вещи, чтобы получить эту невидимость.
Главная цена — TCP. VLESS работает поверх TCP (через TLS), что значит наследует head-of-line блокировку TCP. Если один пакет потерян, каждый следующий в потоке ждёт ретрансмиссии. WireGuard избегает, работая на UDP. На сетях с потерями (перегруженный Wi-Fi или мобильные с плохим покрытием) разница измерима. VLESS также только TCP, точка. XHTTP (новая опция транспорта в XRay-core) добавляет мультиплексирование, но не меняет базовое TCP-ограничение. Для гейминга или real-time голоса, где задержка важнее надёжности, UDP-транспорт WireGuard подходит лучше.
Путь подключения сложнее. Сессия VLESS Reality включает TLS 1.3 handshake (1-RTT или 0-RTT), переговоры VLESS-протокола и потенциально настройку TUN-адаптера с tun2socks-маршрутизацией. Больше движущихся частей, чем у однораундового handshake WireGuard. На стороне сервера Reality поддерживает TLS-соединение с камуфляж-назначением и управляет proxy-логикой для неаутентифицированных. Это стоит больше памяти и CPU на клиента, чем kernel-space обработка пакетов WireGuard. На масштабе разница накапливается для серверных операторов.
Потом аудитируемость. 4000 строк WireGuard формально верифицированы и широко аудированы. XRay-core — крупная Go-кодовая база со значительно большей поверхностью. Базовый VLESS-протокол прост, но окружающая реализация (Reality, uTLS-фингерпринтинг, множество транспортных режимов) не получала того же уровня независимого security-обзора.
Это реальные расходы. Приемлемы, когда альтернатива — заблокированное соединение. Не расходы, которые стоит платить, когда не надо.
Голова к голове: цифры производительности Fexyn
Тестировали оба протокола на одном железе, одном сервере, одних сетевых условиях. Windows 11, 500 Mbps оптика, подключение к серверу Frankfurt. Эти числа из автоматизированных бенчмарков, не cherry-picked.
| Метрика | WireGuard | VLESS Reality |
|---|---|---|
| Время cold-подключения | ~611 мс | ~627 мс |
| Время warm-реконнекта | N/A | ~42 мс |
| Время дисконнекта | ~108 мс | ~100 мс |
| Пропускная (500 Mbps baseline) | ~480 Mbps (96%) | Ниже (TCP-оверхед) |
| Транспорт | UDP | TCP (TLS 1.3) |
| Раунды handshake | 1 round trip | 1-RTT TLS + VLESS-заголовок |
| Детектируется DPI | Да, тривиально | Нет, с Reality |
| Оверхед протокола на пакет | ~32 байта (Poly1305 tag + counter) | 25–50 байт (VLESS) + TLS-запись |
Времена подключения ближе, чем большинство ожидает. 16-миллисекундная разница между 611 мс и 627 мс для cold-подключения — то, что пользователь не воспримет. Большая часть времени в обоих случаях — настройка адаптера, конфиг маршрутов и верификация, не задержка протокола.
У VLESS интересное преимущество на warm-реконнектах. Поскольку XRay-core можно держать запущенным как persistent-процесс между подключениями, реконнект (смена сервера или восстановление после смены сети) требует только переустановки TLS-сессии. Это около 42 мс в наших тестах. WireGuard-реконнекты тоже быстрые, но полный цикл teardown и пересоздания адаптера в нашей Windows-реализации не имеет той же warm-path оптимизации.
Где WireGuard явно вырывается — пропускная. UDP-транспорт с kernel-level (или high-performance userspace) обработкой пакетов даёт WireGuard измеримое преимущество, особенно на high-bandwidth подключениях. Разрыв расширяется на сетях с потерями, где TCP-ретрансмиссия добавляет всплески задержки.
Когда что использовать
Это проще, чем остаток статьи мог бы намекнуть.
Используй WireGuard, если ты на сети, где VPN-трафик не блокируется и не троттлится. Домашний интернет в большинстве западных стран, офисные сети, разрешающие VPN, мобильные сети в странах без активной цензуры. WireGuard даёт лучшую пропускную, низшую задержку и простейшую модель подключения. Правильный дефолт.
Используй VLESS Reality, если ты на сети, блокирующей или деградирующей VPN-протоколы. Университетские сети, блокирующие WireGuard. Корпоративные файрволы, разрешающие только HTTPS на 443. Публичный Wi-Fi с DPI-ограничениями. И, очевидно, везде в России, Китае, Иране или других странах с активной цензурой. VLESS Reality — единственный production-протокол, надёжно проходящий через всё это в наших тестах.
Используй автоматическую ротацию, если путешествуешь между средами или не уверен, что разрешает сеть. Это дефолтный режим Fexyn: пробуй WireGuard сначала за скоростью, fallback на VLESS Reality, если WireGuard падает, потом fallback на OpenVPN последним резервом. Переключение происходит автоматически без потери защиты kill switch.
Почему Fexyn поставляет оба
Большинство VPN-провайдеров поставляют один протокол и, может, OpenVPN как legacy-fallback. NordLynx у NordVPN — WireGuard с NAT-слоем. Lightway у ExpressVPN — кастомный протокол, всё ещё детектируемый DPI. Никто из крупных западных VPN-провайдеров не поставляет VLESS Reality, потому что он из экосистемы XRay/V2Ray, в основном китайскоязычной и требующей глубокого знакомства с кодовой базой без формальной спецификации.
Считаем, что VPN должен работать везде. На домашнем Wi-Fi, где никто не блокирует — да. Также на отельной сети в Москве с ТСПУ. На университетском кампусе, разрешающем только HTTPS. На Wi-Fi кафе, блокирующем UDP полностью.
Это требует множественных протоколов с разными свойствами. WireGuard за скорость, когда ничего не мешает. VLESS Reality за невидимость, когда мешает. OpenVPN для редких сетей, где ни один не работает, но legacy TLS-based VPN-трафик всё ещё разрешён.
Движок ротации Fexyn пробует их по очереди в зависимости от настройки режима подключения. «Speed first» начинает с WireGuard. «Stealth first» начинает с VLESS Reality. В любом случае ты подключён. Выбор протокола автоматический, kill switch остаётся активным во время ротации, и пользователю не надо понимать ни одну из разниц, описанных в этой статье.
Им просто нужно, чтобы интернет работал. Даже когда кто-то старается, чтобы не работал.
Можно попробовать оба протокола сегодня с подпиской Fexyn.