Где считаются байты и почему счётчики расходятся
Учёт трафика VPN — это не одна цифра, а несколько независимых счётчиков в разных точках маршрута. Прежде чем настраивать квоты, инженеру-оператору важно понимать, что каждая точка меряет своё и по своей единице. Совпадать они не будут никогда — вопрос лишь в том, насколько предсказуемо расхождение.
Минимум три точки учёта в типовой связке «gateway → нода → панель»:
| Точка учёта | Что меряет | Единица |
|---|---|---|
| Инбаунд ноды (stats Xray/sing-box) | полезную нагрузку туннеля | байты uplink/downlink |
| Панель (Remnawave, Marzban, 3x-ui, Hiddify) | трафик против квоты юзера | байты × множитель ноды |
| Биллинг gateway / CDN-edge | трафик «по проводу» + число запросов | байты + запросы |
Инбаунд ноды видит расшифрованную нагрузку туннеля. Панель забирает эти счётчики по API и агрегирует их per-user. А биллинг gateway (входного whitelisted-узла или CDN-edge) считает то, что реально прошло по каналу: TLS-записи, HTTP-фрейминг, заголовки, паддинг и повторы. Поэтому байты на gateway почти всегда больше, чем на инбаунде ноды. Метрирование gateway и учёт в панели — это два разных измерения одного потока, и сводить их нужно осознанно.
Учёт трафика в панели: per-user лимиты и множитель ноды
Панели VPN (Remnawave, 3x-ui, Marzban, Hiddify) не считают байты сами — они опрашивают stats-API транспорта на ноде (у Xray это gRPC stats service) с некоторым интервалом и складывают дельты в кумулятивные per-user счётчики. Именно против этих счётчиков и срабатывает квота трафика.
Ключевой механизм для оператора — множитель потребления ноды (traffic coefficient). Панель умножает засчитанные байты на коэффициент ноды перед списанием с лимита юзера:
- множитель 1 — трафик списывается один к одному;
- множитель >1 — «дорогая» нода тратит квоту быстрее (например, премиум-локация или дорогой транзит через gateway);
- множитель 0 — трафик на этой ноде не засчитывается против лимита юзера вообще, при этом сама нода продолжает работать.
Множитель 0 удобен для промо-локаций, тестовых нод или узлов, где вы метрируете трафик отдельно на стороне gateway и не хотите двойного учёта. Но у него есть ловушка: если нода с множителем 0 несёт реальный платный трафик через CDN-edge, панель этого не увидит, квота юзера не уменьшится, а расходы на gateway вы всё равно понесёте. Для таких нод нужен отдельный слой enforcement или лимиты по времени/скорости.
Метрирование на gateway в реальном времени
«Реальное время» в метрировании — это всегда near-real-time: и панель, и gateway снимают счётчики с фиксированным интервалом опроса, а не по каждому пакету. Попакетный учёт технически возможен, но на масштабе дорог и почти никогда не нужен. Практика — агрегировать flow-счётчики или access-логи раз в несколько секунд и считать дельты.
Принципиальное отличие gateway от ноды: входной узел считает не только байты, но и число запросов. Это критично при транспорте XHTTP (mode packet-up) через CDN. XHTTP по своей природе плодит множество мелких uplink-запросов, и каждый такой запрос — отдельная биллинговая единица на edge, вдобавок к переданным байтам. То есть два туннеля с одинаковым объёмом полезной нагрузки могут дать разный счёт на gateway, если у них разная гранулярность запросов.
Отдельный момент, влияющий на корректность метрирования через CDN: при XHTTP uplink-данные должны идти в теле запроса (uplinkDataPlacement: "body"), а не в кастомном заголовке. CDN-edge кастомные заголовки до origin не доносит — туннель рвётся с ошибкой вроде «unexpected EOF». Session/seq кладут в cookie, padding — в query. Это заодно влияет и на учёт: паддинг в query раздувает размер запроса «по проводу», и gateway честно посчитает эти байты, хотя полезной нагрузкой они не являются.
Реконсиляция панели и биллинга gateway
Реконсиляция — это регулярная сверка «сколько насчитала панель» против «сколько выставил gateway». Без неё вы либо переплачиваете, либо неверно списываете квоту с юзеров. Разница почти всегда в пользу gateway, и её источники предсказуемы:
- TLS и HTTP-фрейминг — заголовки, TLS-записи, служебные ответы;
- паддинг — искусственный объём в query/теле запроса;
- повторы и keepalive — ретрансмиты и служебные соединения;
- число запросов — XHTTP-гранулярность, которую панель по байтам не видит.
Практический подход — вычислить эмпирический коэффициент оверхеда: за репрезентативный период возьмите суммарные байты gateway и суммарные байты панели по той же ноде, поделите одно на другое. Полученный множитель (обычно заметно больше единицы) и есть ваш реальный «курс» между полезной нагрузкой и трафиком по проводу. Его можно частично заложить в множитель ноды в панели, чтобы квота юзера примерно соответствовала реальным расходам на gateway. Коэффициент не статичен: он зависит от паттерна трафика (много мелких запросов против крупных постов), поэтому пересчитывайте его периодически и держите алерт на резкое расхождение — это ранний признак либо неправильной конфигурации транспорта, либо утечки трафика мимо учёта.
Квота трафика: enforcement и типовые ошибки
Квота трафика срабатывает по кумулятивному per-user счётчику панели. Поскольку счётчик обновляется по интервалу опроса, между двумя опросами юзер может уйти в перерасход — это нормальный лаг enforcement, а не баг. Чем короче интервал, тем точнее отсечка, но тем выше нагрузка на stats-API ноды. Для большинства операторов достаточно интервала в единицы–десятки секунд.
Типовые ошибки при настройке квот:
- множитель 0 на боевой ноде — трафик идёт, стоит денег на gateway, но с квоты не списывается;
- учёт только на ноде — вы не видите оверхед и число запросов, и реальные расходы на gateway превышают списанное с юзеров;
- игнор служебного трафика — паддинг, keepalive и повторы попадают в счёт gateway, но на инбаунде ноды их почти нет, из-за чего сверка «не бьётся»;
- жёсткая отсечка без буфера — из-за лага опроса юзер успевает превысить лимит; закладывайте небольшой запас или мягкий throttle перед хардкапом.
Отдельно стоит помнить: метрирование не решает задачу репутации IP. Стриминг вроде Кинопоиска банит датацентр-IP по репутации, и для российского контента нужен резидентный IP — whitelisted-вход и корректный учёт трафика это не закрывают. Не путайте «пробить троттлинг» и «разблокировать стриминг» — это разные задачи с разными метриками.
Себестоимость метрируемого трафика и оптимизация
Метрирование напрямую связано с экономикой. Номинальная цена за гигабайт мало что говорит: у провайдеров с тарификацией запросов XHTTP-профиль добавляет к счёту отдельную статью, и реальная ставка получается заметно выше прайсовой. Именно поэтому число запросов — такая же метрика первого класса, как и байты: XHTTP при мелкой гранулярности плодит запросы и поднимает удельную стоимость.
Главный рычаг оптимизации метрируемого трафика — снижать число запросов, не теряя полезную нагрузку. Крупные POST'ы в тело запроса вместо россыпи мелких снижают и количество биллинговых единиц, и накладной оверхед на заголовки. Это одновременно уменьшает счёт на gateway и сближает счётчики панели и биллинга, упрощая реконсиляцию.
Чтобы учёт был честным, origin должен принимать трафик только от gateway: закройте вход файрволом на IP шлюза и добавьте секрет-заголовок X-Cdn-Auth, отсекающий прямые обращения мимо CDN. Иначе часть трафика пройдёт мимо метрирования, и сверка развалится.
Если вы не хотите поднимать и мониторить собственный whitelisted-слой, Clearway (clear-way.pro) предоставляет whitelisted-вход перед нодами как сервис — оператор получает «белый» edge (*.whitechannel-x1-cdn.ru) без покупки серверов, с прозрачным учётом трафика и запросов на стороне gateway. Метрирование при этом остаётся вашим: панель считает per-user квоты, gateway — байты и запросы, а сверка между ними — рутинная операция, описанная выше.