← Назад к блогу

Прокси только для нужных сайтов: маршрутизация по доменам в sing-box и mihomo

Через платный прокси не обязательно гнать весь трафик. Разбираем маршрутизацию по доменам в sing-box и mihomo (Clash Meta): готовые конфиги под актуальные версии, правила по сайтам и программам, несколько стран одновременно и ловушки — QUIC, DNS-утечки, конфликт с антидетектом и ротация посреди сессии.

📅13 октября 2026 г.
Прокси только для нужных сайтов: маршрутизация по доменам в sing-box и mihomo

Типичная ситуация: магазин на немецком Amazon нужно открывать с немецкого IP, кабинет поставщика из США — с американского, а YouTube, рабочий мессенджер и обновления системы пусть идут напрямую. Включать прокси «на всю систему» неудобно и дорого: при оплате за гигабайт через прокси уходит весь фоновый трафик. Выключать-включать вручную — забудете в самый неподходящий момент. Решение — маршрутизация по доменам: локальный клиент сам решает, какой сайт пустить через какой прокси, а какой — напрямую. Ниже — рабочие конфиги для двух самых популярных движков 2026 года, sing-box и mihomo (бывший Clash Meta), и разбор ловушек, на которых обычно ломается схема.

Чем это лучше прокси в браузере и PAC-файла

Прокси в настройках браузера или расширении работает только для этого браузера. PAC-файл умеет выбирать прокси по домену, но тоже живёт внутри браузера и системных настроек — десктопный клиент маркетплейса, Telegram, скрипт на Python или консольная утилита его просто проигнорируют.

sing-box и mihomo работают уровнем ниже: поднимают виртуальный сетевой интерфейс (режим TUN) и пропускают через себя трафик всех программ. Дальше каждое соединение проходит по списку правил: домен, IP-подсеть, имя процесса, порт. Совпало правило — соединение уходит в указанный выход (прокси нужной страны или прямое подключение).

Что это даёт на практике:

  • Экономия трафика. Через платный прокси идут только рабочие сайты, а видео, обновления и облачные бэкапы — напрямую.
  • Несколько стран одновременно. amazon.de — через немецкий выход, walmart.com — через американский, без переключений.
  • Правила по программам. Можно отправить в прокси конкретный процесс целиком (например, десктопный клиент или скрипт), не трогая остальные.
  • Меньше человеческих ошибок. Не нужно помнить, включён ли прокси, — сайт всегда открывается с «правильного» IP.

Что понадобится

  • Прокси с поддержкой SOCKS5 или HTTP и авторизацией по логину и паролю. Оба движка умеют передавать логин и пароль сами, локальный шлюз не нужен.
  • Клиент: для sing-box — официальные приложения для Android, iOS и macOS или ядро для Windows/Linux; для mihomo — графические оболочки вроде Clash Verge Rev или FlClash.
  • Список доменов, которые должны ходить через прокси. Его стоит собрать заранее — об этом ниже.

Вариант 1: sing-box (версии 1.12 и новее)

Важная оговорка про версии. Многие конфиги из интернета написаны под старый sing-box и на актуальных сборках не запускаются. По официальному списку устаревших функций: geosite и geoip удалены в 1.12.0 (вместо них — rule-set), поле outbound внутри правил с 1.11 заменено на действия ("action": "route"), старые форматы DNS-серверов удалены в 1.14.0, а спецвыходы block и dns — ещё в 1.13.0. Актуальная стабильная ветка на момент написания — 1.14.

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

{
  "log": { "level": "info" },
  "dns": {
    "servers": [ { "type": "local", "tag": "local" } ]
  },
  "inbounds": [
    {
      "type": "tun",
      "tag": "tun-in",
      "address": [ "172.18.0.1/30" ],
      "auto_route": true,
      "strict_route": true
    }
  ],
  "outbounds": [
    {
      "type": "socks",
      "tag": "resi-de",
      "server": "ХОСТ_ИЗ_КАБИНЕТА",
      "server_port": 1080,
      "username": "ЛОГИН",
      "password": "ПАРОЛЬ"
    },
    { "type": "direct", "tag": "direct" }
  ],
  "route": {
    "auto_detect_interface": true,
    "default_domain_resolver": "local",
    "rules": [
      { "action": "sniff" },
      { "protocol": "dns", "action": "hijack-dns" },
      {
        "network": "udp",
        "port": 443,
        "domain_suffix": [ "amazon.de", "otto.de" ],
        "action": "reject"
      },
      {
        "domain_suffix": [ "amazon.de", "otto.de", "ipinfo.io" ],
        "action": "route",
        "outbound": "resi-de"
      }
    ],
    "final": "direct"
  }
}

Хост, порт, логин и пароль подставьте из кабинета провайдера. Порт 1080 здесь только для примера.

Что делает каждая часть

  1. TUN-вход (auto_route) заворачивает в sing-box трафик всей системы. strict_route на Windows дополнительно добавляет правила фаервола против DNS-утечек (документация предупреждает, что это может ломать некоторые программы, например VirtualBox).
  2. "action": "sniff" — ключевая строка. Через TUN приходят соединения на IP-адреса, а не на домены. Сниффинг достаёт имя сайта из TLS-рукопожатия (SNI) или HTTP-заголовка, и только после этого начинают срабатывать правила domain_suffix. Без этой строки доменные правила молча не работают — частая причина «конфиг не применяется».
  3. hijack-dns перехватывает DNS-запросы системы и отдаёт их DNS-модулю sing-box.
  4. Правило с reject для UDP 443 отключает QUIC (HTTP/3) для проксируемых доменов. Браузер откатится на обычный HTTPS поверх TCP, и тот пойдёт через прокси. Зачем — в разделе про ловушки.
  5. domain_suffix ловит домен и все его поддомены: amazon.de покрывает и www.amazon.de, и sellercentral.amazon.de.
  6. auto_detect_interface привязывает исходящие соединения самого sing-box к физическому сетевому адаптеру. Без него трафик к прокси-серверу снова попадёт в TUN, и получится петля маршрутизации.
  7. final: direct — всё, что не совпало ни с одним правилом, идёт напрямую.

Несколько стран и правило по программе

Второй выход добавляется как ещё один объект socks со своим тегом (например, resi-us) и отдельным правилом. Отправить в прокси программу целиком можно правилом с полем process_name (работает на Windows, macOS и Linux):

{
  "process_name": [ "python.exe" ],
  "action": "route",
  "outbound": "resi-us"
}

Правила проверяются сверху вниз до первого совпадения, поэтому частные правила ставьте выше общих.

Вариант 2: mihomo (Clash Meta)

mihomo удобен тем, что под него есть зрелые графические оболочки, а конфиг пишется на YAML, который проще читать. Тот же сценарий:

tun:
  enable: true
  stack: gvisor
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://1.1.1.1/dns-query

proxies:
  - name: resi-de
    type: socks5
    server: ХОСТ_ИЗ_КАБИНЕТА
    port: 1080
    username: ЛОГИН
    password: ПАРОЛЬ

rule-providers:
  work-de:
    type: inline
    behavior: classical
    payload:
      - DOMAIN-SUFFIX,amazon.de
      - DOMAIN-SUFFIX,otto.de
      - DOMAIN-SUFFIX,ipinfo.io

rules:
  - RULE-SET,work-de,resi-de
  - MATCH,DIRECT

Главные отличия от sing-box:

  • Режим fake-ip решает проблему «соединение пришло на IP, а не на домен» иначе: mihomo сам отвечает на DNS-запрос фиктивным адресом, запоминает, какому домену он соответствует, и по нему применяет правила. Реальный адрес сайта узнаёт уже прокси-сервер на своей стороне.
  • Набор правил (rule-providers) удобно держать отдельным списком. Тип inline хранит домены прямо в конфиге, тип http подтягивает список по ссылке и обновляет по интервалу, например общий список команды в репозитории.
  • MATCH — аналог final: всё прочее идёт напрямую.
  • Для правил по программам есть PROCESS-NAME, на Android он принимает имя пакета приложения.

Как собрать список доменов и не пропустить нужные

Сайт — это не один домен. Маркетплейс грузит картинки с CDN, скрипты — с отдельного домена, авторизация может жить на третьем. Если основной домен идёт через немецкий IP, а домен входа — с вашего настоящего, антифрод видит два разных адреса в одной сессии.

  1. Откройте сайт с инструментами разработчика (F12 → вкладка Network), пройдите типовой сценарий: вход, поиск, карточка товара, кабинет.
  2. Выпишите все домены из колонки Domain. Сторонние счётчики и рекламу можно не добавлять, а домены самого сервиса (включая CDN и сервер авторизации) — обязательно.
  3. Добавьте их в правило и повторите сценарий. В логе sing-box (уровень info) или во вкладке соединений оболочки mihomo видно, какое правило сработало для каждого соединения.
  4. Держите в списке «контрольный» домен вроде ipinfo.io: он показывает IP прокси, а соседний сервис проверки IP, не попавший в список, — ваш настоящий. Так за секунду видно, что маршрутизация работает.

Ловушки, на которых ломается схема

1. QUIC проскакивает мимо прокси

Chrome и другие браузеры охотно ходят на крупные сайты по HTTP/3, то есть по UDP. Многие прокси-провайдеры не поддерживают UDP через SOCKS5 или поддерживают ограниченно. В худшем случае соединение уходит не туда, в лучшем — сайт тормозит, пока браузер не откатится на TCP. Поэтому в конфиге sing-box выше UDP на порт 443 для рабочих доменов явно отклоняется. В mihomo аналогичного эффекта проще добиться, отключив QUIC в браузере (флаг chrome://flags/#enable-quic).

2. DNS-утечка к провайдеру

Если рабочий домен резолвится локально через DNS вашего интернет-провайдера, сам сайт этого не увидит: соединение всё равно придёт с IP прокси. Но провайдер и любой, кто видит ваш DNS, узнает, какие сайты вы открываете. Режим fake-ip в mihomo и передача домена прокси-серверу после сниффинга в sing-box снижают эту проблему. Подробнее о проверках и способах защиты — в разборе методов защиты от DNS-утечек.

3. Конфликт с другим VPN или антидетектом

Два TUN-интерфейса одновременно — гарантированный хаос в маршрутах. Если в антидетект-браузере у профиля уже свой прокси, его трафик лучше вывести из TUN: правилом по имени процесса отправить браузер в direct, и тогда каждый профиль ходит через свой прокси, как и задумано.

4. Системная маршрутизация не заменяет антидетект

Все программы на компьютере будут выходить в сеть с одного IP на домен. Для одного магазина это нормально. Для 10 аккаунтов на одной площадке — нет: площадка видит одинаковый отпечаток браузера и один адрес. Для мультиаккаунтинга маршрутизация по доменам — вспомогательный инструмент, а не замена связке «отдельный профиль + отдельный прокси».

5. Ротация IP посреди сессии

Если прокси настроен на смену IP при каждом запросе, сайт с авторизацией будет видеть новый адрес на каждой загрузке картинки. Для кабинетов, магазинов и соцсетей берите логин со sticky-сессией (фиксированный IP на время работы) или ротацию по таймеру с интервалом в десятки минут.

6. Прокси без поддержки нужного протокола

Если провайдер даёт только HTTP-прокси, в sing-box используйте выход типа http, в mihomo — type: http. Оба движка поддерживают логин и пароль и для HTTP. Если же программа сама не умеет работать с прокси с авторизацией, а TUN поднимать не хочется, подойдёт локальный шлюз на gost, 3proxy или Squid.

Какой прокси ставить в правило

  • Маркетплейсы, соцсети, кабинеты продавца, рекламные кабинеты — резидентные прокси нужной страны со sticky-сессией. Адрес домашнего провайдера вызывает меньше всего вопросов у антифрода.
  • Площадки с самой жёсткой проверкой (мобильные приложения, TikTok, Instagram) — мобильные прокси: за одним IP оператора одновременно выходят в сеть множество реальных абонентов.
  • API, документация, пакетные репозитории, сервисы без антибот-защиты — датацентровые прокси: они дешевле и быстрее, а для таких задач «домашний» IP не нужен.

Удобно завести в конфиге несколько выходов разных типов и раскидать по ним домены, а не гонять всё через самый дорогой.

Итог

Маршрутизация по доменам превращает прокси из «рубильника» в точный инструмент: нужные сайты всегда открываются с нужного IP, остальной трафик не тратит оплаченные гигабайты. Для старта хватает 30 строк конфига. Главное — не забыть сниффинг (или fake-ip), отключить QUIC для проксируемых доменов, собрать полный список доменов сервиса и брать актуальный синтаксис: конфиги под sing-box до 1.12 на свежих версиях не запустятся.