VPN·HUB·CRACK
Маркет 0 ₽ +
Выйти?
VPN·HUB·CRACK Тройной каскад RU-RU-EU: спрятать белый IP · VPN HUB CRACK
Все статьи
Remnawave PRO Remnawave

Тройной каскад RU-RU-EU: спрятать белый IP

Обновлено 11 августа 2026 Проверено

Тройной каскад RU-RU-EU (спрятать белый IP)

Обычный каскад (см. «Каскад: вход в РФ, чистый выход») это два хопа: РФ-вход → загран-выход. Но у такой схемы РФ-вход сам коннектится за рубеж, и хостер этого сервера в своих логах видит постоянное исходящее соединение на иностранный IP. Для «расходного» входа это норм, но если у вас ценный/чистый белый IP, который надо беречь, это его палит.

📖 Незнакомые слова? Все термины простыми словами объяснены в Словаре терминов.

Тройной каскад добавляет ещё один РФ-хоп, чтобы белый IP вообще ничего не отправлял наружу:

Клиент ─▶ 🇷🇺 БЕЛЫЙ IP : вход, selfsteal     ← хостер видит только входящие, как веб-сайт
              │   (наружу НЕ ходит — только релеит на 2-й IP)
              ▼
         🇷🇺 2-й РФ-IP : расходник           ──sendThrough──▶ 🇪🇺 выход ─▶ интернет

Итог: хостер белого IP и ТСПУ видят только входящий Reality-трафик на домашний сайт. Все «подозрительные» исходящие коннекты за рубеж идут со второго IP, который не жалко. Белый IP остаётся репутационно чистым: он не попадает в abuse-листы как «VPN-релей за границу».

Когда использовать

  • Есть белый/чистый IP, который надо сохранить. Резидентский, «отлёжанный» датацентровый, IP с хорошей репутацией (как искать: MultiRoller, см. «MultiRoller: чистые IP»). Тройной каскад держит его «немым».
  • Хостер РФ-входа агрессивен к VPN. Если провайдер банит за исходящие VPN-туннели за рубеж, белый IP их не делает, делает 2-й IP (можно у другого хостера).
  • Максимальная стелс-задача. Когда «просто работает» мало, нужно «и работает, и белый вход выглядит идеально чистым».

Не нужен ради скорости: три хопа = +RTT и тройная нагрузка крипты. Если IP уже чистый и хостер лоялен, хватит прямой ноды или обычного 2-хоп каскада.

Два варианта топологии

Вариант Белый IP и 2-й IP Скрытие от хостера
A. Один бокс, два IP один сервер, два адреса на eth0 хостер видит оба IP (это один его сервер), но внешняя репутация белого IP чистая
B. Два РФ-сервера белый IP и 2-й IP у разных хостеров хостер белого IP вообще не видит загран-коннектов: их делает чужой сервер

Вариант B даёт полное скрытие от хостера белого IP. Вариант A проще (одна нода) и закрывает главное: внешнюю засветку белого IP. Ниже конфиг, который работает для обоих (в варианте A первые два инбаунда живут на одной ноде, во B на двух нодах).

Ключевой приём: sendThrough

Самое важное: outbound, который реально уходит за рубеж, должен исходить со второго IP, а не с белого (и не с «дефолтного» адреса сервера, который вообще может быть третьим).

"sendThrough": "SECOND_IP"   // ← заставляет Xray брать исходящим именно 2-й IP

Без sendThrough Xray возьмёт source-IP по таблице маршрутизации: на мульти-IP сервере это часто не тот адрес (дефолтный/«грязный»). Всегда явно пиньте sendThrough на 2-й IP на обоих каскадных outbound.

selfsteal на КАЖДОМ хопе (обязательно)

Для максимальной безопасности каждый хоп маскируется под ваш реальный сайт: serverNames = ваш домен (A-запись на этот IP), а Reality dest/target = локальный сайт-обманка. Тогда при активном прозвоне DPI/хостер попадают на настоящий HTTPS-сайт на вашем домене: вход неотличим от обычного веб-сервера.

Готовый установщик сайта-обманки (Caddy, ~8 шаблонов, серт) и ручной nginx-вариант смотрите в статье «Self-steal с nginx: Reality под вашим сайтом». Поднимите selfsteal на белом IP, на 2-м IP и на выходе, затем в конфиге укажите dest на локальный сокет/порт обманки (127.0.0.1:9443 или /dev/shm/nginx.sock).

⚠️ Тем же скриптом ставьте только сайт-обманку. Панель и ноды разворачивайте руками (почему: в той же статье).

⚠️ Грабли Remnawave: vision нельзя вкладывать в vision

Главный подводный камень тройного каскада. Remnawave принудительно добавляет flow=xtls-rprx-vision любому inbound'у вида tcp + reality (переопределить нельзя). А три vision-хопа подряд (vision-внутри-vision-внутри-vision) намертво виснут на объёмном трафике: соединение проходит рукопожатие и мелкие ответы, но любая крупная закачка встаёт через пару сотен байт (дедлок XTLS-splice). Симптом: «сайт открывается, файл не качается».

Решение (проверено): vision оставляем только на одном хопе, внутренние (relay) хопы переводим на grpc-reality: для grpc Remnawave flow не добавляет, vision не вкладывается.

  • Вход (белый IP): можно оставить tcp + reality + vision + selfsteal (это то, к чему коннектятся клиенты; для одного хопа vision ок).
  • 2-й IP и выход: grpc + reality + selfsteal (без flow). gRPC к тому же устойчивее на РФ→загран плече (ТСПУ душит raw/vision сильнее).

Reality-камуфляж (selfsteal через dest/serverNames) на grpc сохраняется полностью: транспорт спрятан внутри Reality-рукопожатия.

Готовый Config Profile

Один профиль на весь каскад. Инбаунды раскидываются по нодам привязкой (вход + 2-й IP → на RU-ноду; выход → на EU-ноду). Меняете только помеченные // ← значения. network: "raw" = новое имя tcp (равнозначно).

{
  "log": { "loglevel": "warning" },
  "dns": { "servers": ["1.1.1.1", "8.8.8.8"] },

  "inbounds": [
    {
      "tag": "ENTRY",                              // вход для КЛИЕНТОВ (белый IP)
      "listen": "WHITE_IP",                        // ← белый IP (на мульти-IP боксе обязателен listen)
      "port": 443,
      "protocol": "vless",
      "settings": { "clients": [], "decryption": "none" },   // clients заполнит панель из сквада
      "sniffing": { "enabled": true, "destOverride": ["http", "tls", "quic"] },
      "streamSettings": {
        "network": "tcp",                          // вход = tcp+vision+selfsteal (клиентам удобно)
        "security": "reality",
        "realitySettings": {
          "dest": "127.0.0.1:9443",                // ← локальный selfsteal-сайт (Caddy/nginx)
          "xver": 1,                               // PROXY-protocol -> реальный IP клиента в декой
          "shortIds": ["SID_ENTRY"],
          "privateKey": "PRIV_ENTRY",              // ← приватный ключ Reality входа
          "serverNames": ["entry.example.ru"]      // ← ваш домен, A-запись на белый IP
        }
      }
    },
    {
      "tag": "HOP2",                               // 2-й РФ-IP (внутренний хоп)
      "listen": "SECOND_IP",                       // ← второй IP
      "port": 443,
      "protocol": "vless",
      "settings": { "clients": [], "decryption": "none" },
      "sniffing": { "enabled": true, "destOverride": ["http", "tls", "quic"] },
      "streamSettings": {
        "network": "grpc",                         // relay-хоп = grpc (НЕ vision!)
        "security": "reality",
        "realitySettings": {
          "dest": "127.0.0.1:9443",                // ← selfsteal на 2-м IP
          "xver": 0,
          "shortIds": ["SID_HOP2"],
          "privateKey": "PRIV_HOP2",
          "serverNames": ["hop2.example.ru"]       // ← домен, A-запись на 2-й IP
        },
        "grpcSettings": { "serviceName": "cascadegrpc" }
      }
    },
    {
      "tag": "EXIT",                               // заграничный выход
      "listen": "0.0.0.0",
      "port": 443,
      "protocol": "vless",
      "settings": { "clients": [], "decryption": "none" },
      "sniffing": { "enabled": true, "destOverride": ["http", "tls", "quic"] },
      "streamSettings": {
        "network": "grpc",
        "security": "reality",
        "realitySettings": {
          "dest": "127.0.0.1:9443",                // ← selfsteal на выходе
          "xver": 0,
          "shortIds": ["SID_EXIT"],
          "privateKey": "PRIV_EXIT",
          "serverNames": ["exit.example.com"]      // ← домен, A-запись на EU-выход
        },
        "grpcSettings": { "serviceName": "cascadegrpc" }
      }
    }
  ],

  "outbounds": [
    { "tag": "DIRECT", "protocol": "freedom" },
    { "tag": "BLOCK",  "protocol": "blackhole" },
    {
      "tag": "to-hop2",                            // ВХОД -> 2-й IP (loopback / на 2-й сервер)
      "protocol": "vless",
      "sendThrough": "SECOND_IP",                  // ← наружу/на хоп идёт 2-й IP, НЕ белый
      "settings": { "vnext": [{
        "address": "SECOND_IP", "port": 443,
        "users": [{ "id": "BRIDGE_UUID", "encryption": "none" }]   // ← VLESS-UUID bridge-юзера
      }]},
      "streamSettings": {
        "network": "grpc",
        "security": "reality",
        "realitySettings": {
          "fingerprint": "firefox",
          "serverName": "hop2.example.ru",         // ← = serverNames инбаунда HOP2
          "publicKey": "PUB_HOP2",                 // ← publicKey пары HOP2
          "shortId": "SID_HOP2"
        },
        "grpcSettings": { "serviceName": "cascadegrpc" }
      }
    },
    {
      "tag": "to-exit",                            // 2-й IP -> заграничный выход
      "protocol": "vless",
      "sendThrough": "SECOND_IP",                  // ← коннект за рубеж исходит со 2-го IP
      "settings": { "vnext": [{
        "address": "EU_IP", "port": 443,
        "users": [{ "id": "BRIDGE_UUID", "encryption": "none" }]
      }]},
      "streamSettings": {
        "network": "grpc",
        "security": "reality",
        "realitySettings": {
          "fingerprint": "firefox",
          "serverName": "exit.example.com",        // ← = serverNames инбаунда EXIT
          "publicKey": "PUB_EXIT",                 // ← publicKey пары EXIT
          "shortId": "SID_EXIT"
        },
        "grpcSettings": { "serviceName": "cascadegrpc" }
      }
    }
  ],

  "routing": { "rules": [
    { "type": "field", "ip": ["geoip:private"],     "outboundTag": "BLOCK" },
    { "type": "field", "protocol": ["bittorrent"],  "outboundTag": "BLOCK" },
    { "type": "field", "inboundTag": ["ENTRY"],     "outboundTag": "to-hop2" },   // вход -> 2-й IP
    { "type": "field", "inboundTag": ["HOP2"],      "outboundTag": "to-exit" },   // 2-й IP -> выход
    { "type": "field", "inboundTag": ["EXIT"],      "outboundTag": "DIRECT" }     // выход -> интернет
  ]}
}

Логика маршрутизации завязана на inboundTag, поэтому один и тот же профиль безопасно раздаётся на обе ноды: на каждой ноде срабатывают только те правила, чьи инбаунды на ней реально запущены.

Сгенерировать ключи (по паре на каждый хоп): команда docker exec <нода> xray x25519 даёт privateKey (вставьте в инбаунд) и publicKey (Password, вставьте в publicKey соответствующего outbound). shortId берётся командой openssl rand -hex 8.

Ноды и привязка инбаундов (Remnawave)

  • Вариант A (один бокс, 2 IP): одна RU-нода, ей привязываете инбаунды ENTRY + HOP2 (они слушают разные IP благодаря listen). Плюс одна EU-нода с инбаундом EXIT.
  • Вариант B (два РФ-сервера): RU-нода-1 ← ENTRY, RU-нода-2 ← HOP2, EU-нода ← EXIT.
  • Менеджмент-адрес RU-ноды ставьте на 2-й IP (панель↔нода на :2222), чтобы на белом IP торчал только Reality :443 и больше ничего.
  • Клиентам в подписке отдаёте только вход (Host на инбаунд ENTRY, адрес = ваш домен входа). Хопы и выход скрыты.

bridge-юзер (техническая связка)

Каждый relay-хоп это обычная Reality-нода, принимает только «своих». Связку обеспечивает служебный bridge-юзер (как в «Каскад: вход в РФ, чистый выход»):

  1. Создайте пользователя bridge_user, выдайте всё безлимитом (трафик ∞, HWID ∞, бессрочно): через него идёт агрегированный трафик всех клиентов, упрётся в лимит → ляжет весь каскад.
  2. Добавьте его в сквад с инбаундами HOP2 и EXIT (но НЕ в сквад входа), так его UUID попадёт в clients этих инбаундов.
  3. Скопируйте его VLESS-UUID и вставьте в оба outbound (to-hop2 и to-exit) → users[0].id = BRIDGE_UUID.

Энд-юзеры (реальные клиенты) сидят в отдельном скваде только с инбаундом ENTRY.

Проверка: белый IP действительно молчит

Пустите через каскад закачку и посмотрите соединения на серверах (ss -tnp):

# на RU-сервере (или RU-ноде-2 в варианте B): плечо на выход должно ИСХОДИТЬ со 2-го IP
ss -tnp | grep ':443' | grep EU_IP        # должно быть: local=SECOND_IP -> EU_IP:443
ss -tnp | grep WHITE_IP | grep EU_IP      # ДОЛЖНО БЫТЬ ПУСТО — белый IP наружу не ходит
# на EU-выходе: пир должен быть 2-й IP, а не белый
ss -tnp | grep ':443'                     # peer = SECOND_IP, белого IP быть НЕ должно

Если плечо на выход исходит со SECOND_IP, а по белому IP наружу пусто, каскад собран правильно: хостеру и ТСПУ виден только чистый вход.

Если объёмный трафик встаёт (MTU)

На части РФ-маршрутов PMTU «чёрная дыра» (большие пакеты молча дропаются, мелкие проходят, закачка виснет). Лечится MSS-клампом на нодах:

for c in PREROUTING POSTROUTING; do
  iptables -t mangle -A $c -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1360
done

Сохранить через netfilter-persistent save или systemd-юнит, чтобы пережило ребут.

Связано

  • «Self-steal с nginx»: сайт-обманка для каждого хопа (скрипт-установщик).
  • «Каскад: вход в РФ, чистый выход»: базовый 2-хоп каскад, bridge-юзер, гибридный роутинг (РФ-сайты напрямую).
  • «MultiRoller: чистые IP»: где брать чистый белый IP и заграничный выход.
  • «Все рабочие конфиги»: Reality/selfsteal/grpc целиком.
  • «Заблокировали IP?»: что делать, если вход всё-таки попал под блок.
Связанные статьи
🔀Каскад РФ → выход 🔗РФ-релей (socat) 🪞Self-steal (nginx) 🎯MultiRoller ⚙️Готовые конфиги