Neste exemplo, veremos como configurar o roteamento de servidor usando usuários de serviço no painel Remnawave.

Roteamento de servidor

Alguns usuários podem ter encontrado o problema de o Remnawave limpar automaticamente o array clients da configuração do servidor. Isso não é um erro nem um bug; o painel limpa automaticamente esses arrays porque, para que algumas funções do painel funcionem corretamente, ele precisa garantir que não haja nada desnecessário nesse array.

Vamos imaginar que temos dois servidores: RU-001 e DE-001.

Os usuários se conectarão ao servidor RU-001, realizaremos o roteamento do tráfego e, como exemplo, enviaremos os sites .ru diretamente e todo o resto para o servidor DE-001.

Para resolver essa tarefa, precisamos criar um usuário de serviço através do qual faremos o roteamento.

Criação do perfil para DE-001

Vá para a seção Config Profiles e crie um novo perfil, dando a ele o nome 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": []
    }
}

Salve a configuração atualizada.

Vá para a seção Internal Squad (para criar um novo squad, clique no ícone de mais no canto direito). Neste squad, ative apenas o inbound BRIDGE_DE_IN recém-criado do perfil Bridge Profile.

Certifique-se também de ativar este inbound e o perfil no cartão do nó — no nosso caso, o nó DE-001.

Criação do usuário de serviço

Vá para a seção Users e crie um usuário chamado bridge_user_001. Certifique-se de que este usuário não tenha limite de tráfego e defina a data de expiração da assinatura por volta do ano de 2099. (Não queremos que o painel desative o usuário por atingir o limite de tráfego ou porque a assinatura expirou.)

Não se esqueça de ativar o squad para este usuário — no nosso caso, ativamos o squad criado acima.

Após a criação bem-sucedida do usuário, abra seu cartão e no menu (botão More Actions) clique na seção Detailed Info.

Nesta seção, role até o final e, dependendo do tipo de inbound que você tem, copie as informações.

Protocolo	Denominação no painel
Shadowsocks	SS Password
VLESS	VLESS UUID
Trojan	Trojan Password

No final, você deve ter em mãos uma senha de conexão.

Configuração do perfil público

Provavelmente você já tem esse perfil e os usuários se conectam através dele. A seção inbounds não precisa ser alterada; o que nos interessa é a seção outbounds e routing.rules.

{
    "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 OWN VALUE!",
                    "show": false,
                    "xver": 0,
                    "shortIds": [""],
                    "privateKey": "USE OWN KEY!",
                    "serverNames": ["REPLACE WITH 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" }
        ]
    }
}

A tarefa inicial é: os usuários se conectam ao servidor RU-001 via protocolo VLESS, e então redirecionamos o tráfego por roteamento.

Outbound

Primeiro precisamos construir o outbound.

{
    "tag": "SS_OUTBOUND_TO_DE",
    "protocol": "shadowsocks",
    "settings": {
        "servers": [
            {
                "address": "ADDRESS OF DE-001",
                "password": "PASSWORD FROM PREVIOUS STEP",
                "port": 9999,
                "level": 0,
                "method": "chacha20-ietf-poly1305"
            }
        ]
    }
}

Valor	O que inserir?
address	IP ou nome de domínio apontando para seu servidor, por exemplo o endereço IP do servidor DE-001
port	Porta do inbound, no nosso caso a porta do inbound BRIDGE_DE_IN
password	Senha do usuário para conexão (os valores podem diferir dependendo do protocolo, veja acima)

No caso do Shadowsocks — não use nenhum método além de chacha20-ietf-poly1305, pois o Remnawave suporta apenas este método.

Roteamento

Exemplo de regra que envia todo o tráfego para o outbound indicado acima.

{
    "inboundTag": ["PUBLIC_RU_INBOUND"],
    "outboundTag": "SS_OUTBOUND_TO_DE"
}

Exemplo de regras que enviam sites RU diretamente (saída direta do nó RU-001) e tudo mais para DE-001.

      {
        "ip": [
          "geoip:ru"
        ],
        "outboundTag": "DIRECT"
      },
      {
        "domain": [
          "geosite:category-ru"
        ],
        "outboundTag": "DIRECT"
      }

Montamos a configuração completa, que ficará assim.

{
    "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 OWN VALUE!",
                    "show": false,
                    "xver": 0,
                    "shortIds": [""],
                    "privateKey": "USE OWN KEY!",
                    "serverNames": ["REPLACE WITH OWN VALUES!"]
                }
            }
        }
    ],
    "outbounds": [
        { "protocol": "freedom", "tag": "DIRECT" },
        { "protocol": "blackhole", "tag": "BLOCK" },
        {
            "tag": "SS_OUTBOUND_TO_DE",
            "protocol": "shadowsocks",
            "settings": {
                "servers": [
                    {
                        "address": "ADDRESS OF DE-001",
                        "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"
            }
        ]
    }
}

Adicionamos nosso outbound SS_OUTBOUND_TO_DE ao array outbounds e as regras ao array rules dentro do objeto routing.

As regras no Xray funcionam com base na ordem de prioridade. Nossas regras podem ser interpretadas aproximadamente assim:

1. Se o endereço IP pertencer a geoip:private — BLOCK (enviado para o outbound BLOCK, que é um blackhole e bloqueia a conexão).
2. Se o domínio pertencer à categoria geosite:private — mesmo tratamento.
3. O mesmo para o tráfego bittorrent.
4. Se o endereço IP pertencer a geoip:ru — enviado para o Outbound DIRECT, então o tráfego sairá do nosso servidor RU-001.
5. Se o domínio pertencer à categoria geosite:category-ru — também enviado para DIRECT.
6. Se o tráfego veio do inbound PUBLIC_RU_INBOUND — o enviamos para o outbound SS_OUTBOUND_TO_DE (e ele vai para o nosso servidor DE-001).

Conclusão

Neste exemplo, obtivemos o seguinte esquema:

• O usuário se conecta ao servidor RU-001 usando o protocolo VLESS
• O tráfego obedece às regras:
  • Sites (ou IPs) russos — saem diretamente (DIRECT)
  • Todo o restante do tráfego — é enviado via protocolo shadowsocks para o outro servidor DE-001

Também é possível usar VLESS como protocolo de trânsito; a principal diferença estará apenas no outbound.