All articles

Deploying Multi-Server VPN Infrastructure with RemnaWave: 10 Nodes & Best Server Architecture

vpndevopsremnawavevlessrealityhysteria2dockerlinuxnetworking

Deploying Multi-Server VPN Infrastructure with RemnaWave: 10 Nodes & Best Server Architecture

Modern routing constraints and protocol inspection require moving away from standalone proxy servers to resilient multi-node infrastructures. A single blocked IP address or localized upstream outage in a European data center should never disconnect users from the network.

This guide details the complete process of building a distributed VPN ecosystem using RemnaWave Panel with a cluster of 10 servers across diverse geographic regions (Germany, Netherlands, Latvia, Czech Republic, Sweden, Finland, USA), supporting VLESS + REALITY and Hysteria 2, alongside a production implementation of «⚡ Best Server» (dynamic client-side URL-testing and seamless failover).

1. Distributed Cluster Architecture

The infrastructure employs a Master-Worker topology, strictly decoupling management operations from high-throughput client proxying:

[ Master Server: RemnaWave Panel ]
  (Web UI, REST API, PostgreSQL 16, Redis, Subscription Engine)
       │
       ├── gRPC / TLS (Secure Management Tunnel)
       │
       ├── Worker 1: Germany - 1 (VLESS REALITY)
       ├── Worker 2: Germany - 2 (VLESS REALITY)
       ├── Worker 3: Germany - 3 (VLESS REALITY)
       ├── Worker 4: Netherlands - 1 (VLESS REALITY)
       ├── Worker 5: Netherlands - 2 (VLESS REALITY + Hysteria 2)
       ├── Worker 6: Riga / Latvia (VLESS REALITY)
       ├── Worker 7: Prague / Czech Republic (VLESS REALITY)
       ├── Worker 8: Sweden (VLESS REALITY)
       ├── Worker 9: Finland (VLESS REALITY)
       └── Worker 10: America / USA (VLESS REALITY)
Component System Role Technology Stack
Master Node (Panel) User authentication, billing, node telemetry, subscription delivery Docker, RemnaWave, PostgreSQL, Redis, Caddy
Worker Nodes (1–10) Inbound connection termination and traffic proxying RemnaWave Node Daemon, Xray-core, Sing-box
VLESS + REALITY Protocol Primary protocol camouflaged as legitimate TLS 1.3 TCP, XTLS Reality, X25519, SNI Camouflage
Hysteria 2 Protocol High-throughput UDP (QUIC) protocol for lossy mobile networks UDP, Salamander Obfuscation, BBR Congestion Control
Virtual «Best Server» Node Automatic node selection based on lowest latency and zero packet loss Client-side URL-Test / Fallback Proxy Group

2. Deploying the Master Server (RemnaWave Panel)

The master node processes zero client proxy traffic — it manages authentication, distributes configuration states to nodes, and serves dynamic subscriptions to client apps (Happ, v2rayN, Sing-box, Clash Meta, Streisand).

Step 2.1. OS Setup & Dependencies

On a clean Ubuntu 24.04 LTS VPS, install Docker and network utilities:

apt update && apt upgrade -y
apt install -y curl ufw git jq

# Install Docker and Docker Compose
curl -fsSL https://get.docker.com | sh
systemctl enable --now docker

Configure the baseline firewall (UFW):

ufw default deny incoming
ufw default allow outgoing
ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw allow 3000/tcp
ufw enable

Step 2.2. Docker Compose Configuration for RemnaWave

Create the working directory and compose configuration:

mkdir -p /opt/remnawave && cd /opt/remnawave

File /opt/remnawave/docker-compose.yml:

version: '3.8'

services:
  remnawave:
    image: remnawave/backend:latest
    container_name: remnawave-panel
    restart: always
    ports:
      - '3000:3000'
    environment:
      - NODE_ENV=production
      - DATABASE_URL=postgresql://remna:secure_db_pass@postgres:5432/remnawave
      - REDIS_URL=redis://redis:6379
      - JWT_SECRET=super_secret_jwt_key_random_generated_string_here
      - APP_PORT=3000
    depends_on:
      - postgres
      - redis

  postgres:
    image: postgres:16-alpine
    container_name: remnawave-postgres
    restart: always
    environment:
      POSTGRES_USER: remna
      POSTGRES_PASSWORD: secure_db_pass
      POSTGRES_DB: remnawave
    volumes:
      - postgres_data:/var/lib/postgresql/data

  redis:
    image: redis:7-alpine
    container_name: remnawave-redis
    restart: always
    volumes:
      - redis_data:/data

volumes:
  postgres_data:
  redis_data:

Step 2.3. Starting Services & Caddy Reverse Proxy

Launch the containers:

docker compose up -d

Install Caddy for automatic Let’s Encrypt SSL certificates and reverse proxying:

apt install -y debian-keyring debian-archive-keyring apt-transport-https
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | tee /etc/apt/sources.list.d/caddy-stable.list
apt update && apt install -y caddy

Configuration /etc/caddy/Caddyfile:

panel.yourdomain.com {
    reverse_proxy localhost:3000
}

Restart Caddy (systemctl restart caddy) to access the dashboard over HTTPS.

3. Worker Node Setup & Kernel Optimization

Each of the 10 worker nodes runs on a dedicated VPS with 1 Gbps networking. Pre-configuring the Linux kernel ensures maximum throughput and low jitter.

Step 3.1. Kernel Tuning & BBR Activation

On every worker VPS, apply network optimizations in /etc/sysctl.conf:

net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr
net.core.rmem_max = 67108864
net.core.wmem_max = 67108864
net.ipv4.tcp_rmem = 4096 87380 33554432
net.ipv4.tcp_wmem = 4096 65536 33554432
net.ipv4.tcp_fastopen = 3
net.ipv4.tcp_max_syn_backlog = 8192
net.core.somaxconn = 8192

Apply settings immediately:

sysctl -p

Step 3.2. Deploying RemnaWave Node Daemon

On each worker VPS, launch the lightweight RemnaWave node daemon:

mkdir -p /opt/remnawave-node && cd /opt/remnawave-node

File /opt/remnawave-node/docker-compose.yml:

version: '3.8'

services:
  node:
    image: remnawave/node:latest
    container_name: remnawave-node
    restart: always
    network_mode: host
    environment:
      - PANEL_URL=https://panel.yourdomain.com
      - NODE_SECRET_TOKEN=unique_node_token_generated_in_panel
      - PORT=2053

Start the node agent:

docker compose up -d

The node immediately appears as Connected in the web panel, reporting live latency, RAM utilization, and bandwidth metrics.

4. Protocol Configuration: VLESS REALITY & Hysteria 2

4.1. VLESS-TCP-REALITY Setup

REALITY provides state-of-the-art obfuscation: third-party active probing observes a genuine TLS 1.3 handshake against trusted domains (SNI).

  1. X25519 Key Generation: The panel generates a Private Key / Public Key pair and a unique Short ID (e.g., 16a8d0ef).
  2. Target SNI Selection: Select targets supporting TLS 1.3 and HTTP/2 physically co-located near the node (e.g., gateway.icloud.com, dl.google.com, swdist.apple.com, www.microsoft.com).
  3. Port: 443/TCP.

4.2. Hysteria 2 (UDP) on Netherlands-2 Node

For high packet-loss links (mobile networks, congested routes), configure Hysteria 2 on Netherlands - 2:

  • Protocol: Hysteria 2 (QUIC / UDP).
  • Port: 443/UDP (or port range 20000-50000/UDP for port hopping).
  • Obfuscation: Salamander password.
  • Self-signed or Let’s Encrypt certificate.

5. Deep Dive: How «⚡ Best Server» Works

At the top of the client server list sits the virtual node «⚡ Best Server». This is not a physical VPS, but a client-side dynamic testing and auto-failover group (URL-Test / Smart Failover).

                  ┌── [ Probe: http://gstatic.com/generate_204 ] ──┐
                  │                                                │
[ Inbound Traffic ] ──> [ URL-Test Group: ⚡ Best Server ] ────────┤
                                                                   ├──> Germany-1 (RTT: 42ms)  [ACTIVE]
                                                                   ├──> Germany-2 (RTT: 45ms)
                                                                   ├──> Netherlands-1 (RTT: 48ms)
                                                                   ├──> Riga (RTT: 62ms)
                                                                   └──> USA (RTT: 128ms)

URL-Test & Failover Mechanics

  1. Periodic Background Probing: The client application (Happ, Sing-box, Clash Meta / Mihomo) sends lightweight HTTP GET probes across all 10 nodes to a benchmark endpoint (http://www.gstatic.com/generate_204 or https://cp.cloudflare.com/generate_204) every 300 seconds.
  2. Metric Aggregation (RTT & Packet Loss): The client calculates Round Trip Time and records response success rates.
  3. Lowest Latency Routing: Traffic routes through the node with the fastest latency (e.g., Germany - 1 with 42 ms RTT).
  4. Seamless Auto-Failover: If the active node stops responding due to an upstream outage or routing block, the client switches sessions to the next healthy node (Germany - 2 or Netherlands - 1) without connection drops or user intervention.

Subscription Group Configuration (Sing-box / Clash Meta)

The RemnaWave subscription generator produces the following outbounds / proxy-groups structure:

{
    "tag": "⚡ Best Server",
    "type": "urltest",
    "outbounds": [
        "Germany",
        "Germany - 2",
        "Germany - 3",
        "Riga",
        "Prague",
        "Netherlands - 1",
        "Netherlands - 2",
        "Sweden",
        "Finland",
        "America"
    ],
    "url": "http://www.gstatic.com/generate_204",
    "interval": "5m",
    "tolerance": 50,
    "idle_timeout": "30m"
}

The tolerance: 50 threshold prevents jittery micro-switching between nodes with comparable pings (e.g., 42 ms vs 45 ms), ensuring stable TCP streams and uninterrupted VoIP calls.

6. Subscription Synchronization & Auto-Updates

  1. Profile Refresh Interval: The subscription response includes a profile-update-interval: 12 header, instructing clients to refresh node configurations every 12 hours.
  2. Quota & Expiry Headers: The panel emits Subscription-Userinfo: upload=...; download=...; total=...; expire=... headers, accurately reflecting account limits (as shown in the client profile: 678GB / ∞, expires 25.05.2027).
  3. Zero-Downtime Node Scaling: Adding an 11th node or replacing decommissioned hardware requires only a simple update in the RemnaWave panel. On the next subscription poll, all clients receive the updated cluster automatically.

7. Key Engineering Takeaways

  1. Decouple Control from Data Planes: Isolating the management panel on a master VPS ensures that individual worker outages never disrupt subscription delivery.
  2. Complementary Protocols: Pairing VLESS REALITY (unmatched TLS camouflage) with Hysteria 2 (high UDP throughput under packet loss) covers all network conditions.
  3. URL-Test Groups as a UX Standard: Client-side dynamic testing eliminates manual server switching and delivers a truly resilient connection experience.