Два независимых механизма: лимит пользователя и множитель ноды
Remnawave разводит учёт трафика по двум уровням, и их важно не путать.
Per-user лимит живёт на уровне пользователя. Это две настройки: объём квоты (в байтах / ГБ) и стратегия сброса. Лимит отвечает на вопрос «сколько данных пользователю разрешено потратить за период».
Множитель потребления (consumption multiplier) живёт на уровне ноды. Это коэффициент, который определяет, насколько «дорого» считается трафик, прошедший именно через этот узел. Множитель отвечает на вопрос «во сколько квоты обходится 1 ГБ реального трафика на конкретной ноде».
Разделение даёт гибкость: один и тот же лимит пользователя расходуется по-разному в зависимости от того, через какую ноду он вышел. Дешёвый прямой узел и дорогой узел за CDN могут списывать квоту с разной скоростью, хотя лимит у пользователя один.
Формула учёта: как множитель влияет на квоту
Правило простое и линейное:
Списанный с квоты трафик = фактический трафик × множитель ноды.
Панель суммирует списания по всем нодам, через которые ходил пользователь, и сравнивает с его лимитом. Несколько примеров для 1 ГБ реально переданных данных:
| Множитель ноды | Списывается с квоты за 1 ГБ | Типичный смысл |
|---|---|---|
| 0 | 0 ГБ | нода вне учёта (трафик не считается) |
| 0.5 | 0.5 ГБ | льготная / дешёвая нода |
| 1.0 | 1 ГБ | базовый учёт 1:1 |
| 2.0 | 2 ГБ | дорогой маршрут считается вдвое |
Множитель 0 — особый случай: нода полностью функциональна и пропускает трафик, но её потребление не идёт против лимита пользователя. Это не выключенная нода, а нода «вне тарификации». Реальные расходы на такой узел вы всё равно несёте — просто панель их не относит на квоту клиента, поэтому за фактическим потреблением такой ноды нужно следить отдельно.
Настройка per-user лимита и стратегии сброса
Лимит пользователя задаётся объёмом квоты и периодом её обнуления. Стратегии сброса в Remnawave покрывают основные тарифные модели:
- Без сброса — жёсткий пакет данных, который не восстанавливается (разовый объём).
- Ежедневно / еженедельно / ежемесячно — квота обнуляется на границе периода, что удобно для подписочных тарифов.
Когда пользователь исчерпывает лимит с учётом всех множителей, доступ ограничивается до следующего сброса — это и есть встроенный контроль перерасхода. Практический совет: задавайте лимит и стратегию не в карточке каждого пользователя вручную, а через шаблон / группу, чтобы новые подписки наследовали единые правила и матрицу учёта было проще сопровождать.
Сценарии применения множителя
Consumption multiplier — это в первую очередь инструмент экономики сервиса, а не технического ограничения.
Тарифная дифференциация. Премиальные локации получают множитель выше 1, базовые — 1.0. Один лимит расходуется быстрее на «дорогих» нодах, что естественно разделяет тарифы без создания отдельных квот.
Номинальная цена за гигабайт мало что говорит: у провайдеров с тарификацией запросов XHTTP-профиль добавляет к счёту отдельную статью, и реальная ставка получается заметно выше прайсовой. Повышенный множитель на такой ноде переносит эту разницу в учёт, чтобы дорогой путь не «съедал» экономику молча.
Промо и удержание. Множитель 0 на резервной ноде — способ временно дать доступ, не расходуя квоту клиентов. Типичная ситуация: у мобильного оператора шатдаун или троттлинг, прямые ноды отвалились, и вы переводите пользователей на whitelist-маршрут. Обнулив множитель на этой ноде на время инцидента, вы сохраняете лояльность и не наказываете клиентов квотой за форс-мажор.
Множитель и ноды за whitelist-CDN под троттлингом
Контекст, в котором множитель особенно полезен, — устойчивость сервиса под ограничениями оператора связи. При блокировках и шатдаунах мобильные операторы в РФ переводят интернет в режим белого списка: доступны только whitelisted-ресурсы (часть CDN, госсайты), а VPN, идущий напрямую к своей ноде, отваливается.
Рабочий инфраструктурный ответ — спрятать вход за whitelisted CDN-edge: транспорт XHTTP (mode packet-up) идёт через CDN, оператор видит обращение к «белому» ресурсу, а CDN проксирует на вашу ноду. Reality или Hysteria2 напрямую под троттлингом обычно не проходят — edge их не пропускает.
Важный нюанс инфраструктуры: whitelist привязан к подсетям /24. У одних хостеров подсети в белых списках, у других нет, а статус меняется — проверять каждую /24 нужно отдельно и актуально, без гарантий (Selectel часто whitelisted, cloud.ru / SberCloud — часто нет). Именно этот «белый» вход как сервис (без продажи серверов) предоставляет Clearway: оператор ставит whitelisted CDN-edge перед своими нодами, а множителем в Remnawave отражает более высокую себестоимость этого маршрута в учёте. Отдельно держите в голове, что whitelist-CDN решает задачу «пробить троттлинг», но не разблокирует стриминг с репутационными банами дата-центров — это другая задача, требующая резидентного IP.
Подводные камни учёта
- Множитель применяется к ноде, а не к пользователю. Все клиенты, вышедшие через узел, считаются по одному коэффициенту. Персональные скидки квоты множителем не сделать — только через отдельный лимит или группу.
- Изменение множителя влияет на будущий трафик. Уже списанное панель задним числом не пересчитывает, поэтому меняйте коэффициент осознанно, а не «поиграться».
- Множитель 0 не экономит ваши деньги. Трафик идёт и стоит вам ровно столько же — вы лишь не относите его на квоту клиента. Следите за реальным потреблением такой ноды отдельно от панельного учёта.
- Учёт зависит от репортинга ноды. Если узел не отдаёт статистику трафика в панель, ни лимит, ни множитель не сработают. После настройки прогоните контрольный трафик и сверьте, что списание идёт с учётом коэффициента.
- Безопасность origin — часть учёта. Ноду за CDN закрывайте файрволом на вход только с IP gateway и защищайте секрет-заголовком (X-Cdn-Auth), иначе прямые обращения мимо CDN исказят и статистику, и нагрузку.