# Онлайн и трафик по инбаундам **URL:** https://f.docs.rw/t/topic/600 **Category:** Предложения **Created:** 2026-08-22T12:34:29Z **Posts:** 5 ## Post 1 by @slashfast — 2026-08-22T12:34:29Z Сейчас админ панели видит только агрегированный онлайн и трафик по ноде/инбаунду — и не может ответить на базовые эксплуатационные вопросы: - каким конкретно инбаундом реально пользуются клиенты (актуально для разных CDN); - какой из нескольких протоколов на профиле востребован, а какой можно смело выпилить, не сломав никому доступ. Это напрямую: - мешает саппорту (при жалобе конкретного пользователя нельзя проверить, к какому инбаунду он реально подключён и есть ли там трафик); - планированию нагрузки (перераспределять нагрузку между инбаундами/нодами приходится вслепую, потому что неизвестно, какой инбаунд реально тянет нагрузку, а какой простаивает). Помимо немедленной пользы для диагностики и планирования, эта же инфраструктура данных — необходимая предпосылка для будущих продуктовых решений (дифференцированные лимиты, биллинг или аналитика per inbound), которые сейчас архитектурно невозможны в принципе, независимо от того, будут ли они реализованы сразу или позже. То есть даже если единственным результатом этого изменения останется только видимость — она уже закрывает реальный кейс в эксплуатации панели, которого раньше не было и не могло быть без правки самого xray-core. Причина этого не в недоработке панели, а в архитектурном ограничении: восполнить эту гранулярность снаружи, на уровне сети, невозможно в принципе — многие инбаунды проксируются через L3-балансировщики (HAProxy, nginx stream), которые работают на уровне TCP/UDP passthrough и не видят прикладной протокол. Единственный источник данных с нужной гранулярностью — сам xray-core на ноде. Однако и xray-core не умеет считать трафик и присутствие в разрезе “юзер X на инбаунд Y”: счётчики per user и per inbound независимы и не пересекаются. Я предложил добавить такое измерение в StatsService ([PR #6494](https://github.com/XTLS/Xray-core/pull/6494)), но мейнтейнер отклонил PR, предложив использовать разных юзеров на разных инбаундах вместо правки API. Это неизбежно даёт N x M identity (N — юзеров, M — инбаундов на юзера) — но эту сложность не нужно решать через N x M новых сущностей в БД панели: можно переиспользовать уже существующее поле email в конфиге клиента, которое и так гоняется “панель-\>нода-\>ответ статистики”. Сейчас панель кладёт туда просто id пользователя; если изменить значение на {id}@{идентификатор инбаунда}, это добавляет нужное измерение поверх уже существующего StatsService. Отдельно стоит обсудить использование дополнительного короткого идентификатора инбаунда для добавления в email, так как uuid может раздуть их или использовать производное от уже существующего. Поскольку оба измерения — и онлайн, и трафик — в xray-core завязаны на один и тот же email-based счетчик в StatsService, один и тот же трюк с {id}@{идентификатор инбаунда} закрывает обе задачи одновременно: и присутствие пользователя на конкретном инбаунде, и объём его трафика именно на этом инбаунде — без отдельного механизма под каждую метрику. Готов взять на себя реализацию, если предложение будет одобрено. --- ## Post 2 by @remnawave — 2026-08-22T12:39:37Z > [@slashfast](#): > > Сейчас админ панели видит только агрегированный онлайн и трафик по ноде — и не может ответить на базовые эксплуатационные вопросы: каким конкретно инбаундом реально пользуются клиенты (актуально для разных CDN), какой из нескольких протоколов на профиле востребован, а какой можно смело выпилить, не сломав никому доступ. Технически – можно, но без деталей по типу _сколько пользователей._ Раздел: Ноды → Метрики. Там есть статистика по инбаундам (по общему трафику). --- ## Post 3 by @slashfast — 2026-08-22T12:45:57Z Да, трафик по инбаундам агрегированно уже виден — тут я неточно сформулировал в исходном посте, извиняюсь. Речь не про отсутствие инбаунд-статистики вообще, а про две конкретные вещи, которых там нет: 1. Online per inbound — сколько людей сейчас сидит на конкретном инбаунде. Этого нет вообще, только агрегат по ноде. 2. Кто из пользователей сколько трафика дал именно на этом инбаунде — в метриках есть только общая цифра по тегу, без разбивки по юзеру. Собственно вторая часть поста (про xray-core и email) как раз про это — почему “юзер X на инбаунде Y” нельзя получить штатно ни для трафика, ни для онлайна, и что с этим можно сделать. И это задел на ограничение трафика по инбаундам (или сквадам) в будущем, что для многих актуально. --- ## Post 4 by @slashfast — 2026-09-16T10:06:41Z Подготовил Draft-PR: [feat: add per-inbound user and traffic statistics by slashfast · Pull Request #218 · remnawave/backend · GitHub](https://github.com/remnawave/backend/pull/218) Пока не стал помечать для ревью, так как изменение большое и нужно обсудить идею в деталях по реализации. Однако считаю, что идея лаконичная и даже ложится в саму суть поля email в xray-core. --- ## Post 5 by @FunLay123 — 2026-09-16T16:37:46Z Прекрасная идея, я считаю