Каскад двух VPS
Remnawave
Последовательно пройдите все шаги. Сначала прочитайте объяснение, затем выполните действие и проверьте результат.
Содержание
Что мы будем строить
Зачем это нужно
Перед началом важно понимать путь пакетов: это исключает путаницу между сервером, панелью и клиентом.
Что делать
Схема: телефон → VPS №1 → VPS №2 → интернет. Первый сервер принимает VPN, второй выходит в интернет. Подготовьте два независимых VPS.
✓ Как проверить: Запишите схему и назначение каждого VPS на бумаге.
Как подключиться по SSH
Зачем это нужно
SSH — удалённая командная строка сервера.
Что делать
Откройте Termius или терминал. Создайте подключение: Address — публичный IP VPS; Port — 22, если провайдер не указал иной; Username — root или предоставленный пользователь. Сверьте отпечаток ключа сервера с информацией провайдера. Для каскада повторите на обоих VPS.
Команды для терминала
whoami
hostname
cat /etc/os-release✓ Как проверить: Появляется приглашение терминала и версия Ubuntu.
Если не получилось: Если Connection timed out — проверьте IP, порт и сетевой экран. Если Permission denied — проверьте имя пользователя и ключ.
Проверяем систему без изменений
Зачем это нужно
Не устанавливайте вторую панель поверх работающей: можно занять те же порты и потерять сервис.
Что делать
Выполните команды только для просмотра. Обратите внимание на 80, 443, 2053, 8443 и порт SSH. Если сервер уже используется, лучше взять чистый тестовый VPS.
Команды для терминала
ss -lntup
ip -br addr
ip route
df -h✓ Как проверить: Вы видите список занятых портов, интерфейсов и свободное место.
Если не получилось: Если порт занят, не останавливайте неизвестный процесс. Узнайте, какая служба его использует.
Устанавливаем Remnawave по официальному руководству
Зачем это нужно
Remnawave обычно разделяет панель и ноды, поэтому один случайный скрипт из интернета может не подойти.
Что делать
На чистом тестовом VPS откройте раздел Installation официальной документации Remnawave. Проверьте требования к Docker/Compose, переменным окружения, доменам и HTTPS. Выполните команды именно для выбранной версии; сохраните секреты вне публичной документации.
Команды для терминала
docker --version
docker compose version✓ Как проверить: Панель доступна по защищённому адресу, а контейнеры работают.
Если не получилось: Если контейнер не стартует, смотрите docker compose logs; не удаляйте тома с данными.
Первоисточник: https://docs.rw/
Создаём ноду и связываем с панелью
Зачем это нужно
Панель сама по себе не принимает VPN-трафик: нужна Xray-нода.
Что делать
В Remnawave откройте раздел Nodes, создайте ноду, получите данные подключения/токен и настройте Remnawave Node по инструкции именно вашей версии. Не вставляйте токен в общедоступный чат или скриншот.
Команды для терминала
docker ps --format "table {{.Names}}\t{{.Status}}"✓ Как проверить: Нода отображается онлайн в панели.
Если не получилось: При статусе Offline проверьте адрес панели, токен, TLS, DNS и логи ноды.
Первоисточник: https://docs.rw/
Выбираем межсерверный транспорт
Зачем это нужно
Панель управляет пользователями, но не всегда умеет автоматически построить полный каскад.
Что делать
Для понятной и проверяемой схемы используйте WireGuard между VPS №1 и VPS №2, а Xray на входном сервере направляйте через этот туннель. В этой статье показана сетевая часть; способ привязки Xray к туннелю зависит от панели и версии.
✓ Как проверить: Вы выбрали WireGuard и понимаете, что это отдельный компонент.
Устанавливаем WireGuard на оба VPS
Зачем это нужно
WireGuard создаёт зашифрованную связь между серверами.
Что делать
Выполните команду отдельно на VPS №1 и VPS №2. Установка не изменяет маршруты автоматически.
Команды для терминала
sudo apt install -y wireguard
wg --version✓ Как проверить: Команда wg --version показывает установленную версию.
Если не получилось: Если пакет недоступен, проверьте apt update и репозитории Ubuntu.
Генерируем ключи WireGuard
Зачем это нужно
У каждого VPS собственная пара ключей. Приватные ключи нельзя передавать третьим лицам.
Что делать
На КАЖДОМ сервере отдельно создайте ключи. Не копируйте один и тот же приватный ключ на оба сервера. Публичные ключи можно обменять между VPS.
Команды для терминала
sudo install -m 700 -d /etc/wireguard
umask 077
wg genkey | sudo tee /etc/wireguard/privatekey | wg pubkey | sudo tee /etc/wireguard/publickey >/dev/null
sudo cat /etc/wireguard/publickey✓ Как проверить: На каждом сервере есть разные публичные ключи.
Если не получилось: Никогда не вставляйте privatekey в скриншоты и публичные инструкции.
Планируем адреса туннеля
Зачем это нужно
Адреса внутри туннеля должны отличаться от Docker-сетей и домашних подсетей.
Что делать
В примере используем 10.77.77.1/30 для VPS №1 и 10.77.77.2/30 для VPS №2. Сначала проверьте, что 10.77.77.0/30 не используется в вашей инфраструктуре.
Команды для терминала
ip -4 route
docker network ls 2>/dev/null || true✓ Как проверить: Подсеть не пересекается с существующими маршрутами.
Если не получилось: Если пересекается, выберите другую частную /30 подсеть и замените адреса в обоих конфигурациях.
Настраиваем WireGuard на VPS №2
Зачем это нужно
Выходной сервер принимает зашифрованный трафик от первого VPS.
Что делать
Создайте /etc/wireguard/wg0.conf на VPS №2: Interface Address=10.77.77.2/30, ListenPort=51820, PrivateKey=его приватный ключ; Peer PublicKey=публичный ключ VPS №1, AllowedIPs=10.77.77.1/32. Ключи подставляйте из локальных файлов. Не копируйте текст с угловыми скобками буквально.
Команды для терминала
sudo nano /etc/wireguard/wg0.conf
sudo chmod 600 /etc/wireguard/wg0.conf✓ Как проверить: Файл существует и доступен только root.
Если не получилось: Если nano не установлен, установите sudo apt install -y nano.
Настраиваем WireGuard на VPS №1
Зачем это нужно
Входной сервер должен знать, куда отправлять пакеты второго сервера.
Что делать
Создайте /etc/wireguard/wg0.conf на VPS №1: Interface Address=10.77.77.1/30, PrivateKey=его приватный ключ; Peer PublicKey=ключ VPS №2, Endpoint=публичный_IP_VPS2:51820, AllowedIPs=10.77.77.2/32, PersistentKeepalive=25. Не ставьте AllowedIPs=0.0.0.0/0 на этапе проверки: можно потерять SSH.
Команды для терминала
sudo nano /etc/wireguard/wg0.conf
sudo chmod 600 /etc/wireguard/wg0.conf✓ Как проверить: В конфигурации VPS №1 указан публичный адрес VPS №2.
Если не получилось: Проверьте отсутствие лишних пробелов в ключах и правильность Endpoint.
Запускаем туннель и проверяем handshake
Зачем это нужно
Handshake показывает, что серверы договорились о ключах.
Что делать
Сначала разрешите UDP 51820 в firewall провайдера на VPS №2 только с IP VPS №1. Затем на обоих VPS запустите wg-quick@wg0.
Команды для терминала
sudo systemctl enable --now wg-quick@wg0
sudo wg show
ping -c 3 10.77.77.2✓ Как проверить: На VPS №1 в wg show виден latest handshake и ping до 10.77.77.2 проходит.
Если не получилось: Если handshake отсутствует, проверьте UDP firewall, Endpoint и пары публичных ключей.
Разрешаем маршрутизацию на VPS №2
Зачем это нужно
Чтобы VPS №2 стал выходом в интернет, ядро должно пересылать пакеты.
Что делать
На VPS №2 включите net.ipv4.ip_forward. Перед NAT узнайте имя внешнего интерфейса (например, ens3) через ip route. Не вставляйте ens3 без проверки.
Команды для терминала
echo "net.ipv4.ip_forward=1" | sudo tee /etc/sysctl.d/90-pelmeni-forward.conf
sudo sysctl --system
ip route get 1.1.1.1✓ Как проверить: net.ipv4.ip_forward = 1; известен внешний интерфейс.
Если не получилось: Если используется собственный firewall, сохраните его конфигурацию перед изменениями.
NAT на выходном VPS
Зачем это нужно
Частные адреса WireGuard не маршрутизируются напрямую в интернет.
Что делать
На VPS №2 нужен SNAT/MASQUERADE для подсети туннеля через внешний интерфейс. В Ubuntu это можно сделать через nftables, но правила зависят от действующего firewall. Сначала изучите текущие правила; не сбрасывайте их.
Команды для терминала
sudo nft list ruleset
ip route get 1.1.1.1✓ Как проверить: Вы видите действующие правила и можете добавить узкое правило MASQUERADE без удаления других.
Если не получилось: Не выполняйте nft flush ruleset: это может оборвать SSH и другие сервисы.
Направляем трафик Xray в туннель
Зачем это нужно
Один только WireGuard не означает, что клиенты VPN идут через VPS №2.
Что делать
В Remnawave используйте поддерживаемый механизм outbound/routing для ноды, в 3x-ui — раздел Xray Outbounds и Routing (названия зависят от версии). Для маршрутизации через системный WireGuard нужен отдельный outbound или политика маршрутизации; не меняйте default route VPS без консоли восстановления.
✓ Как проверить: Тестовый клиент использует нужный outbound; SSH к VPS №1 не теряется.
Первоисточник: https://docs.rw/
Проверяем работу через внешний IP
Зачем это нужно
Внешний IP показывает, через какой сервер трафик покидает сеть.
Что делать
На телефоне с включённым VPN откройте сервис определения IP. В каскаде адрес должен совпадать с публичным IP VPS №2, в одиночной схеме — с IP VPN-сервера. Также проверьте DNS и IPv6, если они включены.
Команды для терминала
curl -4 https://api.ipify.org; echo✓ Как проверить: Адрес соответствует ожидаемому выходному узлу.
Если не получилось: Если виден IP провайдера телефона — VPN не используется или приложение настроено на обход.
Проверяем журналы и ошибки
Зачем это нужно
По логам можно отличить ошибку авторизации от ошибки сети.
Что делать
В Remnawave откройте журналы ноды и контейнеров; в 3x-ui — журналы x-ui/Xray. Проверяйте только последние строки и не публикуйте полные логи с токенами и адресами клиентов.
Команды для терминала
docker ps
docker logs --tail 80 <имя_контейнера>✓ Как проверить: Нет повторяющихся критических ошибок при тестовом подключении.
Если не получилось: Если встречается bind: address already in use — порт уже занят; если invalid config — проверьте поля inbound.
Типовые проблемы и порядок диагностики
Зачем это нужно
Бессистемная замена настроек обычно ухудшает ситуацию.
Что делать
Проверяйте по цепочке: DNS → доступность порта → состояние панели/ноды → Xray inbound → ключи и SNI → маршрут/туннель → DNS клиента. После каждого исправления меняйте только один параметр и повторяйте тест.
Команды для терминала
getent hosts example.com
ss -lntup
ip route✓ Как проверить: Вы определили конкретный этап, на котором соединение ломается.
Если не получилось: Если всё работало до изменения, восстановите резервную копию этого изменения.
Резервные копии и обновления
Зачем это нужно
Без копии настроек обновление может привести к потере пользователей и ключей.
Что делать
Сохраните конфигурации панели, базы пользователей и приватные ключи в зашифрованном хранилище. Перед обновлением читайте release notes, проверяйте совместимость ноды и панели, тестируйте восстановление на отдельном сервере.
✓ Как проверить: Есть резервная копия и записанная процедура восстановления.
Первоисточник: https://docs.rw/
Финальная проверка и памятка читателю
Зачем это нужно
Готовая инструкция должна завершаться воспроизводимым результатом.
Что делать
Проверьте подключение с мобильного интернета и Wi-Fi, внешний IP, DNS, доступность сайта, перезапуск служб и возможность войти по SSH. Запишите версии Xray, панели и Ubuntu, порты и даты обновления — без паролей и приватных ключей.
✓ Как проверить: Другой человек может повторить настройку по вашей записи, а вы можете восстановить доступ после ошибки.
Дополнительные официальные источники
Xray / XTLS · WireGuard Quick Start · Ubuntu Server
Практикум: от чистого VPS до проверки
Ниже не общие советы, а действия с командами, ожидаемыми результатами и диагностикой. Все примеры выполняйте на отдельных тестовых VPS, не на сервере с работающими сервисами.
Подготовьте чистый тестовый сервер
Что это и зачем
Рабочий сервер с действующим VPN нельзя использовать как полигон: установщик может занять порт или изменить сеть.
Действия по порядку
- Возьмите отдельный VPS с Ubuntu 24.04 и публичным IPv4.
- Сохраните IP, логин SSH и способ входа через веб-консоль провайдера.
- Подключитесь через Termius: Host = IP, Port = 22 (или указанный провайдером), Username = root либо выданный пользователь.
- Перед первым подключением проверьте отпечаток SSH-ключа по консоли провайдера.
Команда или пример конфигурации
whoami && cat /etc/os-release && uname -m
ss -lntupПравильный результат: Видна Ubuntu, архитектура и список уже занятых портов.
Если возникла ошибка: Если порт 443 занят, не останавливайте процесс вслепую: нужен другой VPS или согласованная схема с веб-сервером.
Подготовьте необходимые утилиты
Что это и зачем
Пакетный менеджер apt ставит программы из репозиториев Ubuntu. Обновление списка пакетов не равно обновлению всей ОС.
Действия по порядку
- Убедитесь, что подключены к нужному тестовому VPS.
- Вставьте команды по одной.
- Дождитесь завершения apt; не закрывайте терминал во время установки.
Команда или пример конфигурации
sudo apt update
sudo apt install -y curl ca-certificates openssl jq nano dnsutilsПравильный результат: Команда curl --version показывает версию.
Если возникла ошибка: Если apt сообщает о блокировке, дождитесь завершения автоматического обновления; не удаляйте lock-файлы.
Подготовьте домен и DNS
Что это и зачем
A-запись связывает доменное имя с IPv4. REALITY может использовать чужой target для маскировки, но собственный сайт требует своего домена.
Действия по порядку
- В личном кабинете регистратора откройте DNS-зону.
- Создайте A-запись vpn.example.com, указывающую на IP вашего VPS.
- Подождите распространения DNS и проверьте ответ.
- Во всех следующих примерах заменяйте example.com на собственный домен; не вводите пример буквально.
Команда или пример конфигурации
dig +short A vpn.example.com @1.1.1.1
curl -4 https://api.ipify.org; echoПравильный результат: DNS возвращает IP нужного VPS.
Если возникла ошибка: Если DNS пустой, проверьте NS-записи и правильность имени; не путайте A и CNAME.
Проверьте доступность порта
Что это и зачем
На одном IP и одном TCP-порту обычно может слушать только один процесс. Для REALITY нужен свободный входной порт; панель управления должна работать отдельно.
Действия по порядку
- На сервере посмотрите занятые TCP-порты.
- Выберите свободный порт, например 24443; проверьте, что провайдер разрешает входящие TCP на нём.
- Не открывайте административный порт панели всем подряд: ограничьте его по IP либо используйте SSH-туннель.
Команда или пример конфигурации
sudo ss -lntp | grep -E ":(22|80|443|24443|2053)\b" || trueПравильный результат: Выбранный порт не занят; SSH остаётся доступным.
Если возникла ошибка: Если команда показывает LISTEN на выбранном порту, выберите другой и используйте его одинаково в панели и клиенте.
Установите Remnawave Panel по официальной схеме
Что это и зачем
Remnawave состоит из панели и ноды. Панель хранит пользователей и профили, нода запускает Xray. Для панели рекомендованы 2+ CPU, 2+ ГБ RAM и отдельная нода.
Действия по порядку
- Используйте отдельный тестовый VPS под панель и другой VPS под ноду.
- Установите Docker Engine и Compose plugin согласно официальной инструкции Docker для Ubuntu.
- Откройте https://docs.rw/install/remnawave-panel/ и скачайте production compose и пример .env.
- Заполните .env по таблице официальной документации, создайте случайные секреты и установите домены/HTTPS. Не публикуйте .env.
- Запустите контейнеры и проверьте журналы.
Команда или пример конфигурации
sudo docker --version
sudo docker compose version
sudo mkdir -p /opt/remnawave && cd /opt/remnawave
sudo curl -fLo docker-compose.yml https://raw.githubusercontent.com/remnawave/backend/refs/heads/main/docker-compose-prod.yml
sudo curl -fLo .env https://raw.githubusercontent.com/remnawave/backend/refs/heads/main/.env.sample
sudo nano .env
sudo docker compose up -d
sudo docker compose psПравильный результат: Все обязательные контейнеры панели работают, HTTPS панели доступен.
Если возникла ошибка: Если compose не стартует, смотрите docker compose logs --tail 100. Не используйте готовые значения секретов и не удаляйте тома базы.
Создайте Remnawave Node
Что это и зачем
Нода принимает VPN-подключения. Она регистрируется в панели через уникальную конфигурацию Compose.
Действия по порядку
- В панели откройте Nodes → Management → +.
- Укажите имя и Node Port — это порт внутреннего API, не клиентский порт REALITY.
- Нажмите Copy docker-compose.yml.
- На отдельном VPS ноды создайте /opt/remnanode/docker-compose.yml и вставьте именно сгенерированное содержимое.
- Запустите контейнер и в мастере панели выберите Config Profile, затем Create.
- Ограничьте доступ к Node Port IP-адресом панели.
Команда или пример конфигурации
sudo mkdir -p /opt/remnanode
cd /opt/remnanode
sudo nano docker-compose.yml
sudo docker compose up -d
sudo docker compose ps
sudo docker compose logs --tail 60Правильный результат: В Nodes статус ноды Online.
Если возникла ошибка: Если Offline, проверьте DNS, Node Port, токен в compose и firewall; не выкладывайте compose в общий доступ.
Настройте профиль Xray для REALITY
Что это и зачем
Config Profile определяет inbound и outbound Xray, а Host определяет параметры клиентской подписки. Это разные сущности.
Действия по порядку
- Откройте Config Profiles и создайте тестовый профиль.
- Добавьте VLESS inbound на свободный порт 24443 с transport TCP/RAW, security REALITY и flow xtls-rprx-vision.
- Сгенерируйте x25519 private/public key и Short ID, выберите допустимый target:443 и SNI.
- Привяжите профиль к созданной ноде.
- Создайте Host с IP/доменом ноды, портом, SNI, public key и short ID, соответствующими inbound.
- Создайте тестового пользователя, выдайте ему подписку и импортируйте в Xray-клиент.
Команда или пример конфигурации
sudo ss -lntp | grep 24443 || true
cd /opt/remnanode && sudo docker compose logs --tail 80Правильный результат: Нода Online, inbound слушает выбранный порт, клиент подключается.
Если возникла ошибка: При неработающей подписке сравните Host и inbound: порт, public key, shortId, SNI, flow. Версии UI могут различаться; сверяйте https://docs.rw/.
Схема каскада без изменения default route
Что это и зачем
Чтобы не потерять SSH, нельзя наугад перенаправлять весь трафик VPS A в WireGuard. Безопаснее сначала создать отдельный туннель A↔B и направлять через него только исходящие соединения Xray.
Действия по порядку
- Назовите VPS A входным сервером, VPS B выходным.
- Публичный IP B — тот, который должен видеть сайт проверки IP.
- Межсерверная подсеть примера 10.77.77.0/30: A = 10.77.77.1, B = 10.77.77.2.
- На обоих VPS проверьте пересечения с Docker и другими VPN-сетями.
Команда или пример конфигурации
ip -4 route
sudo apt update && sudo apt install -y wireguard
sudo install -d -m 700 /etc/wireguard
umask 077
wg genkey | sudo tee /etc/wireguard/privatekey | wg pubkey | sudo tee /etc/wireguard/publickey >/dev/null
sudo cat /etc/wireguard/publickeyПравильный результат: На A и B созданы разные ключи; публичные ключи можно обменять.
Если возникла ошибка: Не публикуйте /etc/wireguard/privatekey. Не выполняйте wg-quick up до проверки обоих конфигов.
Создайте конфигурацию туннеля на VPS B
Что это и зачем
B принимает UDP-соединение от A. В этом минимальном туннеле не включается системная переадресация всего трафика; для выхода Xray используется отдельный SOCKS-прокси на B.
Действия по порядку
- Сохраните публичный ключ A.
- На B создайте /etc/wireguard/wg0.conf. Вместо меток подставьте реальные ключи.
- В firewall провайдера B разрешите UDP 51820 только с публичного IP A.
- Проверьте конфигурацию перед запуском.
Команда или пример конфигурации
[Interface]
Address = 10.77.77.2/30
ListenPort = 51820
PrivateKey = <ПРИВАТНЫЙ_КЛЮЧ_B>
[Peer]
PublicKey = <ПУБЛИЧНЫЙ_КЛЮЧ_A>
AllowedIPs = 10.77.77.1/32Правильный результат: Файл chmod 600, ключи не содержат угловых скобок.
Если возникла ошибка: Команды с угловыми скобками — образец, не вставляйте буквально.
Создайте конфигурацию туннеля на VPS A
Что это и зачем
A знает публичный адрес B и шифрует трафик к внутреннему адресу 10.77.77.2.
Действия по порядку
- Сохраните публичный ключ B.
- На A создайте /etc/wireguard/wg0.conf.
- В Endpoint укажите настоящий публичный IP B и порт 51820.
- Установите права 600 и запустите туннель на обоих серверах.
Команда или пример конфигурации
[Interface]
Address = 10.77.77.1/30
PrivateKey = <ПРИВАТНЫЙ_КЛЮЧ_A>
[Peer]
PublicKey = <ПУБЛИЧНЫЙ_КЛЮЧ_B>
Endpoint = <ПУБЛИЧНЫЙ_IP_B>:51820
AllowedIPs = 10.77.77.2/32
PersistentKeepalive = 25Правильный результат: После sudo wg-quick up wg0 на обоих серверах команда ping -c 3 10.77.77.2 с A получает ответы.
Если возникла ошибка: Если handshake нет: проверьте UDP 51820, Endpoint, ключи и AllowedIPs. Не меняйте default route VPS.
Проверка WireGuard до настройки Xray
Что это и зачем
Если туннель не работает, каскад через него не заработает.
Действия по порядку
- На B выполните sudo wg-quick up wg0, затем на A ту же команду.
- На A запустите ping и wg show.
- На B проверьте, что виден peer A.
- Только после этого настраивайте SOCKS и Xray.
Команда или пример конфигурации
sudo chmod 600 /etc/wireguard/wg0.conf
sudo wg-quick up wg0
sudo wg show
ping -c 3 10.77.77.2Правильный результат: Есть latest handshake и растут transfer rx/tx.
Если возникла ошибка: Если wg0 уже поднят, wg-quick up сообщит об ошибке существующего интерфейса — проверьте ip addr show wg0.
Выход через B: SOCKS только внутри туннеля
Что это и зачем
Для каскада Xray на A должен передавать исходящие запросы на B. Один вариант — SOCKS inbound Xray на B, доступный только по 10.77.77.2:10808; затем SOCKS outbound Xray на A. Это не то же самое, что обычная цепочка из двух VLESS inbound.
Действия по порядку
- На B установите Xray через выбранную панель и создайте SOCKS inbound: listen 10.77.77.2, port 10808, auth no auth, UDP выключен для первого теста.
- На B ограничьте порт 10808 межсерверной сетью; никогда не публикуйте неаутентифицированный SOCKS в интернет.
- На A добавьте в Xray outbound с protocol socks и settings.servers address 10.77.77.2 port 10808.
- В правилах routing направьте трафик тестового VLESS inbound в outbound с tag exit-b.
- Для DNS и UDP потребуется отдельная проработка: этот пример рассчитан на TCP.
Команда или пример конфигурации
{
"tag": "exit-b",
"protocol": "socks",
"settings": {
"servers": [{"address": "10.77.77.2", "port": 10808}]
}
}Правильный результат: После применения профиля на A TCP-трафик клиента выходит с публичного IP B.
Если возникла ошибка: Если нет подключения: с A проверьте nc -vz 10.77.77.2 10808, журналы Xray на обоих VPS и наличие маршрута в routing. Формат добавления outbound различается между версиями панелей.
Проверьте каскад с телефона
Что это и зачем
Внешний IP позволяет проверить выходной сервер, но не доказывает отсутствие утечек DNS или IPv6.
Действия по порядку
- Подключите телефон к входному VLESS на A.
- Откройте сайт определения IPv4. Ожидается IP B.
- Проверьте DNS и IPv6; если они не маршрутизируются через B, настройте их отдельно или явно отключите соответствующий тип трафика у клиента.
- На A и B посмотрите журналы во время подключения.
Команда или пример конфигурации
curl -4 https://api.ipify.org; echo
sudo wg show
sudo ss -lntp | grep 10808 || trueПравильный результат: На телефоне IPv4 совпадает с B, а в wg show увеличиваются счётчики.
Если возникла ошибка: Если IP A — правило маршрутизации не применилось. Если соединение не работает — проверьте SOCKS B и WG.
Границы примера: эта конфигурация не проверялась на вашем VPS. Для каскада показана воспроизводимая схема TCP через SOCKS и WireGuard; UDP, DNS и IPv6 требуют отдельной настройки. Selfsteal зависит от поддерживаемого target и схемы локального HTTPS. Не публикуйте страницу как гарантию готовой настройки без теста на чистых серверах.