# Каскады: мост RU → EU от iptables до многоуровневых схем > Зачем ставить российский сервер перед зарубежной нодой, семь способов это сделать (iptables, HAProxy, nginx, Xray в Remnawave, GOST v3, Rathole, SSH), цепочки из трёх и больше серверов, сравнение и риски. С конфигами и опытом сообщества по датам. Каскад, он же мост, двойной прыжок или «RU → EU», — это когда клиент подключается не к зарубежной ноде напрямую, а к серверу в России, и уже тот передаёт трафик за границу. В 2026 году это основной способ держать ноды живыми. Цена — лишний сервер, лишние миллисекунды и лишняя точка отказа. **Схема:** Клиент → (Reality, XHTTP) Вход в РФ → (межсерверное плечо) Выход за границей → Интернет *Классический каскад: у клиента в подписке только российский адрес, зарубежная нода видна одному серверу* ## Зачем он нужен Каскад закрывает четыре разные проблемы, и важно понимать, какую из них решаешь ты: | Проблема | Почему помогает каскад | |---|---| | **Белые списки** на мобильном интернете | Клиент может достучаться только до разрешённых подсетей. Вход ставят на IP из белого списка, и дальше трафик идёт уже с сервера. Фильтр работает на уровне IP, поэтому без такого входа не помогает никакой протокол [id=158195\|~08.01.2026](https://t.me/c/2941121338/158195) | | **Блок по IP и «16–20 КБ»** у зарубежного хостера | Hetzner, OVH и других из РФ режут по подсетям. Напрямую клиенты не подключаются, а с российского сервера канал до них живой [id=239752\|23.02.2026](https://t.me/c/2941121338/239752) | | **Шейпинг** на домашних и мобильных каналах | 16.08.2026 при массовом шейпинге в Сибири писали, что «через мост все ноды выдают по тарифу» [id=1125287\|16.08.2026](https://t.me/c/2941121338/1125287) | | **Раздельная маршрутизация** | Российские сайты открываются прямо с российского IP, без капчи и «доступно только в РФ», а всё остальное уходит за границу | Чего каскад не лечит: приложения вроде банков и маркетплейсов, которые видят включённый VPN на самом телефоне. «Любые роутинги и каскады не помогают» [id=404827|25.04.2026](https://t.me/c/2941121338/404827). ## Что видно на каждом плече Каскад — это два независимых соединения, и ТСПУ смотрит на оба: | Плечо | Где проходит | Кто смотрит | Что должно выглядеть прилично | |---|---|---|---| | Клиент → вход | Сеть оператора абонента | ТСПУ оператора | IP входа (в белом списке, если режим белых списков), SNI, отпечаток TLS | | Вход → выход | Сеть российского хостера и магистраль | ТСПУ у хостера или на стыке | IP выхода, протокол межсерверного канала | Главное следствие: если вход просто пересылает байты (L4-проброс), то по второму плечу идёт **тот же самый** TLS, что у клиента, с тем же SNI, но уже к зарубежному IP. Если вход сам разбирает трафик (Xray-мост), второе плечо может быть совсем другим протоколом. > [!NOTE] > Где именно стоит ТСПУ, в базе спорят. Одни пишут, что «на всех ру-нодах тспу» [id=435274|~01.05.2026](https://t.me/c/2941121338/435274), другие — что он «не на хостингах, а на магистралях» [id=532751|~18.05.2026](https://t.me/c/2941121338/532751). Итог 18.08.2026: «есть у всех хостеров, но настроено по-разному» [id=1140025|18.08.2026](https://t.me/c/2941121338/1140025). Поэтому одна и та же схема у разных хостеров живёт по-разному. ## Два класса решений Все способы делятся на две группы: - **L4-проброс** (iptables, nftables, HAProxy, nginx stream, GOST, Rathole, SSH). Вход ничего не знает о VPN: принимает TCP (иногда UDP) и отправляет его дальше. Шифрование и пользователи живут только на выходной ноде. - **Прокси-мост** (Xray на входе, в Remnawave — через профиль ноды). Вход сам расшифровывает клиентский протокол, решает по правилам маршрутизации, куда отправить трафик, и заново шифрует его для второго плеча. **L4-проброс: вход — просто труба:** ``` клиент ══> 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 тоже пройдёт). ```bash # на 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, отдельной таблицей, чтобы не мешать остальным правилам: ```nft {name="/etc/nftables.d/relay.nft"} 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](/gaidy/put-paketa-cherez-netfilter/). - Порт 443 на самом входе больше недоступен: всё уходит на выход. SSH и остальные порты не затронуты. - В чате сравнивали: «iptables проще, HAProxy распихивает исходящий трафик, а в iptables — только в 1 ноду» [id=1075007|~07.08.2026](https://t.me/c/2941121338/1075007). ## Способ 2. HAProxy: несколько выходов, SNI и проверки HAProxy в режиме `tcp` — тот же L4-проброс, но с тем, чего нет у iptables: балансировкой по нескольким выходам, проверкой их живости и выбором выхода по SNI. ```haproxy {name="/etc/haproxy/haproxy.cfg"} 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 [id=295035|~25.03.2026](https://t.me/c/2941121338/295035). Есть и предупреждение: схема «HAProxy по SNI на 443 → 8443/8444» у одного админа периодически ловила 5-минутные баны, и ему советовали перейти на selfsteal [id=761623|28.06.2026](https://t.me/c/2941121338/761623). Отдельная история — рынок «машин под HAProxy»: в августе 2026 продавали аренду российских серверов из белых списков, где root не дают, а дают только HAProxy до твоего выходного сервера. Например, CDNVideo-машины по 25 $ в день [id=1092928|~11.08.2026](https://t.me/c/2941121338/1092928) и MWS от 12,5 $ в день [id=1073076|08.08.2026](https://t.me/c/2941121338/1073076). Это тот же способ 2, только сервер чужой. ## Способ 3. nginx stream Если на входе уже стоит nginx, модуль `stream` делает то же, что HAProxy, и умеет UDP: ```nginx {name="/etc/nginx/nginx.conf (вне блока http)"} 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](https://docs.rw/docs/learn/server-routing), в сообществе на неё ссылались с мая 2026 [id=458430|~05.05.2026](https://t.me/c/2941121338/458430). Вход — обычная нода 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. ```json {name="DE Bridge Profile (выход)"} { "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 остаётся твоим обычным: ```json {name="Профиль входной RU-ноды: outbounds и routing"} { "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`, так сказано в документации. - Документация честно пишет, что это демонстрация, а не готовый прод-конфиг. Этот же конфиг целиком лежит в базе [id=415500|~27.04.2026](https://t.me/c/2941121338/415500). ### SS или VLESS на втором плече По этому вопросу база противоречит сама себе, и это важно: - В начале апреля 2026 SS-мост хвалили: «Shadowsocks заебись» [id=322542|04.04.2026](https://t.me/c/2941121338/322542). 27.04 советовали SS на зарубежном конце, а «vless→vless никто не делает из-за пинга и скорости» [id=439235|27.04.2026](https://t.me/c/2941121338/439235). - Уже тогда же появились сообщения, что «Shadowsocks на ТСПУ банится на большинстве провайдеров» [id=439173|27.04.2026](https://t.me/c/2941121338/439173). А 21.06.2026: «мост через ss на зарубеж — вычисляют быстро и банят быстро» [id=728498|21.06.2026](https://t.me/c/2941121338/728498). - VLESS-VLESS при этом называли мостом с «буквально нулевым» пингом [id=341934|08.04.2026](https://t.me/c/2941121338/341934). В июне 2026 в чате разбирали вход с балансировкой на два выхода по VLESS Reality Vision [id=699075|15.06.2026](https://t.me/c/2941121338/699075). - Исключение: на Selectel «на мосту только ss работает», VLESS TCP там блокировали [id=698859|15.06.2026](https://t.me/c/2941121338/698859). Вариант с VLESS Reality на втором плече: на выходе inbound VLESS с Reality (порт любой, например 8443), на входе такой outbound с UUID служебного пользователя: ```json {name="Outbound на входе: VLESS Reality до выхода"} { "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](/gaidy/vless-reality/). `fingerprint: firefox` — не случайность: в мае 2026 ТСПУ начал отбрасывать Reality с отпечатком `chrome` [id=581441|25-26.05.2026](https://t.me/c/2941121338/581441). SNI выхода выбирай по правилам из того же гайда: зарубежный сайт, желательно из той же ASN, что и выходная нода. Ещё одна схема из чата: на входе Caddy на 443, по путям — XHTTP inbound на `127.0.0.1`, а outbound — VLESS Reality Vision на ноды в Польше и Германии [id=848912|11.07.2026](https://t.me/c/2941121338/848912). Первое плечо тогда выглядит как обычный сайт, подробности в гайде [XHTTP и selfsteal](/gaidy/xhttp-selfsteal/). ## Способ 5. GOST v3: цепочки из коробки [GOST](https://gost.run/en/) — утилита, которая умеет пробрасывать порты через цепочки прокси любой длины. Для каскада её ставят на оба конца и заворачивают второе плечо в свой протокол `relay` поверх TLS или WebSocket. ```bash # на выходе (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: ```yaml {name="/etc/gost/gost.yml на входе"} 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-машинах [id=1104472|~13.08.2026](https://t.me/c/2941121338/1104472): массового опыта моста на нём в чате нет. ## Способ 6. Rathole: соединение изнутри наружу [Rathole](https://github.com/rathole-org/rathole) — обратный туннель, по смыслу как frp. Сервер rathole стоит на входе и открывает порт для клиентов, а клиент rathole стоит на **выходной ноде** и сам подключается к входу. То есть постоянное соединение между серверами открывает зарубежный сервер, а не российский. ```toml {name="server.toml на входе (RU)"} [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" # сюда подключаются клиенты ``` ```toml {name="client.toml на выходе (EU)"} [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`. - Зачем обратное направление: в чате отмечали, что прямое подключение к российской ноде таймаутит, а подключение к ней со стороны зарубежных нод работает [id=642460|05.06.2026](https://t.me/c/2941121338/642460). В хронологии 04.08.2026 есть наблюдение «ТСПУ проверяет на выходе, не на входе» [id=1041345|04.08.2026](https://t.me/c/2941121338/1041345). Это наблюдения отдельных людей, а не правило, но идея понятна: соединение, которое инициирует зарубежный сервер, может проходить там, где исходящее из РФ режется. - Второй плюс: на выходе не нужно открывать ни одного входящего порта. Нода может быть даже за NAT. - Минусы: последний релиз v0.5.0 вышел в 2023 году, репозиторий живой, но новых версий нет. Один туннель — одна точка, при его разрыве отваливаются все клиенты, пока клиент rathole не переподключится. ## Способ 7. SSH-туннели SSH есть на любом сервере, поэтому это самый быстрый способ поднять мост «на коленке»: ```bash # на входе (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 и любым кастомным [id=1031702|03.08.2026](https://t.me/c/2941121338/1031702). - Плюс для отчаянных: маскировка под SSH (finalmask) в августе 2026 работала там, где VLESS и Hysteria2 лежали [id=1031604|03.08.2026](https://t.me/c/2941121338/1031604). Но это отдельный транспорт Xray, а не `ssh -L`. ## Цепочка на клиенте Каскад можно собрать и без моста на сервере: клиент сам подключается к входу, а через него — к выходу. Так делает Xray через `dialerProxy`: ```json {name="Клиентский конфиг: EU через RU"} { "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 (трипл)» [id=742007|24.06.2026](https://t.me/c/2941121338/742007). **Схема:** Телефон → (мобильный интернет) RU из белого списка → (внутри РФ) RU транзит → (за границу) EU выход *Тройной каскад для режима белых списков: первый сервер — ради разрешённого IP, второй — ради канала за границу* **Вход → выход → финальный выход.** К выходной ноде добавляют ещё один outbound: WARP ради «чистого» IP Cloudflare или другую страну ради сервисов с геоблоком. Схема «Eu node → ss → ru node → warp» есть в базе с ноября 2025 [id=48480|~04.11.2025](https://t.me/c/2941121338/48480). Gemini, который недоступен из части стран, лечили «мостом на Дубай» [id=691043|14.06.2026](https://t.me/c/2941121338/691043). Про WARP к августу 2026 писали, что на выходе он «быстро забанится сам» [id=1120269|16.08.2026](https://t.me/c/2941121338/1120269). **Изолированные мосты под группы пользователей.** Один крупный сервис делал отдельный мост на каждые ~100 пользователей: «один IP и очень много мостов, сквады Remnawave на изолированных мостах» [id=1170166|22.08.2026](https://t.me/c/2941121338/1170166). Когда мост банят, отваливается одна группа, а не все. В Xray любой длины цепочка собирается через тот же `dialerProxy` на сервере: outbound «выход 2» с `"sockopt": { "dialerProxy": "выход 1" }` пойдёт через выход 1. В GOST — несколькими `-F` или несколькими `hops`. > [!WARNING] > Каждый узел добавляет свою задержку, свою точку отказа и ещё одного хостера, который может получить предписание. Три узла — это не в три раза надёжнее, а в три раза больше мест, где всё может сломаться. Добавляй уровень, только когда знаешь, какую конкретную проблему он решает. ## Несколько выходов и балансировка Один выход — одна точка отказа. На Xray-входе выходы объединяют в балансер с наблюдателем: ```json {name="Вход: балансировка по двум EU-выходам"} { "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` — **один** тег, а не список, резерв из нескольких выходов так не задать [id=584231|25.05.2026](https://t.me/c/2941121338/584231). - `leastPing` всегда выбирает минимальный пинг, даже если этот выход перегружен [id=188369|22.01.2026](https://t.me/c/2941121338/188369). Слишком частые проверки тоже вредны: интервал 5 секунд называли «слишком часто» [id=629870|03.06.2026](https://t.me/c/2941121338/629870). - Подробнее про стратегии в базе: [Балансеры](/baza/transporty/balansery/). На L4-входе ту же роль играет HAProxy из способа 2. ## Сравнение | Способ | Что на входе | UDP | Видит ли вход трафик | Раздельная маршрутизация | Второе плечо | Когда брать | |---|---|:-:|---|:-:|---|---| | iptables / nftables | Ядро | да | нет | нет | те же байты, что у клиента | Быстро, один выход, минимум нагрузки | | HAProxy | HAProxy | нет | нет | по SNI | те же байты | Несколько выходов, проверки, чужая машина «только под HAProxy» | | nginx stream | nginx | да | нет | по SNI (сложнее) | те же байты | Если nginx уже стоит | | Xray-мост (Remnawave) | Нода Remnawave | да | да | да, geoip/geosite | любой протокол Xray | Основной вариант для панели, свой SNI на каждом плече | | GOST v3 | gost | да | нет | нет | relay поверх TLS или WS | Длинные цепочки, нестандартные сети | | Rathole | rathole | да | нет | нет | Noise или TLS, соединение из EU | Выход за NAT, исходящие из РФ режутся | | SSH | sshd | нет | нет | нет | SSH | Временно, на час, пока чинишь основное | | Цепочка на клиенте | Любая нода | да | нет | на клиенте | Reality внутри Reality | Параноидальный режим, свои устройства | ## Риски и грабли **Вход банят быстрее выхода.** 28.06.2026 писали, что мосты на российских хостерах (Timeweb, Beget, Reg.ru) массово отлетают: «добавленный в мост IP уходит в ТСПУ-бан за час» [id=765784|28.06.2026](https://t.me/c/2941121338/765784). Мост на Beget в августе отработал 15 дней [id=1159974|21.08.2026](https://t.me/c/2941121338/1159974). На Selectel IP, на который часто ходят, блокировался, и выход становился недоступен с него [id=1150347|19.08.2026](https://t.me/c/2941121338/1150347). **Российский хостер — это не только ТСПУ.** Российские хостеры реагируют на жалобы РКН [id=737162|22.06.2026](https://t.me/c/2941121338/737162). Beget в июне 2026 обновил соглашение: VPN и прокси запрещены, скорость режут до 10 Мбит/с [id=721740|19.06.2026](https://t.me/c/2941121338/721740). В январе 2026 ГРЧЦ требовал от VK прекратить VLESS и Shadowsocks на своей сети [id=192699|23.01.2026](https://t.me/c/2941121338/192699). Кто как себя ведёт — в [каталоге хостеров](/hostery/). **Не ставь панель на вход.** После блокировки Telegram в июне 2026 панель Remnawave на российских VPS не могла подключиться к серверам и падала [id=726992|21.06.2026](https://t.me/c/2941121338/726992). Панель держат за границей, на входе — только нода. Сабку в сообществе, наоборот, советовали держать в РФ [id=263001|~10.03.2026](https://t.me/c/2941121338/263001). **Мост «палит» оба IP.** Если трафик с входа идёт на выход неосторожно, в бан могут улететь оба адреса. Отсюда совет гнать за рубеж всё, а не только часть [id=592594|~27.05.2026](https://t.me/c/2941121338/592594). **Задержка и скорость.** Каждый узел добавляет RTT от входа до выхода. Если канал входа за границу шейпят, мост упрётся в него. 19.08.2026: «как только поставишь нормальное на него — скорость в 5–10 раз падает» [id=1144931|19.08.2026](https://t.me/c/2941121338/1144931). Некоторые облака считают входящий и исходящий трафик отдельно, и мост оплачивается дважды [id=379481|20.04.2026](https://t.me/c/2941121338/379481). **MTU.** Если между серверами туннель (WireGuard, WARP), пакеты внутри меньше 1500. Симптом «пинг есть, сайты висят» — классический. Как посчитать MTU, в гайде [MTU и туннели](/gaidy/mtu-i-tunneli/). **Один IP на всех.** При L4-пробросе без PROXY protocol выход видит всех клиентов с IP входа. Лимиты по IP и fail2ban на выходе будут банить сам вход, а абузы от сайтов прилетят на выходной IP за всех сразу. ## Как проверить мост ```bash # 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 тысячах байт, выход режут по пути ([ТСПУ на пальцах](/gaidy/tspu-na-paltsah/)). В чате проверяют похоже: `curl -v IP` до nginx на выходе, «если ответ неполный — ТСПУ-блок» [id=1060795|06.08.2026](https://t.me/c/2941121338/1060795). - С клиента `api.ipify.org` должен показать IP выхода, а российский сайт вроде `2ip.ru` при правилах `geoip:ru → DIRECT` — IP входа. - Доступность входа и выхода из разных стран и российских сетей проверяется на [host.pink/check](/tools/), досье IP и ASN выхода — прямо на `host.pink/IP`. ## Что почитать дальше - База: [Мосты RU→EU](/baza/tspu/mosty/), [БС (белые списки)](/baza/tspu/bs-podseti/), [Балансеры](/baza/transporty/balansery/), [Shadowsocks](/baza/transporty/shadowsocks/), [ТСПУ: серверная часть](/baza/set/tspu-servernoe/). - Гайды: [VLESS + Reality](/gaidy/vless-reality/), [XHTTP и selfsteal](/gaidy/xhttp-selfsteal/), [Нода Remnawave](/gaidy/noda-remnawave/), [WireGuard между серверами](/gaidy/wireguard-mezhdu-serverami/). - [Каталог хостеров](/hostery/): где вход живёт дольше и кто банит за VPN. --- Источник: https://host.pink/gaidy/kaskad-ru-eu/ Лицензия: CC BY-SA 4.0