Каскады: мост RU → EU от iptables до многоуровневых схем

Каскад, он же мост, двойной прыжок или «RU → EU», — это когда клиент подключается не к зарубежной ноде напрямую, а к серверу в России, и уже тот передаёт трафик за границу. В 2026 году это основной способ держать ноды живыми. Цена — лишний сервер, лишние миллисекунды и лишняя точка отказа.

#Зачем он нужен

Каскад закрывает четыре разные проблемы, и важно понимать, какую из них решаешь ты:

Чего каскад не лечит: приложения вроде банков и маркетплейсов, которые видят включённый VPN на самом телефоне. «Любые роутинги и каскады не помогают» 25.04.26.

#Что видно на каждом плече

Каскад — это два независимых соединения, и ТСПУ смотрит на оба:

Главное следствие: если вход просто пересылает байты (L4-проброс), то по второму плечу идёт тот же самый TLS, что у клиента, с тем же SNI, но уже к зарубежному IP. Если вход сам разбирает трафик (Xray-мост), второе плечо может быть совсем другим протоколом.

#Два класса решений

Все способы делятся на две группы:

• L4-проброс (iptables, nftables, HAProxy, nginx stream, GOST, Rathole, SSH). Вход ничего не знает о VPN: принимает TCP (иногда UDP) и отправляет его дальше. Шифрование и пользователи живут только на выходной ноде.
• Прокси-мост (Xray на входе, в Remnawave — через профиль ноды). Вход сам расшифровывает клиентский протокол, решает по правилам маршрутизации, куда отправить трафик, и заново шифрует его для второго плеча.

клиент ══> RU:443 ──> EU:443
• на RU нет Xray и ключей
• один SNI на оба плеча
• RU-сайты тоже идут через EU

клиент ══> RU (Xray) ══> EU
• на RU свой inbound и SNI
• 2-е плечо любым протоколом
• geoip:ru можно напрямую

#Способ 1. iptables и nftables: DNAT

Самый простой вход: ядро российского сервера подменяет адрес назначения и пересылает пакеты на выход. Никаких демонов, работает для TCP и UDP (Hysteria2 тоже пройдёт).

# на RU-сервере; EU_IP — адрес выходной ноды
sysctl -w net.ipv4.ip_forward=1
echo 'net.ipv4.ip_forward=1' > /etc/sysctl.d/99-forward.conf

iptables -t nat -A PREROUTING -p tcp --dport 443 -j DNAT --to-destination EU_IP:443
iptables -t nat -A POSTROUTING -p tcp -d EU_IP --dport 443 -j MASQUERADE
iptables -I FORWARD -p tcp -d EU_IP --dport 443 -j ACCEPT
iptables -I FORWARD -p tcp -s EU_IP --sport 443 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

То же на nftables, отдельной таблицей, чтобы не мешать остальным правилам:

table ip relay {
  chain prerouting {
    type nat hook prerouting priority dstnat;
    tcp dport 443 dnat to EU_IP:443
  }
  chain postrouting {
    type nat hook postrouting priority srcnat;
    ip daddr EU_IP tcp dport 443 masquerade
  }
  chain forward {
    type filter hook forward priority filter;
    ip daddr EU_IP tcp dport 443 accept
    ip saddr EU_IP tcp sport 443 ct state established,related accept
  }
}

• MASQUERADE нужен, чтобы ответ вернулся через вход, а не напрямую клиенту. Побочный эффект: выходная нода видит всех клиентов с одного IP, IP входа.
• Если на сервере стоит Docker, цепочка FORWARD по умолчанию в DROP. Без правил ACCEPT выше пакеты тихо теряются. Подробнее в гайде Путь пакета через netfilter.
• Порт 443 на самом входе больше недоступен: всё уходит на выход. SSH и остальные порты не затронуты.
• В чате сравнивали: «iptables проще, HAProxy распихивает исходящий трафик, а в iptables — только в 1 ноду» ~07.08.26.

#Способ 2. HAProxy: несколько выходов, SNI и проверки

HAProxy в режиме tcp — тот же L4-проброс, но с тем, чего нет у iptables: балансировкой по нескольким выходам, проверкой их живости и выбором выхода по SNI.

global
    maxconn 20000

defaults
    mode tcp
    timeout connect 5s
    timeout client  1h
    timeout server  1h

frontend in443
    bind :443
    tcp-request inspect-delay 5s
    tcp-request content accept if { req_ssl_hello_type 1 }
    # у каждой страны свой SNI в подписке
    use_backend nl if { req.ssl_sni -i nl.example.com }
    default_backend de

backend de
    balance leastconn
    server de1 203.0.113.10:443 check
    server de2 203.0.113.11:443 check
    server de3 203.0.113.12:443 check backup

backend nl
    server nl1 198.51.100.20:443 check

• req.ssl_sni читается из ClientHello без расшифровки. Так один вход раздаёт разные страны: у каждой свой serverName в конфиге клиента. SNI должен совпадать с тем, что ждёт Reality на нужном выходе.
• check раз в пару секунд открывает TCP до выхода. Мёртвый выход убирается из ротации, backup включается, только когда лягут основные.
• send-proxy-v2 в строке server передаёт выходу настоящий IP клиента по PROXY protocol. Тогда в inbound выходной ноды нужен "sockopt": { "acceptProxyProtocol": true }, иначе соединения рвутся. Без этого выход видит всех с IP входа.
• HAProxy проксирует только TCP. Hysteria2 и другой UDP через него не пройдёт.
• В базе есть рабочий шаблон HAProxy с выбором бэкенда по SNI на 443 ~25.03.26. Есть и предупреждение: схема «HAProxy по SNI на 443 → 8443/8444» у одного админа периодически ловила 5-минутные баны, и ему советовали перейти на selfsteal 28.06.26.

Отдельная история — рынок «машин под HAProxy»: в августе 2026 продавали аренду российских серверов из белых списков, где root не дают, а дают только HAProxy до твоего выходного сервера. Например, CDNVideo-машины по 25 $ в день ~11.08.26 и MWS от 12,5 $ в день 08.08.26. Это тот же способ 2, только сервер чужой.

#Способ 3. nginx stream

Если на входе уже стоит nginx, модуль stream делает то же, что HAProxy, и умеет UDP:

stream {
    upstream eu {
        server 203.0.113.10:443 max_fails=2 fail_timeout=10s;
        server 203.0.113.11:443 backup;
    }
    server {
        listen 443;
        listen 443 udp;
        proxy_pass eu;
        proxy_connect_timeout 5s;
        proxy_timeout 1h;
    }
}

• В Debian и Ubuntu модуль ставится пакетом libnginx-mod-stream.
• Проверки живости у бесплатного nginx пассивные: выход помечается мёртвым после max_fails неудачных подключений.
• Выбор по SNI тоже есть (ssl_preread on и map $ssl_preread_server_name), но если он нужен, проще взять HAProxy.

#Способ 4. Xray-мост в Remnawave

Это способ из официальной документации Remnawave, в сообществе на неё ссылались с мая 2026 ~05.05.26. Вход — обычная нода Remnawave, к которой подключаются клиенты. В её профиле есть outbound на выходную ноду и правила маршрутизации.

Трюк в служебном пользователе. Панель вычищает массив clients из конфигов нод, поэтому вход авторизуется на выходе как обычный пользователь панели:

1. Создай профиль для выхода (DE Bridge Profile) с inbound для моста, назначь его выходной ноде и включи этот inbound во внутреннем скваде (Bridge Squad).
2. Создай пользователя bridge_user без лимита трафика и со сроком до 2099 года, добавь его в Bridge Squad.
3. В карточке пользователя: More Actions → Detailed Info → Connection Information. Скопируй пароль или UUID под протокол inbound: SS Password, VLESS UUID или Trojan Password.
4. В профиле входной ноды добавь outbound с этим паролем и правила маршрутизации.

Вариант из документации: второе плечо — Shadowsocks на порту 9999.

{
  "log": { "loglevel": "warning" },
  "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": [] }
}

В профиле входа меняются только outbounds и routing, inbound остаётся твоим обычным:

{
  "outbounds": [
    { "tag": "DIRECT", "protocol": "freedom" },
    { "tag": "BLOCK", "protocol": "blackhole" },
    {
      "tag": "SS_OUTBOUND_TO_DE",
      "protocol": "shadowsocks",
      "settings": {
        "servers": [
          {
            "address": "DE_NODE_ADDRESS",
            "port": 9999,
            "password": "SS_PASSWORD_СЛУЖЕБНОГО_ЮЗЕРА",
            "method": "chacha20-ietf-poly1305",
            "level": 0
          }
        ]
      }
    }
  ],
  "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" }
    ]
  }
}

• Правила идут сверху вниз. Российские IP и домены уходят DIRECT с самого входа, всё остальное с PUBLIC_RU_INBOUND — на выход.
• Для Shadowsocks в Remnawave метод всегда chacha20-ietf-poly1305, так сказано в документации.
• Документация честно пишет, что это демонстрация, а не готовый прод-конфиг. Этот же конфиг целиком лежит в базе ~27.04.26.

#SS или VLESS на втором плече

По этому вопросу база противоречит сама себе, и это важно:

• В начале апреля 2026 SS-мост хвалили: «Shadowsocks заебись» 04.04.26. 27.04 советовали SS на зарубежном конце, а «vless→vless никто не делает из-за пинга и скорости» 27.04.26.
• Уже тогда же появились сообщения, что «Shadowsocks на ТСПУ банится на большинстве провайдеров» 27.04.26. А 21.06.2026: «мост через ss на зарубеж — вычисляют быстро и банят быстро» 21.06.26.
• VLESS-VLESS при этом называли мостом с «буквально нулевым» пингом 08.04.26. В июне 2026 в чате разбирали вход с балансировкой на два выхода по VLESS Reality Vision 15.06.26.
• Исключение: на Selectel «на мосту только ss работает», VLESS TCP там блокировали 15.06.26.

Вариант с VLESS Reality на втором плече: на выходе inbound VLESS с Reality (порт любой, например 8443), на входе такой outbound с UUID служебного пользователя:

{
  "tag": "TO_DE",
  "protocol": "vless",
  "settings": {
    "address": "DE_NODE_ADDRESS",
    "port": 8443,
    "id": "UUID_СЛУЖЕБНОГО_ЮЗЕРА",
    "encryption": "none",
    "flow": "xtls-rprx-vision"
  },
  "streamSettings": {
    "network": "raw",
    "security": "reality",
    "realitySettings": {
      "serverName": "SNI_ИЗ_INBOUND_ВЫХОДА",
      "fingerprint": "firefox",
      "password": "PUBLIC_KEY_ВЫХОДА",
      "shortId": "SHORT_ID_ВЫХОДА"
    }
  }
}

Поля те же, что в клиентском конфиге из гайда VLESS + Reality. fingerprint: firefox — не случайность: в мае 2026 ТСПУ начал отбрасывать Reality с отпечатком chrome пруф. SNI выхода выбирай по правилам из того же гайда: зарубежный сайт, желательно из той же ASN, что и выходная нода.

Ещё одна схема из чата: на входе Caddy на 443, по путям — XHTTP inbound на 127.0.0.1, а outbound — VLESS Reality Vision на ноды в Польше и Германии 11.07.26. Первое плечо тогда выглядит как обычный сайт, подробности в гайде XHTTP и selfsteal.

#Способ 5. GOST v3: цепочки из коробки

GOST — утилита, которая умеет пробрасывать порты через цепочки прокси любой длины. Для каскада её ставят на оба конца и заворачивают второе плечо в свой протокол relay поверх TLS или WebSocket.

# на выходе (EU): сервер relay поверх TLS
gost -L "relay+tls://bridge:ДЛИННЫЙ_ПАРОЛЬ@:8443"

# на входе (RU): клиенты приходят на 443, трафик идёт через EU
# и там отдаётся на 127.0.0.1:443 — туда, где слушает Xray выходной ноды
gost -L "tcp://:443/127.0.0.1:443" -L "udp://:443/127.0.0.1:443" \
     -F "relay+tls://bridge:ДЛИННЫЙ_ПАРОЛЬ@EU_IP:8443"

• Адрес назначения в -L tcp://:443/АДРЕС подключает последний узел цепочки. Поэтому 127.0.0.1:443 — это localhost выходного сервера, а не входа.
• Несколько -F подряд образуют многоуровневую цепочку: -F relay+tls://A:8443 -F relay+tls://B:8443 проведёт трафик через A, потом через B.
• Вместо relay+tls можно relay+wss (WebSocket поверх TLS), если между серверами стоит что-то, что пропускает только HTTP.
• То же в YAML, для systemd удобнее. Имена полей из документации GOST v3:

services:
- name: in443
  addr: :443
  handler:
    type: tcp
    chain: to-eu
  listener:
    type: tcp
  forwarder:
    nodes:
    - name: xray-on-eu
      addr: 127.0.0.1:443
chains:
- name: to-eu
  hops:
  - name: hop-0
    nodes:
    - name: eu
      addr: EU_IP:8443
      connector:
        type: relay
        auth:
          username: bridge
          password: ДЛИННЫЙ_ПАРОЛЬ
      dialer:
        type: tls

Плюсы: одна утилита на всё, UDP, цепочки любой длины, туннель можно спрятать в WebSocket. Минусы: второе плечо — TLS с самоподписанным сертификатом GOST и неброузерным отпечатком. Сайтом оно не выглядит, и если ТСПУ начнёт такие соединения выделять, спрятаться будет некуда. В базе GOST упоминается только как софт, который разрешают на арендованных CDNVideo-машинах ~13.08.26: массового опыта моста на нём в чате нет.

#Способ 6. Rathole: соединение изнутри наружу

Rathole — обратный туннель, по смыслу как frp. Сервер rathole стоит на входе и открывает порт для клиентов, а клиент rathole стоит на выходной ноде и сам подключается к входу. То есть постоянное соединение между серверами открывает зарубежный сервер, а не российский.

[server]
bind_addr = "0.0.0.0:2333"          # сюда подключается выходная нода

[server.transport]
type = "noise"                       # шифрование Noise, без сертификатов

[server.transport.noise]
local_private_key = "PRIVATE_KEY_ИЗ_GENKEY"

[server.services.xray]
token = "ДЛИННЫЙ_СЕКРЕТ"
bind_addr = "0.0.0.0:443"           # сюда подключаются клиенты

[client]
remote_addr = "RU_IP:2333"

[client.transport]
type = "noise"

[client.transport.noise]
remote_public_key = "PUBLIC_KEY_ИЗ_GENKEY"

[client.services.xray]
token = "ДЛИННЫЙ_СЕКРЕТ"
local_addr = "127.0.0.1:443"        # Xray выходной ноды

• Пара ключей X25519 делается командой rathole --genkey: приватный ключ остаётся на входе (сервер), публичный кладётся выходу (клиент). По нему клиент проверяет, что подключился к своему серверу. Запуск: rathole server.toml на входе, rathole client.toml на выходе. Кроме Noise есть транспорты tls и websocket.
• Зачем обратное направление: в чате отмечали, что прямое подключение к российской ноде таймаутит, а подключение к ней со стороны зарубежных нод работает 05.06.26. В хронологии 04.08.2026 есть наблюдение «ТСПУ проверяет на выходе, не на входе» 04.08.26. Это наблюдения отдельных людей, а не правило, но идея понятна: соединение, которое инициирует зарубежный сервер, может проходить там, где исходящее из РФ режется.
• Второй плюс: на выходе не нужно открывать ни одного входящего порта. Нода может быть даже за NAT.
• Минусы: последний релиз v0.5.0 вышел в 2023 году, репозиторий живой, но новых версий нет. Один туннель — одна точка, при его разрыве отваливаются все клиенты, пока клиент rathole не переподключится.

#Способ 7. SSH-туннели

SSH есть на любом сервере, поэтому это самый быстрый способ поднять мост «на коленке»:

# на входе (RU): локальный проброс. Клиенты на RU:443 попадают на 127.0.0.1:443 выхода
ssh -N -L 0.0.0.0:443:127.0.0.1:443 \
    -o ServerAliveInterval=15 -o ExitOnForwardFailure=yes bridge@EU_IP

# или наоборот, на выходе (EU): обратный проброс, соединение открывает EU
ssh -N -R 0.0.0.0:443:127.0.0.1:443 \
    -o ServerAliveInterval=15 -o ExitOnForwardFailure=yes bridge@RU_IP

• Для -L явный адрес 0.0.0.0 делает порт доступным снаружи. Для -R на входе в sshd_config должно стоять GatewayPorts clientspecified (или yes), иначе порт повиснет только на 127.0.0.1.
• Порт 443 требует root, поэтому запускают из systemd или autossh с автопереподключением.
• Минусы серьёзные. Весь трафик всех клиентов идёт внутри одного TCP-соединения. Одна потеря пакета тормозит всех, а на длинных каналах скорость упирается в окно одного TCP. UDP нет. Протокол SSH ТСПУ видит как SSH: 03.08.2026 в чате описывали тест, когда у IP из бана пропадал доступ по порту 22 и любым кастомным 03.08.26.
• Плюс для отчаянных: маскировка под SSH (finalmask) в августе 2026 работала там, где VLESS и Hysteria2 лежали 03.08.26. Но это отдельный транспорт Xray, а не ssh -L.

#Цепочка на клиенте

Каскад можно собрать и без моста на сервере: клиент сам подключается к входу, а через него — к выходу. Так делает Xray через dialerProxy:

{
  "outbounds": [
    {
      "tag": "eu",
      "protocol": "vless",
      "settings": { "address": "EU_IP", "port": 443, "id": "UUID_EU", "encryption": "none", "flow": "xtls-rprx-vision" },
      "streamSettings": {
        "network": "raw",
        "security": "reality",
        "realitySettings": { "serverName": "SNI_EU", "fingerprint": "firefox", "password": "PUBLIC_KEY_EU", "shortId": "SHORT_ID_EU" },
        "sockopt": { "dialerProxy": "ru" }
      }
    },
    {
      "tag": "ru",
      "protocol": "vless",
      "settings": { "address": "RU_IP", "port": 443, "id": "UUID_RU", "encryption": "none" },
      "streamSettings": { "network": "raw", "security": "reality",
        "realitySettings": { "serverName": "SNI_RU", "fingerprint": "firefox", "password": "PUBLIC_KEY_RU", "shortId": "SHORT_ID_RU" } }
    }
  ]
}

• dialerProxy означает «устанавливай соединение до этого сервера через outbound ru». Внутреннее соединение до EU шифруется от клиента до выхода, и вход его не расшифровывает.
• Шаблон Mihomo в Remnawave умеет собирать такие цепочки в подписке через dialer-proxy и префикс вроде 🇷🇺➡️ к именам серверов.
• Минусы: двойное шифрование на телефоне, TLS внутри TLS на первом плече (узнаваемый признак прокси), и не все клиенты это поддерживают.

#Многоуровневые каскады

Два сервера — не предел. В базе встречаются три типовые схемы с тремя и более узлами.

RU из белого списка → RU → EU. Когда IP из белого списка до России достукивается, а до Европы нет, добавляют промежуточный российский сервер: «RU(WL) > RU > EU (трипл)» 24.06.26.

Вход → выход → финальный выход. К выходной ноде добавляют ещё один outbound: WARP ради «чистого» IP Cloudflare или другую страну ради сервисов с геоблоком. Схема «Eu node → ss → ru node → warp» есть в базе с ноября 2025 ~04.11.25. Gemini, который недоступен из части стран, лечили «мостом на Дубай» 14.06.26. Про WARP к августу 2026 писали, что на выходе он «быстро забанится сам» 16.08.26.

Изолированные мосты под группы пользователей. Один крупный сервис делал отдельный мост на каждые ~100 пользователей: «один IP и очень много мостов, сквады Remnawave на изолированных мостах» 22.08.26. Когда мост банят, отваливается одна группа, а не все.

В Xray любой длины цепочка собирается через тот же dialerProxy на сервере: outbound «выход 2» с "sockopt": { "dialerProxy": "выход 1" } пойдёт через выход 1. В GOST — несколькими -F или несколькими hops.

#Несколько выходов и балансировка

Один выход — одна точка отказа. На Xray-входе выходы объединяют в балансер с наблюдателем:

{
  "observatory": {
    "subjectSelector": ["EU_OUT"],
    "probeUrl": "https://www.google.com/generate_204",
    "probeInterval": "30s",
    "enableConcurrency": true
  },
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "balancers": [
      { "tag": "EU_BALANCER", "selector": ["EU_OUT"], "strategy": { "type": "leastPing" }, "fallbackTag": "EU_OUT_1" }
    ],
    "rules": [
      { "ip": ["geoip:private"], "outboundTag": "BLOCK" },
      { "ip": ["geoip:ru"], "outboundTag": "DIRECT" },
      { "inboundTag": ["RU_IN"], "balancerTag": "EU_BALANCER" }
    ]
  }
}

• selector работает по префиксу: EU_OUT возьмёт EU_OUT_1, EU_OUT_2 и так далее. Сами outbound-ы описываются как в способе 4.
• fallbackTag — один тег, а не список, резерв из нескольких выходов так не задать 25.05.26.
• leastPing всегда выбирает минимальный пинг, даже если этот выход перегружен 22.01.26. Слишком частые проверки тоже вредны: интервал 5 секунд называли «слишком часто» 03.06.26.
• Подробнее про стратегии в базе: Балансеры. На L4-входе ту же роль играет HAProxy из способа 2.

#Сравнение

#Риски и грабли

Вход банят быстрее выхода. 28.06.2026 писали, что мосты на российских хостерах (Timeweb, Beget, Reg.ru) массово отлетают: «добавленный в мост IP уходит в ТСПУ-бан за час» 28.06.26. Мост на Beget в августе отработал 15 дней 21.08.26. На Selectel IP, на который часто ходят, блокировался, и выход становился недоступен с него 19.08.26.

Российский хостер — это не только ТСПУ. Российские хостеры реагируют на жалобы РКН 22.06.26. Beget в июне 2026 обновил соглашение: VPN и прокси запрещены, скорость режут до 10 Мбит/с 19.06.26. В январе 2026 ГРЧЦ требовал от VK прекратить VLESS и Shadowsocks на своей сети 23.01.26. Кто как себя ведёт — в каталоге хостеров.

Не ставь панель на вход. После блокировки Telegram в июне 2026 панель Remnawave на российских VPS не могла подключиться к серверам и падала 21.06.26. Панель держат за границей, на входе — только нода. Сабку в сообществе, наоборот, советовали держать в РФ ~10.03.26.

Мост «палит» оба IP. Если трафик с входа идёт на выход неосторожно, в бан могут улететь оба адреса. Отсюда совет гнать за рубеж всё, а не только часть ~27.05.26.

Задержка и скорость. Каждый узел добавляет RTT от входа до выхода. Если канал входа за границу шейпят, мост упрётся в него. 19.08.2026: «как только поставишь нормальное на него — скорость в 5–10 раз падает» 19.08.26. Некоторые облака считают входящий и исходящий трафик отдельно, и мост оплачивается дважды 20.04.26.

MTU. Если между серверами туннель (WireGuard, WARP), пакеты внутри меньше 1500. Симптом «пинг есть, сайты висят» — классический. Как посчитать MTU, в гайде MTU и туннели.

Один IP на всех. При L4-пробросе без PROXY protocol выход видит всех клиентов с IP входа. Лимиты по IP и fail2ban на выходе будут банить сам вход, а абузы от сайтов прилетят на выходной IP за всех сразу.

#Как проверить мост

# 1. С входа: доходит ли вообще трафик до выхода (не блок ли 16–20)
curl -sk -o /dev/null --max-time 15 -w 'скачано %{size_download} байт\n' https://EU_IP/

# 2. С выхода: слушает ли Xray там, куда стучится вход
ss -ltnp | grep ':443'

# 3. С клиента через VPN: какой IP видит мир и какой видят российские сайты
curl -s https://api.ipify.org; echo

• Первая команда показывает блок «16–20 КБ»: если загрузка раз за разом встаёт на 16–20 тысячах байт, выход режут по пути ( ТСПУ на пальцах). В чате проверяют похоже: curl -v IP до nginx на выходе, «если ответ неполный — ТСПУ-блок» 06.08.26.
• С клиента api.ipify.org должен показать IP выхода, а российский сайт вроде 2ip.ru при правилах geoip:ru → DIRECT — IP входа.
• Доступность входа и выхода из разных стран и российских сетей проверяется на host.pink/check, досье IP и ASN выхода — прямо на host.pink/IP.

#Что почитать дальше

• База: Мосты RU→EU, БС (белые списки), Балансеры, Shadowsocks, ТСПУ: серверная часть.
• Гайды: VLESS + Reality, XHTTP и selfsteal, Нода Remnawave, WireGuard между серверами.
• Каталог хостеров: где вход живёт дольше и кто банит за VPN.