Сколько трафика расходует VLESS и увеличивает ли VPN расход интернета

Сколько трафика расходует VLESS и будет ли мобильный оператор списывать больше гигабайт при включённом VPN?

Короткий ответ:

VLESS действительно создаёт дополнительный служебный трафик, но обычно не удваивает расход интернета.

Если приложение скачало условные 10 ГБ видео, через сеть будет передано немного больше 10 ГБ, потому что кроме самих данных существуют:

• IP-заголовки;
• TCP или UDP;
• VLESS;
• TLS или REALITY;
• выбранный transport;
• служебные пакеты;
• подтверждения передачи.

Однако не существует универсальной формулы:

VLESS всегда расходует ровно на 5% больше.

Итог зависит от конфигурации и типа трафика.

Для длинной загрузки большого файла относительный overhead обычно небольшой.

Для множества коротких соединений и мелких пакетов он может быть заметнее.

Почему VPN вообще добавляет трафик

Без прокси передача упрощённо выглядит так:

приложение → TCP/IP → интернет

При использовании VLESS появляется дополнительный уровень:

приложение → VLESS → transport/security → TCP/IP → сервер

Сервер снимает этот внешний слой и отправляет исходный трафик дальше.

Само содержимое никуда не дублируется целиком.

То есть файл размером 1 ГБ не превращается автоматически в:

1 ГБ исходных данных + ещё 1 ГБ VLESS = 2 ГБ.

Добавляются в основном служебные данные вокруг полезной нагрузки.

Из чего состоит дополнительный расход

Каждый пакет в интернете содержит заголовки.

Для обычного IPv4 типичный IP-заголовок занимает 20 байт, а минимальный TCP-заголовок — ещё 20 байт. RFC 9293 прямо указывает 20 байт как фиксированный размер TCP-заголовка без опций, а классический IPv4-заголовок обычно также составляет 20 байт.

Получается минимум:

20 байт IPv4 + 20 байт TCP

ещё до учёта:

• TCP options;
• TLS;
• VLESS;
• transport;
• Ethernet/Wi-Fi;
• дополнительных сетевых уровней.

Это не уникальная проблема VPN.

Обычный HTTPS-трафик тоже имеет служебные заголовки.

VLESS лишь добавляет ещё один уровень упаковки.

TLS и REALITY тоже имеют overhead

VLESS часто используется вместе с TLS или REALITY.

TLS 1.3 передаёт данные отдельными records. Каждый защищённый record имеет собственный заголовок, внутренний ContentType и данные аутентифицированного шифрования. RFC 8446 отдельно описывает возможность дополнительного padding, поэтому точный размер служебной части зависит от реализации и конкретного record.

Поэтому нельзя просто сказать:

TLS всегда добавляет X байт на каждый мегабайт.

Количество records зависит от размера и характера передаваемых данных.

Но при большой непрерывной передаче служебная часть распределяется на большое количество полезных данных, поэтому её относительная доля обычно невелика.

REALITY не означает двойное шифрование всего интернета

Иногда пользователь представляет VLESS + REALITY примерно так:

сначала весь файл шифруется VPN, потом ещё раз REALITY, поэтому трафика становится в два раза больше.

Шифрование так не работает.

Если 1000 байт превращаются в зашифрованный блок, размер ciphertext обычно остаётся близким к размеру исходных данных плюс небольшая служебная часть.

TLS 1.3 использует AEAD и добавляет к защищаемому record служебные данные и authentication expansion, но не создаёт вторую полную копию payload.

Поэтому:

1 ГБ зашифрованных данных ≠ автоматически 2 ГБ сетевого трафика.

VLESS сам по себе довольно лёгкий

В документации Project X VLESS относится к отдельному proxy-протоколу, а transport и его security задаются дополнительно через streamSettings. Поддерживаются различные комбинации VLESS с RAW, XHTTP, gRPC и другими способами передачи.

Это важно для понимания расхода.

В реальном подключении нельзя измерять только:

overhead VLESS.

Нужно учитывать всю схему:

VLESS + transport + security + TCP/UDP/IP.

Сколько процентов добавляет VLESS

Точного универсального процента нет.

Для обычного большого потока данных можно ожидать, что дополнительный расход будет небольшой долей от общего объёма, а не десятками процентов только из-за самого факта VLESS.

Но реальная разница может стать больше при:

• очень мелких пакетах;
• большом количестве коротких соединений;
• частых переподключениях;
• повторной передаче потерянных пакетов;
• transport с дополнительной упаковкой;
• padding;
• плохой сети.

Поэтому утверждение:

«VLESS всегда добавляет ровно 2%»

будет таким же неверным, как:

«VPN удваивает весь трафик».

Пример с большим файлом

Представим загрузку файла:

10 ГБ

Браузер получает примерно 10 ГБ полезных данных.

В сети дополнительно передаются:

• TCP/IP headers;
• TLS records;
• VLESS;
• acknowledgements;
• служебные пакеты.

Поэтому оператор может посчитать немного больше.

Условно:

10 ГБ файла → немного больше 10 ГБ сетевого трафика.

Точное число зависит от конкретного соединения.

Главное:

разница обычно возникает из-за служебной упаковки, а не из-за создания второй копии файла.

Почему на мелких запросах overhead выше

Возьмём два крайних сценария.

Большой файл

Один пакет может содержать много полезных данных и относительно небольшой заголовок.

Например условно:

1400 байт данных + несколько десятков байт служебной информации.

Доля overhead небольшая.

Мелкий запрос

Если приложение отправляет:

50 байт полезных данных

а вокруг всё равно нужны:

• IP;
• TCP;
• TLS;
• transport,

служебная часть уже может быть сопоставима с payload.

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

Однако абсолютный объём таких мелких сообщений обычно небольшой.

Сколько расходует YouTube через VLESS

Здесь почти весь расход определяется самим видео, а не VLESS.

Например просмотр ролика создаёт:

• видеопоток;
• аудио;
• служебные запросы;
• небольшой overhead VPN.

Если YouTube передал несколько гигабайт видео, именно эти несколько гигабайт составят подавляющую часть расхода.

Гораздо сильнее на трафик влияет качество:

• 480p;
• 720p;
• 1080p;
• 1440p;
• 4K.

Переход с 1080p на 4K способен изменить расход в разы.

Включение VLESS поверх того же качества — обычно нет.

Может ли YouTube через VLESS расходовать больше косвенно

Да.

Но это уже интересный косвенный эффект.

Представим:

без VPN YouTube работает плохо → качество автоматически падает до 480p.

После включения VLESS:

соединение стало стабильным → YouTube выбирает 1080p или 4K.

В статистике пользователь увидит:

через VPN трафика стало намного больше.

Но причина не в VLESS overhead.

Причина в том, что YouTube начал передавать видео более высокого качества.

То же возможно со стриминговыми сервисами.

Сколько расходует Telegram через VLESS

Текстовые сообщения расходуют очень мало.

Главный трафик Telegram создают:

• фотографии;
• видео;
• голосовые сообщения;
• файлы;
• звонки.

VLESS добавляет к ним сетевой overhead, но основной объём остаётся тем же контентом.

Если через Telegram скачан файл размером 2 ГБ, именно файл определит практически весь расход.

Сколько расходует Discord

Текстовые сообщения почти незаметны.

Больше трафика создают:

• голос;
• видеосвязь;
• демонстрация экрана;
• стримы.

Discord также активно использует real-time traffic с большим количеством относительно небольших пакетов.

Поэтому процент служебного overhead здесь теоретически может быть выше, чем при загрузке одного большого файла.

Но абсолютный расход всё равно в первую очередь зависит от:

• качества видео;
• bitrate голоса;
• продолжительности разговора.

Сколько расходуют игры

У большинства онлайн-игр удивительно небольшой объём данных по сравнению с видео.

Игры постоянно отправляют:

• координаты;
• действия игроков;
• состояния объектов;
• служебные пакеты.

Но сами пакеты обычно небольшие.

VLESS/TUN добавляет к ним свои заголовки, поэтому относительный overhead может выглядеть заметнее.

Однако по абсолютным гигабайтам один вечер YouTube часто расходует больше, чем много часов обычного игрового трафика.

Совсем другое дело:

• скачивание игры;
• обновление клиента;
• патч на 50 ГБ.

Тогда снова доминирует объём самой загрузки.

Увеличивает ли TUN расход трафика

TUN сам по себе не создаёт огромный дополнительный расход.

Его задача — перехватить системный IP-трафик и передать его proxy-клиенту.

Главное отличие TUN от системного proxy в другом:

через TUN может идти больше приложений.

Например в proxy-режиме через VLESS работал только браузер.

После включения TUN через него начали идти:

• браузер;
• Discord;
• Telegram;
• лаунчеры;
• фоновые службы.

В результате общий расход VLESS действительно вырос.

Но не потому, что TUN «добавляет 50%».

Через туннель просто стало проходить больше реального трафика.

Почему маршрутизация может наоборот уменьшить расход VLESS

Если используется split routing:

зарубежные сервисы → VLESS

российские сайты → напрямую

часть трафика вообще не проходит через сервер.

Например:

• YouTube → VLESS;
• Discord → VLESS;
• российский банк → direct;
• маркетплейс → direct.

На самом интернет-тарифе пользователя эти данные всё равно учитываются.

Но в серверной статистике VLESS они не появятся.

Поэтому:

расход мобильного оператора

и:

расход VLESS-подписки

могут различаться.

Почему оператор телефона и VLESS показывают разные цифры

Это нормальная ситуация.

Разные счётчики измеряют разные точки сети.

Мобильный оператор видит трафик:

телефон ↔ сеть оператора

VLESS-сервер считает:

клиент ↔ proxy / inbound

Приложение может считать:

полезные данные приложения

или другой уровень.

Поэтому можно увидеть:

Android: 12,4 ГБ

VLESS-панель: 11,8 ГБ

оператор: 12,9 ГБ

и это не обязательно ошибка.

Счётчики могут по-разному учитывать:

• upload;
• download;
• protocol overhead;
• retransmissions;
• direct traffic;
• округление;
• период статистики.

Что именно считает 3x-ui

В актуальной 3x-ui клиенты имеют отдельный учёт трафика, включая upload и download, а также общий Total (GB) для квоты. При исчерпании заданного лимита клиент может быть отключён.

API панели также отдаёт для клиента отдельно:

up

и:

down.

Поэтому если провайдер VLESS говорит:

тариф 500 ГБ,

важно уточнить, что именно он считает.

Обычно лимит относится к суммарному клиентскому трафику:

upload + download.

Upload тоже расходует трафик

Пользователи иногда смотрят только на скачивание.

Но сервер может учитывать оба направления.

Например:

• скачали 100 ГБ;
• загрузили 20 ГБ;

итого:

120 ГБ.

Особенно заметен upload при:

• облачных backup;
• отправке видео;
• торрентах;
• стриминге;
• видеосвязи;
• синхронизации файлов.

Даже TCP acknowledgements создают небольшой обратный поток при обычном download.

Если тариф безлимитный, имеет ли расход значение

Для ограничения подписки — почти нет.

Но статистика всё равно полезна.

По резкому росту трафика можно заметить:

• утечку ключа;
• фоновые загрузки;
• неожиданное обновление;
• слишком активное устройство.

Например, если обычно используется:

30–50 ГБ в месяц

а внезапно появляется:

500 ГБ за несколько дней,

стоит проверить, откуда взялась нагрузка.

Может ли VLESS сам генерировать трафик, когда интернетом не пользуются

Небольшой служебный обмен возможен.

Приложение может:

• проверять подключение;
• обновлять подписку;
• выполнять ping;
• поддерживать соединения;
• делать DNS-запросы.

Операционная система и фоновые приложения тоже продолжают работать.

Поэтому:

телефон лежал на столе, но VLESS насчитал несколько мегабайт

не выглядит необычно.

Но сотни гигабайт фонового трафика уже требуют отдельной проверки.

Почему счётчик растёт даже когда браузер закрыт

Потому что браузер — далеко не единственный источник интернета.

Фоном могут работать:

• Windows Update;
• Google Drive;
• OneDrive;
• Steam;
• Epic Games;
• Telegram;
• Discord;
• антивирус;
• облачная синхронизация;
• резервное копирование телефона.

Если включён TUN, этот трафик тоже может идти через VLESS.

VLESS и обновления Windows

Большое обновление Windows может занимать несколько гигабайт.

Если маршрутизация отправляет Microsoft через VLESS, весь этот объём окажется в статистике сервера.

Это намного больше любого protocol overhead.

Поэтому при неожиданном скачке расхода сначала проверяйте реальные загрузки.

VLESS и Steam

То же самое с играми.

Пользователь может месяц пользоваться:

• браузером;
• Telegram;
• Discord

и расходовать сравнительно немного.

Затем Steam скачивает:

80 ГБ игры

и месячная статистика резко вырастает.

Это не «VLESS начал жрать трафик».

Через него прошла большая загрузка.

Влияет ли transport на расход

Да, потому что способы передачи отличаются.

Xray поддерживает для VLESS различные transport methods, включая:

• RAW;
• XHTTP;
• gRPC;
• WebSocket;
• другие варианты.

Каждый transport имеет собственный формат передачи и служебную информацию.

Поэтому два VLESS-профиля могут иметь немного разный overhead даже при одинаковом полезном трафике.

Однако выбирать transport исключительно по экономии нескольких процентов мобильного трафика обычно бессмысленно.

Гораздо важнее:

• работает ли соединение;
• стабилен ли маршрут;
• какая скорость;
• как transport проходит ограничения сети.

RAW обычно имеет меньше дополнительных уровней

RAW ближе всего к непосредственной передаче поверх базового stream.

XHTTP или gRPC добавляют дополнительную transport-логику.

Это может увеличивать количество служебных данных.

Но нельзя сделать вывод:

RAW всегда лучше.

Современные transports существуют не ради экономии байтов, а для различных сетевых сценариев и устойчивости соединения.

Если конкретная сеть лучше работает с XHTTP, небольшой дополнительный overhead может быть совершенно оправдан.

Может ли плохая сеть сильно увеличить расход

Да.

Здесь возникает важный фактор — retransmission.

TCP гарантирует доставку.

Если пакет потерялся, его приходится отправлять повторно.

Допустим, сеть постоянно теряет данные.

Часть пакетов передаётся:

первый раз → потеря

второй раз → успешно

Мобильный оператор физически видел обе передачи.

Поэтому при плохом Wi-Fi или нестабильной мобильной сети расход на передачу того же полезного объёма может увеличиться.

Это уже не чистый VLESS overhead, а последствия packet loss.

Почему это особенно заметно в мобильной сети

Мобильное соединение меняется:

• уровень сигнала;
• базовая станция;
• радиодиапазон;
• загрузка сети;
• маршрут.

При плохом качестве возможны:

• retransmissions;
• разрывы;
• повторные подключения.

Поэтому одинаковая задача может потребовать чуть разного сетевого объёма в разные дни.

VPN не позволяет оператору «не считать» трафик

VLESS скрывает содержимое и назначение соединения в рамках используемой схемы, но оператор всё равно видит передачу байтов между устройством и сервером.

Если мобильный тариф предоставляет:

30 ГБ

включение VLESS не превращает его в безлимитный.

Наоборот, внешний туннель тоже использует эти 30 ГБ.

После исчерпания тарифа VPN не может создать дополнительный физический канал.

А безлимит на отдельные приложения?

Это сложнее.

Некоторые мобильные тарифы не учитывают трафик конкретных сервисов:

• мессенджеров;
• соцсетей;
• музыки.

Если приложение работает напрямую, оператор может классифицировать такой трафик.

При использовании VLESS оператор в основном видит соединение с вашим VLESS-сервером.

Поэтому zero-rating конкретного приложения может не примениться.

То есть:

Telegram напрямую → возможно не расходует пакет

но:

Telegram через VLESS → выглядит как VLESS-трафик → расходует пакет.

Конкретное поведение зависит от оператора и тарифа.

Это может влиять на расход намного сильнее, чем собственный overhead VLESS.

Экономит ли VLESS трафик за счёт сжатия

Обычно рассчитывать на это не нужно.

Современный веб уже использует:

• Brotli;
• gzip;
• сжатые изображения;
• H.264/H.265/AV1;
• сжатое аудио.

Повторно сжимать такой поток почти бессмысленно.

Поэтому VLESS не следует рассматривать как технологию экономии мобильного интернета.

Его задача — передача и маршрутизация трафика, а не уменьшение размера YouTube-видео.

Может ли VPN расходовать меньше трафика

Косвенно — да.

Например, маршрутизация или блокировка рекламы может предотвратить загрузку части:

• рекламных баннеров;
• трекеров;
• ненужных доменов.

Тогда общий расход способен уменьшиться.

Но это функция правил DNS/routing/blocking, а не свойство VLESS как протокола.

Как самостоятельно измерить overhead VLESS

Можно провести простой тест.

Шаг 1

Подготовьте достаточно большой файл, например несколько гигабайт.

Шаг 2

Сбросьте статистику или запишите начальные значения:

• на устройстве;
• в VLESS-панели;
• у оператора, если статистика обновляется достаточно быстро.

Шаг 3

Скачайте файл через VLESS.

Шаг 4

Сравните:

• фактический размер файла;
• download VLESS;
• сетевой расход устройства.

Чем больше файл, тем меньше на результат влияют:

• DNS;
• handshake;
• короткие служебные запросы.

Но полностью лабораторным тест всё равно не будет, потому что устройство параллельно может генерировать другой сетевой трафик.

Почему нельзя проверить overhead через один Speedtest

Speedtest сам генерирует довольно большой объём данных и адаптирует тест к скорости соединения.

Более быстрый VPN может заставить Speedtest передать больше тестовых данных.

В результате:

один Speedtest через VLESS израсходовал больше мегабайт

не означает, что VLESS имеет огромный overhead.

Сам тест выполнил больше работы.

Как уменьшить расход мобильного интернета

Если гигабайты ограничены, намного эффективнее управлять полезным трафиком, чем пытаться экономить на заголовках VLESS.

Самые результативные меры:

1. Снизить качество YouTube.
2. Отключить автозагрузку видео в мессенджерах.
3. Запретить обновление игр через мобильную сеть.
4. Ограничить облачную синхронизацию.
5. Настроить direct routing для трафика, которому VPN не нужен.
6. Проверить фоновые приложения.
7. Отключить автоматические системные обновления через мобильную сеть.
8. Использовать стабильное соединение без большого packet loss.

Экономия здесь измеряется гигабайтами.

Разница transport overhead чаще значительно меньше.

Есть ли смысл выбирать VLESS ради меньшего расхода, чем у обычного VPN

Не как главный критерий.

WireGuard, OpenVPN, VLESS и другие решения имеют разные:

• протоколы;
• заголовки;
• transports;
• механизмы шифрования.

Но для обычного пользователя месячный расход намного сильнее определяется тем, что именно он делает в интернете.

Например:

час 4K-видео

может изменить расход сильнее, чем разница protocol overhead за много дней обычного веб-серфинга.

Поэтому выбирать VPN только по заявлению:

наш протокол экономит 3% трафика

обычно не имеет большого практического смысла.

Если VLESS неожиданно съел весь лимит

Проверьте по порядку:

1. Upload и download.

Возможно, смотрите только одно направление.

2. Игровые загрузки.

Steam/Epic могут скачать десятки гигабайт.

3. Облачные backup.

Особенно фотографии и видео.

4. Другие устройства.

Если один ключ используется на нескольких устройствах, их расход может суммироваться.

5. Утечку ключа.

Посторонний пользователь тоже способен расходовать вашу квоту.

6. Период сброса.

Панель и оператор могут считать разные календарные интервалы.

В 3x-ui трафик привязан к клиенту, а Total (GB) задаёт его общую квоту; панель отдельно хранит upload и download.

Один ключ на нескольких устройствах увеличивает расход?

Сам по себе — нет.

Но каждое устройство генерирует собственный трафик.

Например:

ПК: 100 ГБ

телефон: 30 ГБ

ноутбук: 20 ГБ

Общий расход одного VLESS-клиента может стать:

150 ГБ + служебный overhead.

Если тариф имеет общую квоту на credential, все устройства расходуют её совместно.

Это одна из причин, почему пользователь иногда удивляется:

я на телефоне почти ничего не скачивал, а трафик закончился.

Большую часть мог потратить компьютер.

Краткая таблица

Насколько стоит переживать из-за overhead

Для тарифа:

5 ГБ мобильного интернета

каждый дополнительный расход может быть важен.

Но даже здесь сначала стоит контролировать:

• видео;
• обновления;
• cloud sync.

Для тарифа:

50–100 ГБ

или безлимитного подключения собственный overhead VLESS обычно не является главной практической проблемой.

Гораздо сильнее ощущаются:

• скорость;
• ping;
• стабильность;
• маршрутизация.

Итог

Чтобы ответить, сколько трафика расходует VLESS, важно разделить полезные данные и сетевой overhead.

VLESS не создаёт вторую полную копию всего интернет-трафика.

Если вы скачали большой файл, через сеть действительно передастся немного больше его исходного размера из-за:

• IP;
• TCP или UDP;
• VLESS;
• TLS/REALITY;
• transport;
• служебных пакетов.

TCP и IP сами имеют обязательные заголовки ещё до появления VLESS, а TLS 1.3 дополнительно использует records с собственным заголовком, ContentType и AEAD-защитой.

При этом точного универсального процента для VLESS нет, потому что Xray позволяет использовать разные transports и варианты transport security. RAW, XHTTP и gRPC имеют различную структуру передачи.

Для обычного пользователя главный расход создаёт не VLESS, а сам контент:

• YouTube;
• загрузка игр;
• файлы;
• облачные backup;
• обновления.

Поэтому включение VLESS обычно не превращает:

10 ГБ → 20 ГБ.

Гораздо реалистичнее:

к полезному трафику добавляется сравнительно небольшой сетевой overhead, величина которого зависит от конкретной конфигурации и характера соединения.

А если счётчик VLESS неожиданно вырос на десятки или сотни гигабайт, искать причину сначала стоит в реальных загрузках, нескольких устройствах или возможной утечке ключа, а не в нескольких байтах служебных заголовков каждого пакета.