Serverseitiges Routing
Dieser Leitfaden dient ausschließlich als Demonstration des serverseitigen Routings. Gehe nicht davon aus, dass das Kopieren dieser Beispiele eine vollständig funktionierende Konfiguration für den Produktionseinsatz ergibt. Er deckt nicht alle Fähigkeiten von Xray-core ab und ist nicht garantiert in jeder Umgebung einwandfrei zu funktionieren.
Für vollständige Details zur Konfigurationssyntax und zum Verhalten lies die offizielle Xray-Dokumentation.
Einige Benutzer haben möglicherweise bemerkt, dass Remnawave das clients-Array aus der Node-Konfiguration automatisch löscht. Dies ist kein Fehler, sondern ein beabsichtigtes Verhalten. Remnawave löscht es, um sicherzustellen, dass nur die notwendigen Konfigurationen für bestimmte Funktionen beibehalten werden.
In diesem Leitfaden richten wir das serverseitige Traffic-Routing mit zwei Nodes ein: RU und DE. Benutzer verbinden sich mit dem RU-Node. Von dort aus wird der Datenverkehr wie folgt weitergeleitet:
- Datenverkehr zu
.ru-Websites wird direkt über denRU-Node weitergeleitet. - Der gesamte übrige Datenverkehr wird über den
DE-Node weitergeleitet.
Um dies zu erreichen, erstellen wir einen Service-Benutzer, der das Traffic-Routing ermöglicht.
Der Datenverkehrsfluss könnte in etwa so aussehen:
- Der Benutzer öffnet
google.com. - Die Anfrage erreicht zunächst den
RU-Node. - Der
RU-Node wendet die Routing-Regeln an. Dagoogle.comkeine.ru-Domain ist, wird der Datenverkehr an denDE-Node weitergeleitet. - Der
DE-Node stellt die Verbindung zugoogle.comher.
Diese Art der serverseitigen Routing-Konfiguration wird oft als „Bridge" bezeichnet.
Konfigurationsprofil für DE erstellen
Navigiere zum Bereich Konfigurationsprofile und erstelle ein neues Konfigurationsprofil, z. B. DE Bridge Profile.
{
"log": {
"loglevel": "warning"
},
"dns": {},
"inbounds": [
{
"tag": "BRIDGE_DE_IN",
"port": 9999,
"listen": "0.0.0.0",
"protocol": "shadowsocks",
"settings": {
"clients": [],
"network": "tcp,udp"
},
"sniffing": {
"enabled": true,
"destOverride": ["http", "tls", "quic"]
}
}
],
"outbounds": [
{
"tag": "DIRECT",
"protocol": "freedom"
},
{
"tag": "BLOCK",
"protocol": "blackhole"
}
],
"routing": {
"rules": []
}
}
Weise das neu erstellte Konfigurationsprofil dem DE-Node zu. Wähle den BRIDGE_DE_IN-Inbound aus.
Erstelle eine neue interne Squad, nennen wir sie Bridge Squad. Aktiviere den zuvor erstellten Inbound — BRIDGE_DE_IN.
Service-Benutzer erstellen
Damit unsere Bridge funktioniert, müssen wir einen Benutzer erstellen. Nennen wir ihn bridge_user.
Da es sich um einen Service-Benutzer handelt, möchten wir natürlich nicht, dass sein Abonnement abläuft oder durch Traffic-Nutzung begrenzt wird. Setze Data Limit auf 0 und Expiry Date auf das Jahr 2099.
Weise diesem Benutzer anschließend die entsprechende Squad zu. In unserem Fall ist das Bridge Squad.
Nachdem der Service-Benutzer erstellt wurde, benötigen wir sein Passwort. Öffne die Benutzerkarte, klicke auf More Actions und dann auf Detailed Info. Dort sollte der Bereich Connection Information zu sehen sein.
Abhängig vom Protokoll des Inbounds (in unserem Fall Shadowsocks) kopiere den entsprechenden Wert:
| Protokoll | Verbindungsinfo-Wert |
|---|---|
| Trojan | Trojan-Passwort |
| VLESS | VLESS UUID |
| Shadowsocks | SS-Passwort |
Öffentliches Profil konfigurieren
Wahrscheinlich hast du bereits ein Konfigurationsprofil, mit dem sich deine Benutzer verbinden. Falls nicht, lies diesen Leitfaden.
In diesem Schritt sind wir nicht an den "inbounds" interessiert — stattdessen werden wir die Arrays "outbounds", "routing" und "rules" dieses Profils anpassen.
{
"log": {
"loglevel": "none"
},
"inbounds": [
{
"tag": "PUBLIC_RU_INBOUND",
"port": 443,
"listen": "0.0.0.0",
"protocol": "vless",
"settings": {
"clients": [],
"decryption": "none"
},
"sniffing": {
"enabled": true,
"destOverride": ["http", "tls", "quic"]
},
"streamSettings": {
"network": "raw",
"security": "reality",
"realitySettings": {
"target": "USE YOUR OWN VALUE!",
"show": false,
"xver": 0,
"shortIds": [""],
"privateKey": "USE YOUR OWN KEY!",
"serverNames": ["USE YOUR OWN VALUES!"]
}
}
}
],
"outbounds": [
{
"protocol": "freedom",
"tag": "DIRECT"
},
{
"protocol": "blackhole",
"tag": "BLOCK"
}
],
"routing": {
"rules": [
{
"ip": ["geoip:private"],
"outboundTag": "BLOCK"
},
{
"domain": ["geosite:private"],
"outboundTag": "BLOCK"
},
{
"protocol": ["bittorrent"],
"outboundTag": "BLOCK"
}
]
}
}
Outbounds
Zunächst müssen wir das outbounds-Array anpassen.
{
"tag": "SS_OUTBOUND_TO_DE",
"protocol": "shadowsocks",
"settings": {
"servers": [
{
"address": "DE NODE ADDRESS",
"password": "PASSWORD FROM PREVIOUS STEP",
"port": 9999,
"level": 0,
"method": "chacha20-ietf-poly1305"
}
]
}
}
| Feld | Wert |
|---|---|
address | Die IP-Adresse oder der Domainname deines DE-Node-Servers. |
port | Der Inbound-Port, in unserem Fall der Port von BRIDGE_DE_IN. |
password | Das Passwort für den Service-Benutzer. Abhängig vom verwendeten Protokoll; siehe vorherigen Schritt. |
method | Verschlüsselungsmethode. Für Shadowsocks in Remnawave immer chacha20-ietf-poly1305 verwenden. |
Routing und Regeln
Passe als Nächstes die Routing-Regeln deinen Anforderungen entsprechend an.
Unten ist ein Beispiel einer Regel, die den RU-Node zum Exit-Node für russische IPs und Websites macht, während der restliche Datenverkehr an den DE-Node gesendet wird.
{
"ip": ["geoip:ru"],
"outboundTag": "DIRECT"
},
{
"domain": ["geosite:category-ru"],
"outboundTag": "DIRECT"
}
Unten ist ein Beispiel einer Regel, die den gesamten Datenverkehr an den SS_OUTBOUND_TO_DE-Outbound weiterleitet.
{
"inboundTag": ["PUBLIC_RU_INBOUND"],
"outboundTag": "SS_OUTBOUND_TO_DE"
}
Das vollständige öffentliche Konfigurationsprofil könnte so aussehen:
{
"log": {
"loglevel": "none"
},
"inbounds": [
{
"tag": "PUBLIC_RU_INBOUND",
"port": 443,
"listen": "0.0.0.0",
"protocol": "vless",
"settings": {
"clients": [],
"decryption": "none"
},
"sniffing": {
"enabled": true,
"destOverride": ["http", "tls", "quic"]
},
"streamSettings": {
"network": "raw",
"security": "reality",
"realitySettings": {
"target": "USE YOUR OWN VALUE!",
"show": false,
"xver": 0,
"shortIds": [""],
"privateKey": "USE YOUR OWN KEY!",
"serverNames": ["USE YOUR OWN VALUES!"]
}
}
}
],
"outbounds": [
{
"protocol": "freedom",
"tag": "DIRECT"
},
{
"protocol": "blackhole",
"tag": "BLOCK"
},
{
"tag": "SS_OUTBOUND_TO_DE",
"protocol": "shadowsocks",
"settings": {
"servers": [
{
"address": "DE NODE ADDRESS",
"password": "PASSWORD FROM PREVIOUS STEP",
"port": 9999,
"level": 0,
"method": "chacha20-ietf-poly1305"
}
]
}
}
],
"routing": {
"rules": [
{
"ip": ["geoip:private"],
"outboundTag": "BLOCK"
},
{
"domain": ["geosite:private"],
"outboundTag": "BLOCK"
},
{
"protocol": ["bittorrent"],
"outboundTag": "BLOCK"
},
{
"ip": ["geoip:ru"],
"outboundTag": "DIRECT"
},
{
"domain": ["geosite:category-ru"],
"outboundTag": "DIRECT"
},
{
"inboundTag": ["PUBLIC_RU_INBOUND"],
"outboundTag": "SS_OUTBOUND_TO_DE"
}
]
}
}
Xray-Routing-Regeln werden der Reihe nach verarbeitet, von oben nach unten.
So funktionieren die Regeln in unserem Beispiel:
-
Private IPs (
geoip:private) →BLOCK
Datenverkehr, der dieser Regel entspricht, wird an denBLOCK-Outbound gesendet, das ist einblackhole-Protokoll (vollständig blockiert). -
Private Domains (
geosite:private) →BLOCK
Wie oben, aber für Domainnamen. -
BitTorrent-Datenverkehr (
bittorrent) →BLOCK
Gesamter BitTorrent-Datenverkehr wird blockiert. -
Russische IPs (
geoip:ru) →DIRECT
Datenverkehr, der dieser Regel entspricht, wird an denDIRECT-Outbound gesendet, das ist einfreedom-Protokoll (derRU-Node fungiert als Exit-Node). -
Russische Domains (
geosite:category-ru) →DIRECT
Datenverkehr zu russischen Domains geht ebenfalls direkt vom RU-Node aus. -
Keine Regel passt (der restliche Datenverkehr) →
SS_OUTBOUND_TO_DE
Jeglicher verbleibende Datenverkehr, der amPUBLIC_RU_INBOUNDankommt, wird über den zuvor erstelltenShadowsocks-Outbound an denDE-Node weitergeleitet.
Du musst nicht Shadowsocks als Transitprotokoll verwenden — du kannst stattdessen auch VLESS nutzen. Achte nur darauf, deine Konfiguration entsprechend anzupassen.