docs: help-articles

_panel-docs/help-articles/ru/EDITOR_TEMPLATES_XRAY_JSON.md

@@ -0,0 +1,31 @@
+## Формат подписки Xray JSON
+
+Формат Xray JSON обеспечивает поддержку подписок в формате JSON для совместимых клиентов. Просто добавьте `/json` в конец URL вашей подписки, чтобы включить этот формат.
+
+### Поддерживаемые приложения
+
+- **v2rayNG** — версия 1.8.29 или выше
+- **V2rayN** — версия 6.40 или выше
+- **Streisand** — все версии
+- **Happ** — все версии
+- **V2Box** — все версии
+- **ktor-client** — все версии
+
+### Инструкции по использованию
+
+**Шаг 1:** Измените URL вашей подписки
+
+Добавьте `/json` в конец вашей ссылки на подписку:  
+`https://<сервер>/api/sub/xxxx/json`
+
+**Шаг 2:** Проверьте совместимость
+
+Убедитесь, что ваше клиентское приложение соответствует минимальным требованиям к версии, перечисленным выше.
+
+**Или:** Включите JSON на базовом пути
+
+Включите опцию "Обслуживать JSON на базовом пути подписки" в настройках подписки. Это позволит обслуживать подписку JSON на базовом пути подписки (без необходимости добавлять /json).
+
+### Резервное поведение
+
+Для клиентов, которые не поддерживают формат JSON (таких как клиенты на основе Base64 или Mihomo), подписка автоматически вернется к стандартному формату, совместимому с вашим клиентом.

_panel-docs/help-articles/ru/PAGE_EXTERNAL_SQUADS.md

@@ -0,0 +1,43 @@
+## Внешние сквады
+
+С помощью внешних сквадов вы можете переопределить некоторые настройки или шаблоны, которые пользуются пользователи при запроме подписки. _У одного пользователя не может быть больше одного активного внешнего сквада. _
+
+Например, для разных групп пользователей вы можете задать разный роутинг (для Happ, v2rayTUN), разный роутинг может быть в том числе внутри шаблонов.
+
+С помощью дополнительного меню вы можете быстро назначить внешний сквад всем пользователям (или наоборот убрать всех пользователей из внешнего сквада).
+
+Если у пользователя не выбран общий сквад – использую глобальные настройки из раздела «**Подписка**», а так же шаблон клиентского конфига «**Default**».
+
+---
+
+Плавно перейдем к рассмотрению настроек, которые доступны в карточке внешнего сквада.
+
+### Переопределение шаблонов
+
+Когда пользователь запрашивает подписку – в зависимости от клиентского приложения из которого пришел запрос, пользователь может получить разные шаблоны. Например, если приложение, которое работает на ядре Mihomo – Remnawave увидит это и выдаст **Default** шаблон типа **Mihomo**. (Управлять шаблонами вы можете в соотвествующем разделе).
+
+Внутри Remnawave вы можете создавать бесконечное множество шаблонов для каждого типа (Mihomo, Stash, Xray Json, Singbox, Clash), но по умолчанию всегда будет отдаваться **Default** шаблон.
+
+**Чтобы переопределить это поведение как раз и существует эта настройка внутри внешнего сквада.**
+
+Допустим, для определенного внешнего сквада мы хотим использовать _Custom Template_, который принадлежит к типу **Mihomo**, в таком случае мы выбираем этот шаблон в соответствующем разделе и сохраняем изменения. Если запрос придет от пользователя, который состоит в этом внешнем скваде – вместо _Default_ шаблона он получит _Custom Template_.
+
+Если оставить поле переопределения пустым – пользователь, который находится в этом скваде получит _Default_ шаблон.
+
+_Обратите внимание, переопределение шаблона в разделе «Правила ответов» имеет более высокий приоритет, чем переопределение в этом разделе._
+
+### Настройки (подписки)
+
+В этом разделе переопределяются общие настройки, которые находятся в разделе «Подписка» → «Настройки». Соотвественно, с помощью переопределения настроек в рамках сквада вы можете переопределить многие параметры сразу для целой группы пользователей.
+
+Имейте в виду, если любой из параметров явно переопределен (в том числе пустое значение) – он будет переопределен. Только удаление переопределения (значек корзины) отменит переопределение.
+
+К примеру, в общих настройках заголовок профиля у меня указан как «Remnawave», но для 10-ти пользователей я хочу переопределить его, например на «Remnawave v.2.x», в таком случае в этом разделе я переопределяю этот параметр, а потом нужным 10-ти пользователям назначаю этот внешений сквад.
+
+### Хосты
+
+Основываясь на логике из предыдущего пункта – в этом разделе можно полностью переопределить некоторые параметры, которые вы могли заметить в карточке каждого созданного вами **хоста**.
+
+**Переопределенные здесь значения будут применены ко всем хостам, которые получает пользователь в подписке.**
+
+Например, с помощью переопределение `vlessRouteId` мы можем назначить определенное значение и таким образом «_роутить_» целую группу пользователей (тех, которые будут находиться в этом скваде). Само собой, вторая половина настроек такого роутинга находится в серверной конфигурации – профиля.

_panel-docs/help-articles/ru/PAGE_HOSTS.md

@@ -0,0 +1,67 @@
+## Хосты
+
+Кратко говоря, хосты это клиентская репрезентация вашей серверной конфигурации. Если на сервере для успешного подключения необходимо **инбаунд**, то на клиентской стороне пользователю необходим **хост**.
+
+Группа хостов (или можно сказать _список_), представляет из себя подписку. Подписка – это ссылка, после добавления такой ссылки в клиентское приложение перед пользователем появляется список хостов (серверов, если угодно). И далее пользователь уже вправе выбирать любой из них.
+
+Важно заметить, что **хост** является в первую очередь лишь клиентской интерпретация вашей серверной части. Например, если пользователь получил подписку (список хостов у него уже на руках), а вы отключите этот хост – пользователь по прежнему **сможет** подключиться к серверу, на который направлен этот хост. Но при обновлении подписки – этого хоста у него уже не будет.
+
+Так как хост привязывается напрямую к инбаунду (который находится в профиле) – хост наследует большинство настроек из него, однако в некоторых случаях бывает полезно переопределить или дополнить эти настройки – для этого существует раздел **расширенных** настроек.
+
+---
+
+При создании нового хоста или редактировании существующего, перед вами доступно два раздела: **Основные** и **Расширенные** (настройки).
+
+### Основные
+
+- **Примечание**
+
+    В этом пункте вы определяете как данный хост будет отображаться в клиентском приложение. Обычно здесь пишут название страны, к которой будет подключаться пользователь.
+
+    _Совет: чтобы в клиентском приложении отображался флаг страны – добавьте эмоджи в самое начало примечания._
+
+- **Выбор инбаунда** (и профиля)
+
+    Как уже упоминалось выше – хост это лишь клиентская репрезентация вашей серверной конфигурации, поэтому и обязательным требованием к созданию хоста является выбор инбаунда. В зависимости от количества инбаундов, нод и профилей выберите соотвествующий инбаунд в меню выбора.
+
+- **Адрес** и **порт**
+
+    Адресом является домен или IP-адрес, в большинстве случаев здесь необходимо прописать адрес или домен сервера, к которому будет подключаться пользователь. Порт – обычно соответствует порту **инбаунда**, _в некоторых случаях может отличаться._
+
+    _В адрес можно так же вписать несколько доменных имен – например: `node-1.com,node-2.com,node-3.com`. Может возникнуть мысль, что с помощью этого в теории можно производить некоторую балансировку, но важно заметить – пользователь при запросе подписки получит лишь один из этих адресов (что конкретно он получит определяется случайно и не привязано к какому-либо логике балансировке). Следовательно – до тех пор, пока пользователь не обновит подписку в клиентском приложении (или если не сработает автообновление) – адрес у пользователя не изменится._
+
+- _Тег_ и _ноды_
+
+    Эти параметры не видны конечному пользователю, они больше нужны администратору панели (вам), чтобы в будущем было проще ориентироваться в созданных хостах, если их будет много.
+    В частности, выбор ноды в этом пункте не играет функциональной роли – **это только визуальная привязка для более простого ориентирования в будущем.**
+
+---
+
+### Расширенные
+
+**В большинстве случаев вам не нужно редактировать ничего из этого раздела, если вы явно не понимаете для каких целей это делаете. Некорректное изменение некоторых параметров может привести к тому, что ваше подключение будет не работать. Отнеситесь к редактированию каждого пункта со всей серьезности и всегда проверяйте дважды сверяйте настройки перед применением изменений.**
+
+В этом разделе мы не будем делать проходить по каждому пункту – сконцентрируемся на основных пунктах.
+
+- **SNI (ServerNames)**
+
+    В некоторых случаях бывает необходимо переопределить настройки объекта `serverNames` (которые определяются внутри инбаунда в профиле) для конкретного хоста.
+
+    Имейте в виду, `serverNames` простым языком является _паролем_, по которому, например, **Reality** определяет **валидность** соединения. Если вы в этом пункте укажете **SNI**, например `example.com` и при этом внутри инбаунда `serverNames` выглядят вот так:
+
+    ```json
+    "serverNames": [
+    	"example1.com",
+    	"example2.com"
+    ]
+    ```
+
+    Такое соединение работать не будет, так как `example.com` не находится в списке разрешенных `SNI`.
+
+- **Переопределить SNI из адреса**
+
+    По умолчанию, Remnawave берет первый объект из массива `serverNames` (инбаунда) чтобы добавить SNI в клиентский хост. Если вы включите этот параметр – Remnawave возьмет адрес (который вы указали в разделе **Основные**) и передаст его клиенту.
+
+Из прочих пунктом в этом разделе так же можно выделить пункт `vlessRouteId`, который является небольшим слоем абстракции над Xray Core и предоставляем вам простой способ воспользоваться функционалом `vlessRoute`, который предоставляет Xray. <a href="https://xtls.github.io/ru/config/routing.html#ruleobject">Ознакомиться подробнее с правилами роутинга.</a>
+
+---

_panel-docs/help-articles/ru/PAGE_INTERNAL_SQUADS.md

@@ -0,0 +1,21 @@
+## Внутренние сквады
+
+Основная цель внутренних сквадов – это **разграничение** доступа пользователей.
+
+Внутренние сквады напрямую связаны с **профилями** и их **инбаундами**. Им можно назначить сколько угодно активных инбаундов (которые находятся внутри профилей). А так как профили и их инбаунды напрямую связаны с нодами – с помощью внутреннего сквада мы можем тонко контролировать какие пользователи или группы пользователей могут иметь доступ к нодам.
+
+---
+
+В карточке каждого сквада (в общем списке) вы можете заметить количество активных инбаундов, а так же количество участников этого сквада (пользователей, которые состоят в нем).
+
+При нажатии на кнопку дополнительных действий (в карточке сквада) вы можете так же быстро добавить или удалить всех пользователей. Если вам требуется назначить сквад каким-то _определенным_ пользователям – вы можете это сделать в разделе **«Пользователи»**.
+
+Менеджмент пользователей и нод, которые могут быть им доступны иногда бывает очень запутанным – воспользуйтесь кнопкой **«Доступные ноды»**, чтобы быстро посмотреть какие ноды доступны этому скваду. Напомню, что при создании или изменнии **ноды** мы так же в ней выбираем какой **профиль** будет использоваться и какие **инбаунды** из него будут активны на ноде. И так как внутри сквада мы тоже выбираем **инбаунды**, поэтому мы можем с помощью связей определить конкретные ноды, к которым у этого сквада (следовательно и его участников) будет доступ.
+
+---
+
+Для примера, у нас есть две группы пользователей: **бесплатные** и **платные**. И мы хотим, что бы **бесплатные** пользователи имели доступ к _группе серверов #1_, а платные имели доступ и к _группе серверов #1_, а так же дополнительно к _группе серверов #2_.
+
+Для этой цели мы создадим два сквада: **Free** и **Premium**, внутри каждого из них выбираем соответствующие инбаунды.
+
+И допустим, что мы уже создаем пользователя – в таком случае если перед нами бесплатный пользователь – мы просто активируем для него внутренний сквад **Free**. А когда перед нами будет платный пользователь – активируем оба сквада – **Free** и **Premium** (если нужно, чтобы у пользователя был доступ ко всем нодам/инбаундам). Но мы так же можем для платного пользователя активировать только один сквад – **Premium**, в таком случае доступа к нодам/инбаундам из группы **Free** у пользователя не будет.