AmneziaWG 3.0 или VLESS Reality: что выбрать для сети

AmneziaWG создаёт интерфейс уровня IP и наследует модель cryptokey routing WireGuard. Приложение отправляет зашифрованные IP-пакеты поверх UDP. Параметры H1–H4 меняют идентификаторы типов пакетов, S1–S4 добавляют случайные префиксы, I1–I5 задают сигнатурные пакеты перед handshake, а Jc, Jmin и Jmax управляют дополнительными случайными пакетами. Криптографические операции остаются в модели WireGuard.

Такая архитектура удобна, когда устройству нужен полноценный туннель: приложения видят обычный сетевой интерфейс, а маршруты задаются AllowedIPs и системной таблицей. Она также означает зависимость от UDP. Сеть может ограничить конкретный порт, весь неизвестный UDP или продолжительные UDP-потоки. Маскировка пакета не превращает транспорт в TCP или TLS.

Для версии 3.0 нужен новый профиль и совместимый клиент. AmneziaVPN до 4.8.12.9 не поддерживает новый формат. Команда эксплуатации должна уметь проверить endpoint, firewall, NAT, MTU, handshake и соответствие параметров на клиенте и сервере.

VLESS служит протоколом аутентификации и передачи в Xray-core, а REALITY относится к транспортному TLS-слою. Официальная документация Project X описывает server-side параметры target, serverNames, privateKey, shortIds и ограничения uTLS. Сервер принимает валидный REALITY-запрос по настроенным именам и ключам. Трафик, который не проходит аутентификацию, может перенаправляться к target; документация отдельно предупреждает о риске злоупотребления таким fallback и предлагает фильтрацию или лимиты.

VLESS может работать с несколькими транспортными схемами, поэтому слово VLESS само по себе не сообщает, используется ли TCP, XHTTP или другой режим. Сравнение должно называть полную связку, например VLESS + TCP + XTLS Vision + REALITY. Иначе два тестировщика могут измерять разные системы под одним названием.

REALITY зависит от корректного target и SNI-параметров. Ошибка serverName, ключа, shortId, времени или версии Xray приводит к сбою рукопожатия. Зато среда, где разрешён обычный TCP 443, может относиться к этой схеме иначе, чем к UDP-туннелю.

Для AmneziaWG наблюдатель видит UDP-поток. H-, S-, I- и J-параметры меняют начало, размеры и служебную последовательность пакетов. Официальная документация говорит о возможности имитировать признаки распространённых UDP-протоколов, включая DNS и QUIC. Она не заявляет, что весь последующий поток становится точной копией выбранного протокола.

Для VLESS Reality наблюдатель видит TCP-соединение и рукопожатие, которое REALITY строит с использованием uTLS и настроенного target. Дальнейшие признаки зависят от flow и транспорта. Адрес сервера, частота соединений и объём данных остаются доступными сетевому оператору в обеих архитектурах.

Система DPI может принимать решения по сигнатуре, метаданным, списку адресов или активной проверке. Поэтому обход блокировок VLESS Reality и AmneziaWG проверяют отдельно у каждого оператора. Фраза «не распознаётся» требует протокола эксперимента и даты; без них она превращается в неподтверждённое обещание.

Сравнивать скорость по чужим числам нельзя. AmneziaWG зависит от реализации клиента и сервера, процессора, MTU и качества UDP-маршрута. VLESS Reality зависит от Xray, выбранного flow, TCP-маршрута, congestion control и параметров транспорта. Расстояние до сервера и нагрузка часто перекрывают разницу протоколов.

UDP не выполняет повторную передачу на транспортном уровне туннеля; вложенные TCP-сессии сами восстанавливают потерянные сегменты. TCP-транспорт VLESS подчиняется управлению перегрузкой внешнего TCP. При потерях результат меняется, а сравнение одной загрузки не отделяет протокол от маршрута.

Нужен парный тест на одном сервере или в одном дата-центре, с одинаковым маршрутом, временем и лимитом CPU. Измеряют не только Mbps, но и p50/p95 задержки, потери, время подключения, стабильность длинной сессии и повтор после смены сети. Результат применим к испытанным условиям, а не ко всем пользователям.

AmneziaWG подходит для системного IP-туннеля и нативных конфигураций. Пользователь импортирует файл в AmneziaVPN или совместимый AmneziaWG-клиент. Версия 3.0 требует нового профиля. Администратор управляет ключами пиров, маршрутами, NAT и UDP-портом. Отдельная конфигурация на устройство упрощает отзыв доступа.

VLESS Reality используют клиенты, совместимые с Xray-core и конкретным flow. Профиль содержит UUID, адрес, порт, параметры REALITY и транспорта. Режим TUN зависит от клиента; некоторые приложения начинают с системного proxy. Поддержка одной и той же ссылки может различаться между версиями клиентов.

Эксплуатационная сложность зависит от опыта команды. Ошибка в H-диапазонах AWG и ошибка target/serverName в REALITY одинаково превращают рабочую идею в нерабочий сервис. Перед массовой выдачей профилей нужны валидатор конфигурации, smoke-тест и журнал версий.

Если целевая сеть пропускает UDP, нужен системный туннель и поддерживаемый Amnezia-клиент, AmneziaWG 3.0 становится обоснованным кандидатом. Если UDP ограничен, но TCP 443 доступен, команда может протестировать VLESS Reality. Это условия для теста, а не гарантия результата.

Для ответа на вопрос «какой протокол VPN лучше 2026» заполните матрицу: целевые операторы, доступность UDP, поддерживаемые ОС, режим TUN, стоимость диагностики, ротация ключей, наблюдаемость и резервный транспорт. Проведите одинаковый набор проверок в каждой сети. Зафиксируйте версию AmneziaVPN, Xray-core и клиента VLESS.

Источники для проверки: https://docs.amnezia.org/documentation/amnezia-wg/, https://docs.amnezia.org/documentation/instructions/new-amneziawg-selfhosted/, https://www.wireguard.com/protocol/, https://xtls.github.io/en/config/transports/reality.html и https://github.com/XTLS/Xray-core. Рабочая схема должна включать резервный профиль другого класса, поскольку оператор может изменить фильтрацию после публикации статьи.

Добавьте в матрицу модель распространения профилей. Для AWG важно выпускать отдельный peer на устройство, фиксировать версию формата и отзывать утёкший ключ. Для VLESS нужно отслеживать UUID, shortId, параметры flow и совместимость URI с клиентом. Массовая замена одной строки без проверки создаёт разные ошибки: AWG может не согласовать handshake, а Xray может отклонить REALITY-аутентификацию.

Наблюдаемость тоже различается. WireGuard-подобный сервер показывает время последнего handshake и счётчики peer, но не объясняет пользовательский DNS после туннеля. Xray пишет события своего протокольного слоя, однако полнота лога зависит от конфигурации и уровня verbosity. Сформируйте общий журнал без секретов: идентификатор профиля, версия, endpoint, сеть, этап и код ошибки.

Наконец, проверьте поведение после сна устройства, смены Wi-Fi на LTE и истечения NAT-состояния. Такие сценарии влияют на практический выбор сильнее короткого speed test. Решение можно считать принятым после повторяемого подключения, работы маршрутов и документированного rollback, а не после одного успешного открытия сайта. Зафиксируйте владельца каждого компонента: клиент, сервер, DNS и канал поддержки. Это сокращает передачу инцидента между командами и сохраняет единый набор фактов. Пересматривайте матрицу после изменения транспорта, клиента или политики целевого оператора.