docs: help-articles

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

@@ -0,0 +1,31 @@
+## Xray JSON Subscription Format
+
+The Xray JSON format provides native JSON-based subscription support for compatible clients. Simply append `/json` to your subscription URL to enable this format.
+
+### Supported Applications
+
+- **v2rayNG** — version 1.8.29 or higher
+- **V2rayN** — version 6.40 or higher
+- **Streisand** — all versions
+- **Happ** — all versions
+- **V2Box** — all versions
+- **ktor-client** — all versions
+
+### Usage Instructions
+
+**Step 1:** Modify your subscription URL
+
+Append `/json` to the end of your subscription link:  
+`https://<server>/api/sub/xxxx/json`
+
+**Step 2:** Verify compatibility
+
+Ensure your client application meets the minimum version requirements listed above.
+
+**Alternatively:** Enable JSON At the base path
+
+Enable the "Serve JSON at base subscription" option in the subscription settings. This will serve the JSON subscription at the base subscription path (without having to append /json).
+
+### Fallback Behavior
+
+For clients that don't support the JSON format (such as Base64 or Mihomo-based clients), the subscription will automatically fall back to the standard format compatible with your client.

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

@@ -0,0 +1,43 @@
+## External Squads
+
+Using external squads, you can override certain settings or templates that users use when requesting a subscription. _A user cannot have more than one active external squad._
+
+For example, for different user groups, you can set different routing (for Happ, v2rayTUN), and different routing can also be within templates.
+
+Using the additional menu, you can quickly assign an external squad to all users (or conversely remove all users from an external squad).
+
+If a user has no external squad selected – global settings from the "**Subscription**" section are used, as well as the "**Default**" client config template.
+
+---
+
+Let's smoothly move on to reviewing the settings available in the external squad card.
+
+### Template Override
+
+When a user requests a subscription – depending on the client application from which the request came, the user may receive different templates. For example, if the application runs on the Mihomo core – Remnawave will detect this and provide the **Default** template of the **Mihomo** type. (You can manage templates in the corresponding section).
+
+Inside Remnawave, you can create an infinite number of templates for each type (Mihomo, Stash, Xray Json, Singbox, Clash), but by default, the **Default** template will always be provided.
+
+**To override this behavior is exactly what this setting inside the external squad exists for.**
+
+Let's say, for a specific external squad we want to use a _Custom Template_ that belongs to the **Mihomo** type, in this case we select this template in the corresponding section and save the changes. If a request comes from a user who belongs to this external squad – instead of the _Default_ template, they will receive the _Custom Template_.
+
+If you leave the override field empty – the user who is in this squad will receive the _Default_ template.
+
+_Please note, template override in the "Response Rules" section has a higher priority than override in this section._
+
+### Settings (Subscription)
+
+In this section, general settings that are located in the "Subscription" → "Settings" section are overridden. Accordingly, by overriding settings within the squad, you can override many parameters at once for an entire group of users.
+
+Keep in mind, if any of the parameters is explicitly overridden (including an empty value) – it will be overridden. Only deletion of the override (trash icon) will cancel the override.
+
+For example, in general settings my profile header is set as "Remnawave", but for 10 users I want to override it, for example to "Remnawave v.2.x", in this case I override this parameter in this section, and then assign this external squad to the needed 10 users.
+
+### Hosts
+
+Based on the logic from the previous point – in this section you can completely override some parameters that you might have noticed in the card of each **host** you created.
+
+**Values overridden here will be applied to all hosts that the user receives in the subscription.**
+
+For example, by overriding `vlessRouteId` we can assign a specific value and thus "_route_" an entire group of users (those who will be in this squad). Naturally, the other half of such routing settings is located in the server configuration – the Config Profile.

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

@@ -0,0 +1,67 @@
+## Hosts
+
+In brief, hosts are the client representation of your server configuration. If an **inbound** is required on the server for a successful connection, then on the client side the user needs a **host**.
+
+A group of hosts (or you could say a _list_) represents a subscription. A subscription is a link, and after adding such a link to a client application, the user sees a list of hosts (servers, if you will). The user can then choose any of them.
+
+It's important to note that a **host** is primarily just a client interpretation of your server component. For example, if a user has received a subscription (the list of hosts is already in their hands) and you disable this host - the user will **still be able** to connect to the server that this host points to. But upon updating the subscription - they will no longer have this host.
+
+Since a host is directly bound to an inbound (which is located in the profile) - the host inherits most settings from it. However, in some cases it can be useful to override or supplement these settings - that's what the **advanced** settings section is for.
+
+---
+
+When creating a new host or editing an existing one, you have access to two sections: **Basic** and **Advanced** (settings).
+
+### Basic
+
+- **Remark**
+
+    In this field, you define how this host will be displayed in the client application. Usually, the name of the country the user will be connecting to is written here.
+
+    _Tip: To display a country flag in the client application - add an emoji at the very beginning of the remark._
+
+- **Inbound Selection** (and profile)
+
+    As mentioned above - a host is just a client representation of your server configuration, so selecting an inbound is a mandatory requirement for creating a host. Depending on the number of inbounds, nodes, and profiles, select the appropriate inbound in the selection menu.
+
+- **Address** and **Port**
+
+    The address is a domain or IP address. In most cases, you need to specify the address or domain of the server the user will be connecting to. The port usually corresponds to the **inbound** port, _in some cases it may differ._
+
+    _You can also enter multiple domain names in the address field - for example: `node-1.com,node-2.com,node-3.com`. You might think that this could theoretically be used for some load balancing, but it's important to note - the user will receive only one of these addresses when requesting a subscription (which specific one they get is determined randomly and is not tied to any load balancing logic). Consequently - until the user updates the subscription in the client application (or unless auto-update triggers) - the user's address will not change._
+
+- _Tag_ and _Nodes_
+
+    These parameters are not visible to the end user, they are more for the panel administrator (you) to make it easier to navigate through created hosts in the future if there are many of them.
+    In particular, selecting a node in this field doesn't play a functional role - **this is only a visual binding for easier navigation in the future.**
+
+---
+
+### Advanced
+
+**In most cases, you don't need to edit anything from this section unless you clearly understand what purposes you're doing it for. Incorrect modification of some parameters may result in your connection not working. Approach editing each item with all seriousness and always double-check settings before applying changes.**
+
+In this section, we won't go through every item - we'll focus on the main ones.
+
+- **SNI (ServerNames)**
+
+    In some cases, it may be necessary to override the `serverNames` object settings (which are defined within the inbound in the profile) for a specific host.
+
+    Keep in mind, `serverNames` in simple terms is the _password_ by which, for example, **Reality** determines the **validity** of the connection. If you specify an **SNI** in this field, for example `example.com`, and within the inbound `serverNames` looks like this:
+
+    ```json
+    "serverNames": [
+    	"example1.com",
+    	"example2.com"
+    ]
+    ```
+
+    Such a connection will not work, as `example.com` is not in the list of allowed `SNI`.
+
+- **Override SNI from Address**
+
+    By default, Remnawave takes the first object from the `serverNames` array (of the inbound) to add SNI to the client host. If you enable this parameter - Remnawave will take the address (which you specified in the **Basic** section) and pass it to the client.
+
+Among other items in this section, the `vlessRouteId` field is also worth noting, which is a small abstraction layer over Xray Core and provides you with a simple way to use the `vlessRoute` functionality that Xray provides. <a href="https://xtls.github.io/en/config/routing.html#ruleobject">Learn more about routing rules.</a>
+
+---

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

@@ -0,0 +1,21 @@
+## Internal Squads
+
+The main purpose of internal squads is **access control** for users.
+
+Internal squads are directly linked to **profiles** and their **inbounds**. You can assign them as many active inbounds as needed (which are located inside profiles). And since profiles and their inbounds are directly linked to nodes – using an internal squad, we can finely control which users or groups of users can have access to nodes.
+
+---
+
+In each squad's card (in the general list), you can see the number of active inbounds, as well as the number of members in this squad (users who belong to it).
+
+By clicking on the additional actions button (in the squad card), you can also quickly add or remove all users. If you need to assign a squad to _specific_ users – you can do this in the **"Users"** section.
+
+Managing users and nodes that can be accessible to them can sometimes be very confusing – use the **"Available Nodes"** button to quickly see which nodes are available to this squad. Let me remind you that when creating or modifying a **node**, we also select which **profile** will be used and which **inbounds** from it will be active on the node. And since we also select **inbounds** inside the squad, we can use these relationships to determine specific nodes that this squad (and consequently its members) will have access to.
+
+---
+
+For example, we have two user groups: **free** and **paid**. And we want **free** users to have access to _server group #1_, and paid users to have access to both _server group #1_ and additionally to _server group #2_.
+
+For this purpose, we create two squads: **Free** and **Premium**, and inside each of them we select the corresponding inbounds.
+
+And let's say we're creating a user – in this case, if we have a free user – we simply activate the **Free** internal squad for them. And when we have a paid user – we activate both squads – **Free** and **Premium** (if the user needs access to all nodes/inbounds). But we can also activate only one squad for a paid user – **Premium**, in which case the user will not have access to the nodes/inbounds from the **Free** group.