VPN/panel
1
0
Fork 0
mirror of https://github.com/remnawave/panel.git synced 2026-04-20 14:42:01 +00:00
Code Issues Packages Projects Releases Wiki Activity

fix: broken links

Browse Source
This commit is contained in:
kastov
2025-10-26 06:08:47 +03:00
parent 0a576a85b5
commit 0f21319ed1
2 changed files with 44 additions and 56 deletions
Download Patch File Download Diff File Expand all files Collapse all files

43
docs/learn-en/quick-start.md
View File

@@ -106,11 +106,11 @@ With the 2.2.0 update, authentication methods and branding can now be managed in
You can customize your Brand Name and use your own Logo.
- `Brand Name`
Set any text to replace the default “Remnawave” brand name on the login page and navigation menu.
Set any text to replace the default “Remnawave” brand name on the login page and navigation menu.
- `Logo URL`
Upload your custom logo image to display on the login page and navigation menu.
Upload your custom logo image to display on the login page and navigation menu.
### Authentication Methods {#oauth}
### Authentication Methods {#oauth}
Remnawave supports multiple authentication methods for passwordless logins. You can enable one or more options based on your needs.
@@ -131,11 +131,11 @@ Before setting up Passkey authentication, you need to define your Panel domain.
Define the fully qualified HTTPS origin for your backend your backend (e.g., `https://panel.example.com`)
2. **Register a Passkey**
Click `Manage`, then `Register`. Follow the steps your browser/device provides.
Click `Manage`, then `Register`. Follow the steps your browser/device provides.
3. **Login Using Passkey**
After registration, return to the login page to test the passkey. Once confirmed, you can disable username/password login.
</details>
</details>
#### GitHub {#github}
@@ -152,14 +152,14 @@ Visit [Developer Settings page](https://github.com/settings/applications/new) to
2. **Get Client ID and Client Secret**
Copy the `Client ID` and `Client Secret` from app page.
3. **Set the Variables in Remnawave**
3. **Set the Variables in Remnawave**
- `Client ID`
- `Client Secret`
- `Allowed Emails` — specify which GitHub email addresses can log in.
4. **Login Using GitHub**
After registration, return to the login page to test the new authentication method. Once confirmed, you can disable username/password login.
</details>
</details>
#### PocketID {#pocketid}
@@ -173,17 +173,16 @@ In `Administration` → `OIDC Clients`, click `Add OIDC Client`.
- `Callback URLs` — `https://panel.example.com/oauth2/callback/pocketid` (replace `panel.example.com` with your Panel domain).
2. **Get Client ID and Client Secret**
Copy the `Client ID` and `Client Secret`.
Copy the `Client ID` and `Client Secret`.
3. **Set the Variables in Remnawave**
3. **Set the Variables in Remnawave**
- `Client ID`
- `Client Secret`
- `Plain Domain` — plain domain for PocketID instance. Do not use any paths or protocols, just a plain domain (e.g., `pocketid.example.com`)
- `Allowed Emails` — add email addresses allowed to log in.
4. **Login Using PocketID**
Return to the login page to test the new authentication method. Once confirmed, you can disable username/password login.
</details>
</details>
#### Yandex ID {#yandexid}
@@ -201,16 +200,16 @@ Visit [Yandex ID page](https://oauth.yandex.com/client/new/id) to create an app.
- `Permissions` — only `Access to email address` is required.
2. **Get Client ID and Client Secret**
Once the Yandex ID app is created, you'll see app profile where you need to copy `Client ID` and `Client Secret`.
Once the Yandex ID app is created, you'll see app profile where you need to copy `Client ID` and `Client Secret`.
3. **Set the Variables in Remnawave**
3. **Set the Variables in Remnawave**
- `Client ID`
- `Client Secret`
- `Allowed Emails` — set the email adresses of the yandex accounts you wish to give access to. The account on yandex that logins in be registered to the email that you specified here.
- `Allowed Emails` — set the email adresses of the yandex accounts you wish to give access to. The account on yandex that logins in be registered to the email that you specified here.
4. **Login Using Yandex ID**
Return to the login page to test the new authentication method. Once confirmed, you can disable username/password login.
</details>
</details>
#### Telegram OAuth {#telegram}
@@ -220,22 +219,22 @@ You can log in with your Telegram account.
<summary>How to Set Up Telegram OAuth</summary>
1. **Create a Bot**
Message `/newbot` to [@BotFather](t.me/BotFather) and create a new bot. Copy its token.
Message `/newbot` to [@BotFather](https://t.me/BotFather) and create a new bot. Copy its token.
2. **Set Domain**
Message `/mybots`. Select the bot you created. The go to `Bot Settings` → `Domain` → `Set domain`.
Message the domain of your Panel. E.g. `https://panel.example.com`.
Message `/mybots`. Select the bot you created. The go to `Bot Settings` → `Domain` → `Set domain`.
Message the domain of your Panel. E.g. `https://panel.example.com`.
3. **Get Admin IDs**
Message `/start` to [@userinfobot](t.me/userinfobot). Copy the ID it responded with.
Message `/start` to [@userinfobot](https://t.me/userinfobot). Copy the ID it responded with.
4. **Set the Variables in Remnawave**
4. **Set the Variables in Remnawave**
- `Bot Token` — set the token of a bot you created earlier.
- `Allowed Admin IDs` — set the ID you got earlier from @userinfobot.
- `Allowed Admin IDs` — set the ID you got earlier from @userinfobot.
5. **Login Using Telegram Auth**
Return to the login page to test the new authentication method. Once confirmed, you can disable username/password login.
</details>
</details>
---

57
docs/learn-en/server-routing.md
View File

@@ -4,7 +4,7 @@ sidebar_position: 7
---
:::warning Demonstration Only | Not Production-Ready
This guide is meant purely as a demonstration of server-side routing. Do not assume that copying these examples will produce a fully functional setup in a production. It does not cover all capabilities of Xray-core, nor is it guaranteed to work perfectly in every environment.
This guide is meant purely as a demonstration of server-side routing. Do not assume that copying these examples will produce a fully functional setup in a production. It does not cover all capabilities of Xray-core, nor is it guaranteed to work perfectly in every environment.
For full details on configuration syntax and behavior, refer to the [official Xray documentation](https://xtls.github.io/config/).
:::
@@ -14,12 +14,14 @@ Some users may have noticed that Remnawave automatically clears the `clients` ar
---
In this guide, we'll walk through setting up server-side traffic routing using two Nodes: `RU` and `DE`. Users will connect to the `RU` Node. From there, the traffic will be routed as follows:
- Traffic to `.ru` websites will be proxied directly through the `RU` Node.
- All other traffic will be routed through the `DE` Node.
To achieve this, we'll create a _service user_ that will facilitate the traffic routing.
As a result, the traffic "flow" could look something like this:
1. The user opens `google.com`.
2. The request first reaches the `RU` Node.
3. The `RU` Node applies the routing rules. Since `google.com` is not a `.ru` domain, the traffic is routed to the `DE` Node.
@@ -49,11 +51,7 @@ Navigate to the Config Profiles section and [create a new Config Profile](/docs/
},
"sniffing": {
"enabled": true,
"destOverride": [
"http",
"tls",
"quic"
]
"destOverride": ["http", "tls", "quic"]
}
}
],
@@ -78,7 +76,7 @@ Navigate to the Config Profiles section and [create a new Config Profile](/docs/
---
[Create a new Internal Squad](/docs/learn-en/internal-squads#create-squad), let's call it `Bridge Squad`. Enable the Inbound we created earlier — `BRIDGE_DE_IN`.
[Create a new Internal Squad](/docs/learn-en/squads#create-internal-squad), let's call it `Bridge Squad`. Enable the Inbound we created earlier — `BRIDGE_DE_IN`.
:::
## Create a Service User {#create-service-user}
@@ -91,7 +89,7 @@ Since this is a service user, we obviously don't want its subscription to expire
Next, assign the appropriate Squad to this user. In our case, that's `Bridge Squad`.
After the service user is created, we will need to get its password. Open the user card, click on the `More Actions` button, then `Detailed Info`. There you should see `Connection Information` section.
After the service user is created, we will need to get its password. Open the user card, click on the `More Actions` button, then `Detailed Info`. There you should see `Connection Information` section.
Depending on the Inbound's protocol (Shadowsocks in our case), copy the appropriate value:
@@ -100,18 +98,17 @@ Depending on the Inbound's protocol (Shadowsocks in our case), copy the appropri
| Trojan | Trojan Password |
| VLESS | VLESS UUID |
| Shadowsocks | SS Password |
## Configure a Public Profile {#create-pub-profile}
Most likely, you already have a Config Profile that your users connect to. If not, refer to [this guide](/docs/learn-en/config-profiles).
Most likely, you already have a Config Profile that your users connect to. If not, refer to [this guide](/docs/learn-en/config-profiles).
For this step, we're not interested in the `"inbounds"` — instead, we'll be modifying the `"outbounds"`, `"routing"`, and `"rules"` arrays of that Profile.
```json title="Public Profile Example"
{
"log": {
"loglevel": "none"
"loglevel": "none"
},
"inbounds": [
{
@@ -125,11 +122,7 @@ For this step, we're not interested in the `"inbounds"` — instead, we'll be mo
},
"sniffing": {
"enabled": true,
"destOverride": [
"http",
"tls",
"quic"
]
"destOverride": ["http", "tls", "quic"]
},
"streamSettings": {
"network": "raw",
@@ -147,7 +140,7 @@ For this step, we're not interested in the `"inbounds"` — instead, we'll be mo
],
"outbounds": [
{
"protocol": "freedom",
"protocol": "freedom",
"tag": "DIRECT"
},
{
@@ -165,8 +158,8 @@ For this step, we're not interested in the `"inbounds"` — instead, we'll be mo
"domain": ["geosite:private"],
"outboundTag": "BLOCK"
},
{
"protocol": ["bittorrent"],
{
"protocol": ["bittorrent"],
"outboundTag": "BLOCK"
}
]
@@ -245,16 +238,12 @@ The complete public Config Profile could look like this:
"listen": "0.0.0.0",
"protocol": "vless",
"settings": {
"clients": [],
"decryption": "none"
"clients": [],
"decryption": "none"
},
"sniffing": {
"enabled": true,
"destOverride": [
"http",
"tls",
"quic"
]
"destOverride": ["http", "tls", "quic"]
},
"streamSettings": {
"network": "raw",
@@ -302,11 +291,11 @@ The complete public Config Profile could look like this:
"ip": ["geoip:private"],
"outboundTag": "BLOCK"
},
{
{
"domain": ["geosite:private"],
"outboundTag": "BLOCK"
},
{
{
"protocol": ["bittorrent"],
"outboundTag": "BLOCK"
},
@@ -332,22 +321,22 @@ Xray routing rules are processed in order, from **top to bottom**.
Here's how the rules in our example work:
1. Private IPs (`geoip:private`) → `BLOCK`
Traffic matching this rule is sent to the `BLOCK` Outbound, which is a `blackhole` protocol (completely blocked).
Traffic matching this rule is sent to the `BLOCK` Outbound, which is a `blackhole` protocol (completely blocked).
2. Private domains (`geosite:private`) → `BLOCK`
Same as above, but for domain names.
Same as above, but for domain names.
3. Bittorrent traffic (`bittorrent`) → `BLOCK`
All BitTorrent traffic is blocked.
All BitTorrent traffic is blocked.
4. Russian IPs (`geoip:ru`) → `DIRECT`
Traffic matching this rule is sent to the `DIRECT` Outbound, which is a `freedom` protocol (`RU` Node acts as an exit node).
Traffic matching this rule is sent to the `DIRECT` Outbound, which is a `freedom` protocol (`RU` Node acts as an exit node).
5. Russian domains (`geosite:category-ru`) → `DIRECT`
Traffic to Russian domains also goes directly out from the RU Node.
Traffic to Russian domains also goes directly out from the RU Node.
6. No rule match (the rest of the traffic) → `SS_OUTBOUND_TO_DE`
Any remaining traffic arriving at the `PUBLIC_RU_INBOUND` is routed to the `DE` Node via the `Shadowsocks` Outbound we created earlier.
Any remaining traffic arriving at the `PUBLIC_RU_INBOUND` is routed to the `DE` Node via the `Shadowsocks` Outbound we created earlier.
---