Обычно всё начинается с какой-то очень приземлённой задачи. Не с архитектуры, не с сетевой философии, а с чего-то бытового.
Например, хочется открыть зарубежный маркетплейс и посмотреть, какие там цены для другой страны. Или нужно, чтобы один сайт открывался через отдельный маршрут, а все российские сервисы, банки, госуслуги, обновления системы и рабочие сайты шли как обычно. Или хочется пустить браузер через один путь, а всё остальное на компьютере вообще не трогать.
И вот в этот момент человек внезапно выясняет, что интернет устроен не очень дружелюбно. Если просто взять и направить весь трафик в один туннель, почти всегда начинаются побочные эффекты. Что-то тормозит. Где-то меняется география там, где она не должна меняться. Где-то отваливаются авторизации. Где-то растёт задержка. Где-то приложение вообще ведёт себя так, будто ты лично его оскорбил.
Поэтому нормальный путь - не гнать весь трафик одинаково, а разделять его по задачам.
Это и есть раздельное туннелирование. По сути, ты заранее решаешь:
- какие сайты должны идти одним маршрутом
- какие приложения должны идти другим
- что должно идти напрямую
- а что вообще лучше обрабатывать уже на сервере
И вот это уже не какая-то экзотика для сетевых фанатов. Это вполне бытовая история.
Полезных сценариев тут много.
Самый простой - пустить через отдельный маршрут 2-3 конкретных сайта и не трогать всё остальное.
Чуть более взрослый - заставить идти по отдельному пути только браузер, в котором ты проверяешь зарубежные сервисы, а всю систему оставить в покое.
Ещё полезнее - направить через SOCKS только одно приложение. Например, отдельный браузер, парсер, клиент или тестовую утилиту.
Домашний уровень - перенести правила на роутер, чтобы все устройства дома уже автоматически ходили как нужно.
И совсем интересный вариант - когда на клиенте весь трафик уходит в локальный SOCKS-вход, дальше попадает на твой сервер с Marzban и Xray, а уже там делится по странам, доменам и категориям. Например, одни сайты идут напрямую, другие через отдельный выход, третьи режутся совсем.
Ниже разберём всё по порядку. От самого простого варианта до самого гибкого.
Когда достаточно только браузера
Если задача звучит как "мне нужно пустить через другой маршрут буквально несколько сайтов", то лезть в маршруты системы, IP-диапазоны и роутер вообще не надо. Это как ради замены лампочки разбирать половину дома.
Здесь самый удобный инструмент - PAC-файл.
Это обычный файл с маленькой JavaScript-функцией, которая для каждого запроса браузера решает, что делать дальше. Для одних сайтов можно сказать "иди через SOCKS", для остальных - "иди напрямую".
Простейший пример:
function FindProxyForURL(url, host) {
host = host.toLowerCase();
if (dnsDomainIs(host, "amazon.com") || dnsDomainIs(host, ".amazon.com")) {
return "SOCKS 127.0.0.1:1080";
}
if (dnsDomainIs(host, "ebay.com") || dnsDomainIs(host, ".ebay.com")) {
return "SOCKS 127.0.0.1:1080";
}
if (dnsDomainIs(host, "walmart.com") || dnsDomainIs(host, ".walmart.com")) {
return "SOCKS 127.0.0.1:1080";
}
return "DIRECT";
}
Логика тут очень простая. Для трёх доменов используется локальный SOCKS на 127.0.0.1:1080. Всё остальное идёт напрямую.
Это хороший вариант, когда тебе нужно:
- открыть несколько конкретных сайтов через другой маршрут
- не трогать всю систему
- быстро проверить идею
- не разбираться в сетях глубже необходимого
В Windows такой файл подключается через настройки прокси, в разделе со сценарием настройки. В macOS - через настройки сети и автоматическую конфигурацию прокси.
Если файл лежит локально, его можно вообще раздать маленьким встроенным сервером:
python -m http.server 8080
Тогда PAC будет доступен, например, по адресу:
http://127.0.0.1:8080/proxy.pac
И дальше уже браузер будет сам смотреть в этот файл перед каждым запросом.
У PAC есть один важный плюс - он работает по доменам. То есть тебе не нужно думать про IP-адреса сайта, диапазоны, CDN и прочее сетевое колдовство. Ты просто говоришь: вот эти домены - сюда, всё остальное - как обычно.
Но есть и ограничение. PAC - это в первую очередь история про браузеры и про приложения, которые уважают системные прокси-настройки. А часть программ на это смотрит с ледяным равнодушием.
Когда нужно направить через SOCKS только одно приложение
Это, пожалуй, самый полезный сценарий в обычной жизни.
Например, ты хочешь:
- чтобы браузер для проверки зарубежных цен шёл через SOCKS
- а всё остальное на компьютере работало напрямую
Или:
- чтобы какая-то утилита, парсер, тестовый клиент или отдельное приложение шло через другой маршрут
- а система не менялась совсем
Тут есть два варианта.
Вариант первый - если приложение умеет читать переменные окружения
Некоторые программы понимают такие переменные:
- HTTP_PROXY
- HTTPS_PROXY
- ALL_PROXY
Тогда можно запускать их через отдельный скрипт.
Для Windows:
@echo off
set "ALL_PROXY=socks5://127.0.0.1:1080"
set "HTTP_PROXY=%ALL_PROXY%"
set "HTTPS_PROXY=%ALL_PROXY%"
start "" "C:\Program Files\MyApp\app.exe"
Для macOS:
#!/usr/bin/env bash
export ALL_PROXY="socks5://127.0.0.1:1080"
export HTTP_PROXY="$ALL_PROXY"
export HTTPS_PROXY="$ALL_PROXY"
"/Applications/MyApp.app/Contents/MacOS/MyApp"
Что важно - это не глобальная настройка системы. Это настройка только для того процесса, который ты запускаешь из этого скрипта.
То есть всё остальное продолжает жить как жило.
Это очень аккуратный способ. Но, конечно, не всё так просто. Не каждое приложение читает эти переменные. Терминальные утилиты часто читают. GUI-программы уже как повезёт. Иногда работает идеально, иногда вообще никак.
Вариант второй - если приложение само ничего не умеет
Вот тут уже нужны программы, которые умеют перехватывать трафик процесса и отправлять его через SOCKS насильно.
Самый известный вариант - Proxifier.
Логика работы у него простая:
- добавляешь SOCKS-сервер
- создаёшь правило
- говоришь, что только конкретное приложение должно идти через этот SOCKS
- всё остальное оставляешь прямым
Например:
- chrome.exe - через SOCKS
- всё остальное - Direct
Это уже очень удобный рабочий режим. Можно даже завести отдельный браузер "для специальных задач", а основной оставить обычным.
Если хочется ещё аккуратнее, можно запускать Proxifier с нужным профилем через .bat, а потом сразу запускать нужную программу. Тогда у тебя вообще получается почти отдельная среда.
На macOS похожий подход тоже возможен. Для терминальных команд там ещё удобно использовать proxychains, когда нужно пустить через SOCKS ровно одну команду вроде curl, git или чего-то подобного.
Когда браузера и одного приложения уже мало
Следующий уровень - когда хочется, чтобы правила работали не точечно на одном компьютере, а шире.
Например:
- чтобы один телевизор шёл одним путём
- ноутбук другим
- телефон третьим
- а локальные сервисы дома вообще никогда не трогались
Здесь уже появляется роутер.
Уровень роутера - один раз настроил, и оно работает для всего дома
Это очень удобный вариант, если устройств много и не хочется на каждом что-то отдельно настраивать.
На роутере можно строить policy-based routing. По-человечески - правила, которые говорят, какой трафик куда отправлять.
Например:
- телевизор идёт через отдельный маршрут
- ноутбук напрямую
- конкретные домены идут через один выход
- всё локальное остаётся локальным
В этом подходе есть большой плюс. Логика живёт в одном месте. Не нужно объяснять домашним, почему на этом устройстве включить вот это, а на другом не трогать вон то. Не нужно вспоминать, где и что ты менял неделю назад.
Но и нюансов хватает.
Во-первых, доменные правила на роутере часто завязаны на DNS. А если клиентские приложения начинают использовать DoH, роутер может просто не видеть обычные DNS-запросы. И тогда правила "по домену" внезапно работают не так, как ты ожидал.
Во-вторых, роутерный уровень уже требует чуть большего понимания того, что вообще происходит в сети. Не какого-то академического ужаса, но уже и не совсем режим "сейчас просто галочку поставлю".
Если дома одно устройство и один сценарий, это может быть избыточно. Если устройств много, наоборот, это очень разумный путь.
Самая гибкая схема - когда клиент просто отправляет всё в SOCKS, а деление происходит на сервере
Вот здесь начинается уже действительно взрослая архитектура.
Схема такая:
- на клиенте есть локальный SOCKS
- клиент отправляет трафик туда
- дальше трафик уходит на твой сервер
- а уже сервер решает, что с ним делать
Именно здесь хорошо раскрываются Marzban и Xray.
На клиенте всё становится довольно тупым. И это плюс. Клиенту не нужно знать, что такое geosite, geoip, категории доменов, российские диапазоны, рекламные списки и так далее. Он просто отправляет трафик в нужную точку.
А вся логика живёт на сервере.
Это очень удобно, если ты хочешь:
- разделять трафик по странам
- разделять по доменам
- делить по категориям вроде маркетплейсов, видео, рекламы, соцсетей
- централизованно менять правила в одном месте
- не поддерживать вручную кучу разных конфигов на клиентах
Как это выглядит логически
На сервере можно задать правила вроде таких:
- российские IP - напрямую
- локальные адреса - напрямую
- маркетплейсы - через один выход
- видео - через другой
- рекламные домены - в блок
- всё остальное - по умолчанию через третий маршрут
- а можно еще повесить и Родительский контроль!
То есть по сути ты строишь свой собственный диспетчер трафика.
Пример логики в конфиге:
{
"routing": {
"domainStrategy": "IPIfNonMatch",
"rules": [
{
"type": "field",
"ip": ["geoip:private", "geoip:ru"],
"outboundTag": "direct"
},
{
"type": "field",
"domain": ["geosite:category-ads-all"],
"outboundTag": "block"
},
{
"type": "field",
"domain": [
"domain:amazon.com",
"domain:ebay.com",
"domain:walmart.com"
],
"outboundTag": "proxy-us"
},
{
"type": "field",
"network": "tcp,udp",
"outboundTag": "proxy-default"
}
]
}
}
Даже если не вчитываться в JSON, идея тут понятна:
- локальное и российское - напрямую
- реклама - режется
- конкретные маркетплейсы - через специальный выход
- всё остальное - в дефолтный маршрут
Откуда берутся списки
Обычно используются:
- geoip.dat - для диапазонов IP по странам
- geosite.dat - для доменных списков и категорий
Если этого мало, можно подключать кастомные файлы.
Например:
- списки кинотеатров
- списки маркетплейсов
- списки нужных сервисов
- рекламные и мусорные домены
- собственные категории под свои задачи
Вот твой кейс про "на сервере включается разделение по специальным файлам, содержащим диапазоны адресов по странам или домены по направлениям" - это как раз сюда. Это не экзотика, а совершенно нормальный рабочий сценарий.
Роль Marzban во всей этой истории
Marzban здесь выступает как панель и оболочка вокруг Xray. Он не столько сам маршрутизирует, сколько управляет Xray и его окружением.
Если говорить совсем просто:
- Xray - это движок, который умеет routing rules
- Marzban - это удобный способ этим хозяйством управлять
Поэтому, когда ты хочешь работать со списками стран, доменов и категорий, по факту ты думаешь в терминах Xray, а Marzban просто помогает это держать в порядке.
Реальные сценарии, где всё это не выглядит надуманным
Иногда статьи на такие темы грешат тем, что описывают очень умные, но совершенно неживые сценарии. Поэтому давайте без фантазий про "глобальную сетевую архитектуру в корпоративном контуре". Вот обычные, понятные случаи:
Проверка цен и региональных условий
Один из самых житейских сценариев. Нужно открыть несколько маркетплейсов, сервисов бронирования или магазинов через другой маршрут и посмотреть локальные цены, доставку, наличие, акции. Для этого часто хватает PAC или отдельного браузера через SOCKS.
Один браузер "обычный", другой "специальный"
Очень удобный режим.
Например:
- основной браузер идёт напрямую
- второй браузер идёт через SOCKS
Так не нужно постоянно переключать системные настройки. И не нужно каждый раз вспоминать, а сейчас у тебя что вообще включено.
Только медиасервисы через отдельный маршрут
Например, стриминги идут через один выход, а всё рабочее, банковское и локальное идёт напрямую. Это удобно делать либо на роутере, либо уже на сервере через списки доменов.
Только одно приложение через SOCKS
Очень полезно для тестов, парсинга, отладки, проверки поведения клиента или просто для отдельной рабочей задачи. Здесь лучший вариант - отдельный запуск с переменными окружения или Proxifier.
Централизованная логика для всех устройств
Если у тебя дома ноутбук, телевизор, телефон, планшет, приставка и ещё пол-ящика техники, гораздо приятнее решить это один раз на роутере или сервере, чем потом бегать и вспоминать, где именно ты что настраивал.
Что выбрать, если не хочется сразу залезать в дебри
Если задача маленькая и конкретная, начни с маленького и конкретного решения.
Если нужно пустить через другой маршрут 2-3 сайта - начни с PAC.
Если нужно пустить через SOCKS только одно приложение - попробуй запуск через переменные окружения. Если программа не понимает это, переходи на Proxifier.
Если хочется, чтобы всё работало сразу для нескольких устройств дома - смотри в сторону роутера.
Если нужна максимальная гибкость, несколько выходов, правила по странам, доменам и категориям - делай локальный SOCKS на клиенте и routing rules на сервере через Xray и Marzban.
Это как с инструментами в мастерской. Не надо сразу брать сварочный аппарат, если тебе нужно просто подкрутить один винт. Но и отвёрткой чинить всё подряд - тоже странная жизненная позиция.
В итоге
Раздельное туннелирование нужно не потому, что это модно и сетевые энтузиасты любят красивые слова. Оно нужно потому, что интернет давно перестал быть местом, где один и тот же маршрут одинаково хорош для всего.
Один сайт ты хочешь открыть через один путь. Другой - оставить прямым. Одно приложение должно идти через SOCKS. Другое вообще не нужно трогать. Где-то удобнее решить всё на уровне браузера. Где-то на уровне процесса. Где-то на роутере. А где-то логично вынести всю маршрутизацию на сервер и больше не мучить клиентов.
Именно это и есть нормальный взрослый подход. Не "пустить всё одинаково", а направлять трафик туда, где ему действительно место.
Если хочешь, я могу следующим сообщением сделать ещё более живую версию именно под публикацию на Хабре - с более цепким вступлением, более плавными переходами между разделами и совсем естественной разговорной подачей.
Если вам интересно и хочется подробнее, оставляйте коментарии, постараюсь объяснить.