Технологии / ClashMi — параметры приложения

ClashMi — документация по параметрам (RU)

Обновлено 28 августа 2026~37 мин чтения

Справочник по всем настройкам приложения ClashMi (GUI-клиент поверх ядра mihomo / Clash.Meta). Составлено по исходникам приложения: строки локализации (lib/i18n/strings_en.g.dart), экраны настроек (lib/screens/group_helper.dart, home_screen_widgets.dart, net_check_screen.dart) и значения по умолчанию (lib/app/modules/*, lib/app/clash/clash_config.dart).

В скобках у многих пунктов указан ключ конфига mihomo (то, что в приложении показывается серой подсказкой-tips) — по нему удобно искать документацию mihomo. Официальная документация ядра: <https://wiki.metacubex.one/>

Оглавление:

• Частые задачи (быстрый старт)
• 1. Режимы прокси: Rule / Global / Direct
• 2. Инструменты на главном экране: Board, Runtime Profile, Network Check
• 3. App Settings — настройки приложения
• 4. Core Settings — настройки ядра
• 4.1 TUN
• 4.2 DNS
• 4.3 NTP
• 4.4 TLS
• 4.5 Sniffer
• 4.6 Geo RuleSet
• 4.7 LAN device access
• 4.8 Diversion Template
• 5. Board — панель zashboard подробно
• 6. Network Check — диагностика подробно
• 7. Настройки под производительность
• Поддерживаемые платформы и версии

Частые задачи (быстрый старт)

Не хотите читать всё — вот куда идти под конкретную цель:

Дальше — полный справочник по разделам.

1. Режимы прокси: Rule / Global / Direct

Переключатель на главном экране (сегментированная кнопка под индикатором подключения). Определяет как ядро выбирает исход для каждого соединения. Меняется на лету, без переподключения.

Подробнее про Global. GLOBAL — это не сервер, а встроенная группа-селектор, в которую mihomo автоматически включает все узлы конфига. В режиме Global правила rules не действуют вообще: весь трафик уходит в тот узел, что выбран в группе GLOBAL (на главном экране ClashMi при этом режиме показывается цепочка именно этой группы, и там же переключается узел). Полезно для диагностики (работает ли узел без влияния правил) или чтобы принудительно пустить всё за границу. Минусы: игнорируются доменные DIRECT-исключения — российские сервисы/банки поедут через зарубежный узел (гео-блоки, капчи, замедление); не режется реклама (REJECT-правила выключены); может отвалиться доступ в локальную сеть (GEOIP,private,DIRECT тоже не применяется). Для повседневного использования лучше Rule, а Global включать точечно и потом возвращаться обратно.

Сопутствующие понятия (не режимы, а цели правил — встречаются в rules и прокси-группах): DIRECT — напрямую, REJECT/Block — заблокировать (соединение обрывается), PASS — пропустить правило дальше. Полный набор типов прокси-групп в ClashMi: URLTest, Selector, LoadBalance, Fallback, Direct, Compatible, Pass, Reject, RejectDrop.

2. Инструменты на главном экране

Помимо переключателя режима, на главном экране есть три диагностических пункта.

Board

Встроенная веб-панель управления ядром (dashboard типа zashboard/yacd/metacubexd). Открывает интерфейс, где видно активные соединения, логи, прокси-группы, задержки, и где можно вручную переключать выбранный узел в группах.

• Работает поверх External Controller ядра (см. Core Settings).
• Может быть локальной (ядро само поднимает панель на Local Board Port) или онлайн (внешний URL панели) — переключается в App Settings → Use Online Board.
• На мобильных панель поднимается на время просмотра и гасится при выходе.

Подробный разбор вкладок панели и ответ на вопрос «откуда берутся подключения» — см. §5. Board — панель zashboard подробно.

Runtime Profile

Показывает итоговый рабочий конфиг, который реально запущен в ядре, — уже после применения всех overwrite/patch (исходный профиль → Custom Overwrite → App Overwrite). Это файл serviceCoreRuntimeProfile, доступный только для чтения. Главный инструмент отладки: «а что на самом деле сейчас крутится в mihomo».

Network Check (Network Check)

Экран сетевой диагностики по конкретному домену. Проверяет 4 стадии и помогает понять, где именно рвётся доступ:

Логика чтения: если стадия 3 (Proxy) работает, а 2 (TUN) — нет, проблема в TUN/маршрутах; если не резолвится DNS (стадия 1) — проблема в DNS-настройках.

Подробный разбор всех проверок, значение «подозрения на подмену DNS» и таблица «результат → диагноз» — см. §6. Network Check — диагностика подробно.

3. App Settings — настройки приложения

Настройки самого приложения (интерфейс, обновления, поведение), не влияют на конфиг ядра. Часть пунктов видна только на определённых платформах.

Пункты ниже — платформозависимые:

Подробно: Log Level, User-Agent и Delay Test

Log Level (логирование приложения)

Уровень подробности логов самого приложения ClashMi (Flutter-часть): импорт профилей, сетевые запросы приложения, ошибки UI. Значения по нарастанию детализации: trace → debug → info → warning → error (каждый следующий пишет меньше, только более важное).

• Зачем. Диагностика проблем именно на стороне приложения: не импортируется подписка, не открывается экран, странные ошибки. Для баг-репорта временно ставят debug/trace, воспроизводят проблему, копируют лог — и возвращают обратно.
• Важно не путать с Core Settings → Log Level (debug/info/warning/ error/silent). Это два разных лога: здесь — про интерфейс/приложение, там — про работу ядра mihomo (маршрутизация, соединения, DNS). Для проблем «сайт не открывается / узел не работает» нужен лог ядра, а не приложения.
• Цена детализации. trace/debug заметно многословны и могут слегка нагружать устройство и засорять журнал — для повседневного использования держите warning.

User-Agent

HTTP-заголовок User-Agent, с которым приложение скачивает профили/подписки (не путать с UA вашего браузинга — на реальный трафик через VPN он не влияет).

• Значение по умолчанию (когда поле пустое): ClashMeta/<версия ядра>; mihomo/<версия ядра>.
• Зачем это вообще нужно. Многие панели-провайдеры (V2Board / SSPanel / Xboard и т.п. — ClashMi умеет в них логиниться) отдают разный формат конфига в зависимости от User-Agent: увидев в UA clash/mihomo, сервер вернёт Clash/mihomo-YAML; другому клиенту — базовый base64 или sing-box-JSON. Поэтому «правильный» UA нужен, чтобы подписка вообще пришла в понятном ClashMi виде.
• Когда менять вручную. Если ваш провайдер привязывает выдачу к конкретному клиенту (например, ждёт Happ, v2rayNG, Clash-verge и т.п.) — вписав нужную строку, вы «прикидываетесь» этим клиентом и получаете корректный конфиг. В штатном случае поле оставляют пустым (дефолт mihomo-UA работает почти везде).

Delay Test URL / Timeout — и что такое «пинг до сервера»

Эти два поля управляют замером задержки узлов — той самой цифрой в мс, что видна у каждого сервера в списке прокси (кнопка «молния»/пинг).

• Delay Test URL — адрес, до которого идёт проба. По умолчанию https://www.gstatic.com/generate_204.
• Delay Test Timeout(ms) — сколько ждать ответ; по умолчанию 5000 мс. Не ответил за это время → узел помечается как недоступный (задержка «—»).

Как считается «пинг» (важно!). Это не ICMP-ping до IP сервера и не ваша задержка «телефон → IP узла». ClashMi просит ядро выполнить HTTP-пробу командой /proxies/<узел>/delay?url=<Delay Test URL>&timeout=<мс>: ядро через этот конкретный узел открывает соединение до тест-URL и замеряет время до ответа в миллисекундах. То есть цифра отражает сквозную задержку всего пути:

вы → прокси-узел → тест-сайт (generate_204) → ответ обратно

Отсюда практические следствия:

• Цифра включает и ваш канал до узла, и канал узла до тест-сайта, и TLS/HTTP-хендшейк — это реальная «отзывчивость» через узел, а не голый сетевой ping. Поэтому она обычно выше, чем ICMP-ping до того же IP.
• Меньше — лучше. Прочерк/таймаут = узел не ответил за отведённое время (лёг, заблокирован, или тест-URL недоступен из его локации).
• Выбор URL имеет значение. generate_204 идеален для пробы: отдаёт пустой HTTP 204 мгновенно. Если поставить тест-URL, который из страны узла заблокирован (напр. что-то, недоступное с этого сервера), узел покажет таймаут, хотя для остального трафика он рабочий. Обратная хитрость: можно поставить URL сервиса, который вам реально важен (напр. проба до нужного вам ресурса), — тогда «пинг» покажет отзывчивость именно к нему.
• Группы типа URLTest используют ровно этот механизм, чтобы автоматически выбирать самый быстрый узел; связанный параметр ядра unified-delay делает замер честнее (двойной хендшейк, чтобы исключить разброс на установке TCP/TLS).

Итог одним предложением: «пинг до выбранного сервера» в ClashMi = время полного HTTP-запроса до Delay Test URL, проложенного через этот сервер, а не пинг до его IP.

Wake Lock (Android) — отзывчивость vs батарея

Тумблер Wake Lock (App Settings, только Android) держит процессор активным, пока VPN включён, чтобы система в простое (Doze/deep-sleep) не «усыпляла» туннель. Без него при погашенном экране соединение может подвисать/рваться, а при пробуждении VPN «оживает» с лагом (первые запросы отваливаются).

Чем платишь и грабли:

• Батарея — главный минус: постоянный Wake Lock не даёт устройству уйти в глубокий сон.
• OEM-«убийцы» фона (MIUI/HyperOS, EMUI, ColorOS, OneUI) прибивают процесс независимо от Wake Lock — нужно ещё отключить оптимизацию батареи для приложения и разрешить автозапуск. Без этого Wake Lock на таких прошивках бесполезен.
• Держит процессор, не радио — Wi-Fi/модем всё равно могут идлить.
• Иногда обрывы — это не Doze, а NAT-таймаут оператора, дропающий идлящее соединение; Wake Lock лишь держит приложение живым для быстрого reconnect, сам разрыв не лечит.

Рекомендация: по умолчанию держать выключенным (экономия батареи), включать точечно, если «после сна VPN тупит/отваливается», и обязательно в паре с «отключить оптимизацию батареи».

4. Core Settings — настройки ядра

Настройки ядра mihomo — то, что попадает в рабочий конфиг. Изменения применяются после переподключения (в приложении об этом висит зелёная подсказка: «After modifying the configuration, you need to reconnect to take effect»).

Механика Overwrite (важно понимать): итоговый конфиг собирается по цепочке Исходный профиль ← Custom Overwrite ← App Overwrite. То есть эти настройки «перекрывают» то, что пришло в подписке. У большинства блоков (TUN, DNS, NTP, TLS, Sniffer, LAN) есть тумблер Overwrite — пока он выключен, значения берутся из профиля, а блок не трогается; включив его, вы переопределяете блок настройками из приложения.

Основной список Core Settings

Блок ниже отображается только для встроенного/пустого патча (не показывается, если выбран пользовательский Custom Overwrite):

Кнопка сохранения на этом экране (иконка файла) показывает итоговый сгенерированный патч-конфиг — можно посмотреть, что уйдёт в ядро.

Per-App Proxy (Android) — экран выбора приложений:

• Whitelist Mode — режим белого списка. Включён: в прокси идут только отмеченные приложения. Выключен (чёрный список): в прокси идут все, кроме отмеченных.

4.1 TUN

Виртуальный сетевой интерфейс — перехват всего трафика системы. На мобильных поднимается через системный VpnService (тумблер запуска = включение TUN).

Android:

iOS / macOS (низкоуровневые флаги NetworkExtension, у каждого своя мин. версия ОС):

💡 На пальцах (Network stack): это то, как приложение «врезается» в сеть. system = напрямую в ядро ОС — быстрее, но капризнее (нужны права, не работает при включённом фаерволе). gvisor = свой софтверный стек — совместимее, но грузит процессор. mixed — TCP через ядро (скорость) + UDP через gvisor (совместимость). Не знаете что выбрать — оставьте gvisor; тормозит на ПК/Android — попробуйте mixed. На iOS/macOS выбора нет — только gvisor.

4.2 DNS

Как ядро резолвит домены. Критично для работы TUN (см. режим fake-ip).

💡 На пальцах (fake-ip): на вопрос «какой IP у сайта?» ядро мгновенно отдаёт фейковый адрес (из диапазона 198.18.x.x), а настоящий резолвит уже выбранный сервер. Зачем: (1) быстрее — не ждём реального DNS; (2) провайдер не видит, какие сайты вы открываете; (3) маршрут выбирается по домену, а не по IP. Для TUN это лучший режим. Что-то ломается (STUN/игры/локальные сервисы) — добавьте такой домен в fake-ip-filter.

4.3 NTP

Встроенный NTP-клиент ядра (нужен, например, протоколам с проверкой времени — VMess/Reality-подобным).

4.4 TLS

Пользовательские TLS-сертификаты для ядра (RESTful API поверх TLS, MITM-функции и т.п.).

4.5 Sniffer

Определение реального протокола/домена внутри соединения (по трафику), даже если клиент ушёл по IP. Помогает точнее применять доменные правила.

💡 На пальцах (Sniffer): иногда приложение подключается сразу по IP, без домена — и доменные правила (пустить youtube.com через нужный узел) не срабатывают. Сниффер подсматривает домен внутри самого соединения и «возвращает» его правилам. Зачем: чтобы маршрутизация по доменам работала, даже когда клиент ушёл по голому IP. Обычно держат включённым.

4.6 Geo RuleSet

Источники и обновление гео-баз (GeoSite/GeoIP), которые ClashMi преобразует в RuleSet. На iOS правила IP-ASN/SRC-IP-ASN игнорируются (ограничения памяти).

4.7 LAN device access

Доступ к прокси с других устройств локальной сети (например, раздать прокси на роутер/ТВ).

Осторожно: включённый allow-lan без аутентификации делает ваш прокси открытым для всей локальной сети.

4.8 Diversion Template

Шаблоны маршрутизации, из которых собираются правила и группы конфига.

Как завести своё правило (пошагово): этот домен — напрямую, тот — через нужную ноду. Правило собирается в два шага: (A) создать шаблон правил, (B) на профиле включить его и выбрать, КУДА направить трафик. Так правило переживает обновление подписки — это отдельный override-слой, саму подписку он не меняет.

Русский перевод меню машинный: Diversion Templates там называется «Шаблон сортировки пациентов», Proxy Groups — «Группа агентов». Путаетесь — переключите язык на English.

Шаг A — создать шаблон правил. Настройки → Diversion Templates → Rule Templates → «＋»:

1. Name — любое имя (напр. direct-list, via-de).
2. Внутри шаблона «＋» добавьте правило: Type (тип совпадения — таблица ниже) + значение (домен/IP). Для IP-типов включите тумблер NO-RESOLVE. Правил в один шаблон можно много — все уйдут в одну цель.
3. Сохраните. Цель (куда направить) здесь не выбирается — только «что ловим».

Шаг B — привязать к профилю и выбрать цель.

1. Сделайте нужный профиль активным и подключитесь — без активного подключения список узлов для выбора цели не подтянется.
2. Настройки профиля → раздел Rules → включите Overwrite [Rules].
3. Тапните свой шаблон и выберите цель из живого списка выходов: DIRECT (напрямую, мимо VPN), имя конкретной ноды, главную группу-селектор или авто-группу по пингу (URLTest).
4. Переподключитесь — правило применится.

Типы правил (пикер Type):

💡 На пальцах: для «весь сайт целиком» берите DOMAIN-SUFFIX (ловит и поддомены). DOMAIN — строго один хост. IP-типы (IP-CIDR/GEOIP/IP-ASN) требуют NO-RESOLVE, иначе ядро зря резолвит домен в IP. GEOSITE — готовая пачка доменов, не перечисляя руками.

Примеры (Type · значение · цель → строка правила):

• ya.ru напрямую: DOMAIN-SUFFIX · ya.ru · DIRECT → DOMAIN-SUFFIX,ya.ru,DIRECT (с поддоменами).
• строго один хост: DOMAIN · ya.ru · DIRECT → DOMAIN,ya.ru,DIRECT.
• сайт через конкретную ноду: DOMAIN-SUFFIX · figma.com · 🇩🇪 DE-Node → DOMAIN-SUFFIX,figma.com,🇩🇪 DE-Node.
• по IP напрямую: IP-CIDR · 8.8.8.8/32 + NO-RESOLVE · DIRECT → IP-CIDR,8.8.8.8/32,DIRECT,no-resolve.

Грабли:

• Имя ноды-цели берётся из вашей подписки — «через ноду» работает, только если она в ней есть.
• Профиль должен быть активным и подключённым в момент выбора цели.
• Не включили Overwrite [Rules] или не переподключились → правило не применится.
• Правила читаются сверху вниз, срабатывает первое совпавшее — свой шаблон кладётся выше общего MATCH.

5. Board — панель zashboard подробно

Локальный Board в ClashMi — это встроенный сторонний open-source веб-дашборд zashboard, вшитый в приложение (assets/zashboard/, собранная PWA ~3.9 МБ) и раздаваемый локальным HTTP-сервером на 127.0.0.1:<Local Board Port> (по умолчанию 7066). Он подключается к RESTful API работающего ядра mihomo (адрес/порт/secret берутся из External Controller) и через этот API показывает и меняет состояние ядра в реальном времени. Из интернета ничего не тянется — панель работает офлайн; сервер слушает только 127.0.0.1, доступ к API защищён Secret.

Ниже приведены текстовые схемы-макеты вкладок (это схемы, а не скриншоты).

Вкладки панели

zashboard разбит на вкладки (русские названия — из локализации самой панели): Обзор, Прокси, Подключения, Правила, Журнал, Настройки.

Обзор

Сводка в реальном времени: текущая скорость ↑/↓, число активных подключений, память ядра, график трафика.

[СХЕМА, не скриншот]
┌──────────────────────────────────────────────┐
│ zashboard              Обзор ▾            🌙   │
├──────────────────────────────────────────────┤
│  ↑ Выгрузка 1.2 MB/s      ↓ Загрузка 5.4 MB/s │
│  Активные: 37             Память ядра: 84 MB  │
│  ┌──────────── график трафика ─────────┐      │
│  │        ╱╲     ╱╲╱╲                   │      │
│  └─────────────────────────────────────┘      │
└──────────────────────────────────────────────┘

Прокси

Список прокси-групп и узлов. Здесь можно прогнать задержку (пинг) и вручную выбрать узел в группах типа Selector — это единственный способ из панели повлиять на маршрут (см. ниже про правила).

[СХЕМА, не скриншот]
┌──────────────────────────────────────────────┐
│  Прокси                          [Тест ⚡]     │
│  GLOBAL  (Selector)                            │
│    ● 🇺🇸 US-1      42 ms                        │
│    ○ 🇳🇱 NL-2      68 ms                        │
│  YouTube (Selector)                            │
│    ● 🇫🇮 FI-Node   30 ms                        │
└──────────────────────────────────────────────┘

Подключения

Живой список соединений, которые ядро прямо сейчас обрабатывает. Переключатель Активные / Закрытые (Закрытые — недавно завершённые за текущую сессию панели, сбрасываются при перезапуске). Есть фильтр/поиск. По каждому соединению доступна кнопка Закрыть.

Колонки (реальные из zashboard): Источник (локальный IP:порт), Хост (домен/адрес назначения), Процесс (какое приложение инициировало), Правило (какое правило сработало), Цепочки (через какую группу/узел идёт, или Прямое = DIRECT), Сеть (TCP/UDP), Тип, Загрузка/Скорость, Время (длительность), Задержка.

[СХЕМА, не скриншот]
┌───────────────────────────────────────────────────────────────┐
│ Подключения     [Активные] Закрытые          🔎 фильтр…        │
├──────────────┬────────────────────┬───────────┬───────────────┤
│ Хост         │ Процесс            │ Правило   │ Цепочки        │
├──────────────┼────────────────────┼───────────┼───────────────┤
│ chatgpt.com  │ com.openai.chatgpt │ GEOSITE,  │ GLOBAL→🇺🇸US-1 │
│ :443  TCP    │                    │ openai    │ ↑2KB ↓40KB 8s  │
│ *.push.apple │ apsd (система)     │ MATCH     │ Прямое         │
│ vk.com:443   │ Chrome             │ GEOSITE,ru│ Прямое  ↑1KB   │
│ mtalk.google │ com.google.gms     │ MATCH     │ GLOBAL→🇺🇸US-1 │
└──────────────┴────────────────────┴───────────┴───────────────┘

Правила

Список правил маршрутизации текущего конфига — только для чтения. Отсюда правила менять нельзя (ограничение Clash API: эндпоинт /rules доступен лишь на чтение). Также показывает подключённые Rule Providers.

[СХЕМА, не скриншот]
┌──────────────────────────────────────────────┐
│  Правила (только чтение)         Rule Providers│
│  0  DOMAIN-SUFFIX,openai.com    → GLOBAL       │
│  1  GEOSITE,category-ru         → Прямое       │
│  2  GEOIP,private               → Прямое       │
│  …                                             │
│  N  MATCH                       → GLOBAL       │
└──────────────────────────────────────────────┘

Журнал

Логи ядра в реальном времени (уровень — как в Core Settings → Log Level). Полезно видеть, какое правило сматчилось и куда ушло соединение.

Настройки

Настройки самой панели: адрес External Controller (host/port/secret), тема, язык, период обновления. К конфигу ядра отношения не имеют.

Откуда берутся подключения (и почему там GPT, хотя я к нему не заходил)

Ключевой момент: вкладка Подключения — это не история ваших действий, а live-срез всего, что ядро проксирует в данный момент. Панель подписана на поток /connections API ядра (websocket) и показывает соединения по мере их появления.

А теперь главное: при включённом TUN через ядро проходит трафик всех приложений и системы на устройстве — не только того, что вы осознанно открыли. Поэтому «Подключения» = рентген всей сетевой активности телефона в реальном времени.

Почему вы видите chatgpt.com / openai, хотя «не заходили»:

1. Фоновая активность приложения. Если установлено приложение ChatGPT (или оно висит в фоне) — оно само периодически стучится на свои серверы: обновление сессии, синхронизация, загрузка конфигов, аналитика. Это происходит без вашего участия.
2. Пуш-уведомления и телеметрия. Постоянные keep-alive к push-серверам (в схеме выше — push.apple, mtalk.google для FCM), плюс отправка телеметрии.
3. Открытая вкладка/виджет/webview. Вкладка браузера на chatgpt.com, PWA, виджет или встроенный в другое приложение webview продолжают фоновые запросы.
4. Предзагрузка/предрезолв. Браузеры заранее коннектятся и резолвят домены, которые «могут понадобиться».
5. fake-ip / sniffer подписывают соединение доменом, поэтому вы прямо видите chatgpt.com, даже если фоновый запрос шёл по IP.

Как проверить, кто именно инициировал: смотрите колонку Процесс — там имя приложения/пакета. (На Android для заполнения этой колонки нужен Core Settings → Find Process Mode = always или strict.) Если это фоновый процесс — можно нажать Закрыть на соединении или выгрузить приложение; но обычно это нормальный фоновый шум, а не что-то тревожное.

Вывод: появление GPT в списке почти всегда означает, что установленное приложение ChatGPT или открытая где-то страница обращаются к своим серверам в фоне. Это ожидаемо для TUN-режима, где виден весь трафик устройства.

Что через Board можно и нельзя

6. Network Check — диагностика подробно

Network Check (главный экран → доп. инструменты) — встроенный сетевой диагност по одному домену. Вводите домен (по умолчанию example.com; для реальной диагностики вбивайте тот, что не открывается — chatgpt.com, youtube.com и т.п.), жмёте Check — и приложение по очереди выполняет 4 проверки. Кнопка копирования вверху выгружает весь отчёт (домен, ОС, все 4 секции) — удобно приложить в тикет поддержки.

Важно: проверки идут сверху вниз и независимо, поэтому смотреть надо не на одну строку, а на комбинацию результатов — именно она указывает на слой, где ломается.

Что делает каждая проверка (по коду)

1. DNS Query. Резолвит домен через DNS самого ядра (запрос к API /dns/query, типы A и AAAA) — то есть ровно так, как ядро резолвит его в бою, с вашими настройками DNS из профиля. Для каждого полученного IP:

• IP публичный/маршрутизируемый → строка вида A: 203.0.113.10 (норма);
• IP не публичный (0.0.0.0, 127.x, 10.x, 192.168.x, 169.254.x, прочие приватные/зарезервированные, ::1, fc00::/7) → строка помечается [Suspected DNS poisoning] — подозрение на подмену;
• запрос не удался → A query failed: <причина>; пустой ответ → A: <empty>.

2. HTTP (via TUN). Сначала проверяет tun.enable: если TUN выключен — пишет «TUN is not enabled» и пропускает. Если включён — делает HTTPS-запрос https://<домен>/ в режиме DIRECT (без явного прокси-порта). Но так как TUN включён, этот «прямой» сокет всё равно перехватывается TUN → уходит в ядро → маршрутизируется по правилам. То есть это сквозной путь, как у обычного приложения: приложение → TUN → ядро → правила → наружу. Успех = HTTP 200, таймаут 15 с.

3. HTTP (via Proxy, port: N). Тот же HTTPS-запрос, но явно через локальный прокси-порт ядра (PROXY 127.0.0.1:<mixed-port>), в обход TUN. Проверяет связку ядро + прокси-узел напрямую, независимо от TUN и таблицы маршрутов.

4. Route Table (не на iOS). Выгружает таблицу маршрутизации ОС — видно, установил ли TUN свои маршруты (дефолт через TUN-шлюз). Нужна, когда TUN включён, но трафик мимо него.

Что такое «подозрение на подмену DNS»

Флаг ставится по простому признаку: ядро вернуло для домена не-публичный IP. Это классическая сигнатура DNS-инъекции со стороны цензора (ТСПУ/GFW): на plain-DNS (UDP :53) в ответ на запрос заблокированного домена подсовывается поддельная запись, ведущая в «никуда» — 0.0.0.0, 127.0.0.1 или приватный диапазон. Клиент честно коннектится по этому адресу, попадает в пустоту — сайт «не работает».

Поскольку проверка идёт через ваш DNS ядра, результат фактически отвечает на вопрос: «чистое ли у меня сейчас разрешение имён для этого домена?»

• Если DNS настроен на подменяемый апстрим (провайдерский :53) → увидите подмену.
• Если DNS идёт через DoH/DoT за рубеж или fake-ip → подмена обходится, увидите либо реальный публичный IP, либо fake-ip-адрес.

⚠️ Ложные срабатывания. Если домен легитимно резолвится в приватный адрес (внутренний сервис, self-hosted, что-то в вашей локалке) — проверка тоже пометит его как «подмену», хотя это норма. Флаг — это подсказка, а не приговор.

Нюанс fake-ip: в режиме enhanced-mode: fake-ip ядро отдаёт домену адрес из диапазона 198.18.0.0/16. Он публичный по формальному признаку, так что как «подмена» он не помечается — это ожидаемо.

Таблица «результат → диагноз»

Правило чтения по слоям: DNS (1) — чистое ли имя; Proxy (3) — жив ли сам узел/ядро; TUN (2) — доходит ли до приложений; Route Table (4) — установлен ли перехват. Идёте снизу вверх: если 3 (Proxy) хорошо, а 2 (TUN) плохо — чините TUN/маршруты, а не узел.

Как пользоваться — по шагам

1. Столкнулись, что сайт не открывается → откройте Network Check, введите его домен (не example.com).
2. Нажмите Check, дождитесь всех 4 секций.
3. Сверьтесь с таблицей выше: комбинация DNS / Proxy / TUN покажет слой проблемы.
4. Если ничего не понятно — нажмите копировать и приложите отчёт в поддержку.

7. Настройки под производительность

Что крутить ради скорости и чем за это платишь. Сами параметры описаны выше — здесь сведено «для скорости → последствие».

Главный рычаг — не тумблер, а нода. Большая часть «тормозит» лечится сменой на ближнюю/менее загруженную ноду (или авто-группой по пингу), а не настройками. Стек system/mixed — второй по величине выигрыш.

Из обсуждений сообщества (mihomo): приоритет стеков по скорости — system ≳ mixed ≫ gvisor (gvisor целиком в userspace → самый прожорливый по CPU, на слабом железе +30–50% нагрузки; ядро-стеки берут аппаратное ускорение). Держите fake-ip, но исключайте из fake-ip-filter STUN/локалку/ сетевые проверки, иначе часть приложений ломается. Источники: mihomo wiki · TUN, mihomo wiki · DNS, гайд Clash Meta 2026.

Чего НЕ включать: мультиплексирование (mux), если попадётся — для VLESS+Vision/Reality оно режет параллельную скорость и мешает Vision; выигрыш только на «дорогих» рукопожатиях.

Поддерживаемые платформы и версии

По официальному README и сборочным конфигам ClashMi (ядро — Flutter):

• На десктопах системный TUN-стек (system/mixed) требует повышенных прав и не работает при включённом фаерволе → тогда gvisor (см. §7).
• На старых Android/слабом железе system-стек может быть недоступен — останется gvisor.

Приложение: значения по умолчанию (сводка)

Документ отражает исходники ClashMi на момент 2026-07-13 (ветка feature/mihomo-clash-sub). Названия пунктов даны по английской локализации — в приложении с русским языком часть из них переведена.