todo/Clash/06-features-protocols.md
loop-uh 08b4491545
Some checks failed
Published content check / validate (push) Failing after 3s
Завершить переезд базы знаний на Forgejo
Обновить правила репозитория и подписи исходников в 99 заметках, не затрагивая пользовательские незакоммиченные файлы. Сделать Forgejo Actions содержательным: проверять опубликованный commit, а не пустое рабочее дерево после checkout.
2026-08-07 08:27:28 +03:00

26 KiB
Raw Permalink Blame History

date tags aliases link
2026-07-25
clash
mihomo
протоколы
маршрутизация
dns
tun
Возможности mihomo
Протоколы mihomo
Что умеет mihomo
mihomo features
https://wiki.metacubex.one/

🚀 Возможности и протоколы mihomo: что ядро умеет в 2026 году

[!info] О чём заметка Разбор актуальных возможностей ядра mihomo (бывший Clash.Meta) — какие протоколы оно поддерживает как клиент и как сервер, чем маскирует трафик, как устроены TUN, DNS-подсистема, сниффер и наборы правил. Что такое mihomo и откуда он взялся — в заметке Clash/02-mihomo; базовое устройство конфига Clash (порты, группы, правила, fake-ip) разобрано в Clash/01-clash-core и здесь не повторяется.

[!warning] Списки функций устаревают быстрее заметок Ядро mihomo выпускает релизы с новыми протоколами раз в несколько недель, поэтому перечни ниже — срез на 25 июля 2026 (стабильная версия v1.19.29 от 18 июля 2026 и релизные заметки предшествующих версий). Перед настройкой сверяйтесь с официальной документацией и списком релизов: часть функций живёт только в ветке Alpha, часть требует свежей версии, а имена полей иногда меняются.

TL;DR

  • Как клиент mihomo умеет практически весь современный набор: Shadowsocks/SSR, VMess, xray/vless (с xray/reality и XTLS Vision), Trojan, Hysteria/00-overview, TUIC, WireGuard, ShadowTLS, Snell, SSH, AnyTLS, а в свежих версиях — ещё Tailscale, OpenVPN и реле GOST.
  • Как сервер он поднимает listeners по большинству тех же протоколов — то есть работает входной точкой для других устройств, а не только исходящим клиентом.
  • Маскировка: uTLS-отпечатки браузеров (client-fingerprint), REALITY, ShadowTLS, обфускации restls и jls, мультиплексирование через smux/h2mux, транспорты WebSocket, gRPC, HTTP/2 и XHTTP.
  • Перехват трафика: TUN с тремя сетевыми стеками (system, gvisor, mixed), redir/TPROXY на Linux, авто-настройка маршрутов и правил.
  • Правила стали заметно мощнее оригинала: логические AND/OR/NOT, GEOSITE, IP-ASN, DOMAIN-REGEX, подправила sub-rules, наборы правил в компактном бинарном формате .mrs.
  • Сниффер восстанавливает домен из TLS SNI, HTTP Host и QUIC — благодаря ему доменные правила работают даже когда приложение подключается по «голому» IP.

Протоколы: исходящие подключения

Полезно сразу разделить два слоя, которые в подписках часто перемешаны в одну строку. Протокол отвечает за то, как устроены сами данные внутри соединения (VLESS, Trojan, Shadowsocks). Транспорт и маскировка — за то, во что это соединение завёрнуто снаружи (TLS, WebSocket, gRPC, REALITY, обфускаторы). Одна и та же связка «протокол + транспорт» должна совпадать у клиента и сервера, иначе соединение не установится вовсе.

Протокол Особенности реализации в mihomo
protocols/shadowsocks / SSR Классика экосистемы; современные AEAD-шифры и методы редакции 2022, плагины обфускации, в свежих версиях — обфускация jls
protocols/vmess Наследие v2ray; поддерживает транспорты WS/gRPC/HTTP2 и мультиплекс, в релизах 2026 добавлены mkcp и tlsmirror
VLESS Основной протокол современных подписок: работает с [[xray/reality
protocols/trojan Маскировка под обычный HTTPS; сочетается с WS/gRPC и обфускациями
Hysteria / Hysteria2 QUIC поверх UDP, устойчивость к потерям, обфускация и port hopping — сам протокол разобран в [[Hysteria/00-overview
protocols/tuic (v4/v5) Ещё один QUIC-протокол с быстрым установлением UDP-сессий и режимами релея native/quic
WireGuard Полноценный WG-клиент прямо в ядре — можно использовать как обычный outbound наравне с прокси
protocols/shadowtls Обёртка, прячущая произвольный протокол за настоящим TLS-рукопожатием с чужим доменом (учитывайте известные с 2025 года проблемы обнаружения v3)
Snell Протокол из клиента Surge; в mihomo версии до v4, в свежих релизах — с поддержкой shadow-tls
SSH Туннель через обычный SSH-сервер
protocols/anytls Протокол 2025 года с акцентом на борьбу с детектом «TLS внутри TLS»; в mihomo поддерживается и как outbound, и как listener
Tailscale, OpenVPN, GOST Добавлены в релизах середины 2026: подключение к сети Tailscale, клиент OpenVPN (включая tls-crypt-v2), реле в формате GOST

Чего в mihomo нет — тоже стоит знать заранее: protocols/naiveproxy здесь не реализован, и подписку с ним придётся открывать другим ядром (см. Clash/08-vs-sing-box).

Проще говоря: mihomo перестал быть «клиентом Clash с парой протоколов» и превратился в универсальный комбайн — по широте набора он сопоставим с sing-box/sing-box-extended и xray/project-x, а по некоторым экзотическим позициям (OpenVPN, Tailscale, GOST в одном бинарнике) местами их обгоняет.

Протоколы: входящие подключения (listeners)

Раздел listeners в конфиге — это серверная сторона. mihomo может слушать порт и принимать подключения по HTTP, SOCKS, смешанному порту, Shadowsocks, VMess, VLESS, Trojan, TUIC, Hysteria2, AnyTLS, WireGuard, а также в режимах прозрачного перехвата (redir, tproxy, tun).

Практический сценарий: mihomo стоит на домашнем роутере или на мини-ПК, принимает трафик всех устройств в квартире как обычный прокси-сервер и уводит его наружу через ваши узлы по общим правилам. Телефонам и телевизорам при этом не нужен собственный клиент — им достаточно указать шлюз. Второй сценарий — цепочка: mihomo на VPS принимает подключения по VLESS и передаёт их дальше, в другой выходной узел.

[!note] Сервер на mihomo — это не то же самое, что панель управления Ядро умеет принимать соединения, но не занимается учётом пользователей, лимитами и биллингом. Если нужен многопользовательский сервер с выдачей подписок, для этого существуют панели поверх Xray (3x-ui, Marzban — упомянуты в xray/project-x) или управляющая подсистема форка sing-box/architecture. mihomo в роли сервера — это скорее шлюз для своих устройств, чем сервис для клиентов.

Маскировка и транспорты

Задача маскировки — сделать так, чтобы DPI не отличал прокси-соединение от обычного веб-трафика. mihomo даёт несколько независимых слоёв, которые комбинируются.

uTLS-отпечатки. Глобальный параметр client-fingerprint (значения вида chrome, firefox, safari, ios, random) заставляет ядро повторять TLS-рукопожатие популярного браузера. Без этого у Go-программы получается собственный, легко узнаваемый почерк — по нему прокси-клиент вычисляется без всякой расшифровки трафика. Механика самого детекта по отпечатку рукопожатия разобрана в DPI/browser-ja4-fingerprint-block.

REALITY. Прикрытие настоящим чужим сайтом: клиент выполняет рукопожатие так, что стороннему наблюдателю оно неотличимо от обращения к реальному домену. Устройство протокола — в xray/reality; со стороны mihomo это несколько полей в описании узла (public-key, short-id).

ShadowTLS, restls, jls. Три разных подхода к «спрятать протокол за TLS». ShadowTLS проксирует настоящее рукопожатие к чужому серверу и подменяет только полезную нагрузку. restls (в релизах 2026 добавлен для AnyTLS, VMess, VLESS и Trojan) и jls (для Shadowsocks) — обфускации, устойчивые к активному зондированию: наблюдатель, попытавшийся подключиться к вашему серверу «на пробу», получает поведение обычного сайта.

Транспорты. WebSocket, gRPC, HTTP/2, XHTTP и mKCP — способ упаковать протокол в привычный веб-трафик, чтобы он проходил через CDN и обратные прокси. Подробно про самый новый из них — в заметке xray/xhttp.

Мультиплексирование (smux, h2mux, yamux) пропускает несколько логических соединений через одно физическое. Это уменьшает число TCP-рукопожатий и ускоряет открытие страниц, но у приёма есть цена: сотни запросов в одном длинном соединении — сами по себе статистически заметный паттерн, и на части сетей мультиплекс ухудшает выживаемость канала, а не улучшает её.

Перехват трафика: TUN и прозрачные режимы

TUN-режим создаёт виртуальный сетевой интерфейс, на который система направляет весь трафик, — так mihomo работает как настоящий VPN, включая приложения, которые не умеют ходить через прокси. Раньше это была премиальная функция закрытого Clash Premium; в mihomo она открыта и штатна.

Ядро предлагает три сетевых стека, и выбор между ними — практическое решение, а не украшение:

  • system — использовать стек операционной системы. Обычно быстрее и экономнее по CPU, но сильнее зависит от особенностей платформы.
  • gvisor — пользовательский стек (userspace TCP/IP из проекта gVisor). Работает предсказуемо везде, полезен там, где системный стек конфликтует с другими VPN или с правилами файрвола; платит за это нагрузкой на процессор.
  • mixed — TCP через системный стек, UDP через gVisor: компромисс, часто выручающий, когда UDP через system ведёт себя странно.

Дополнительно TUN умеет сам прописывать маршруты и правила (auto-route, auto-detect-interface) и настраивать разрешение имён так, чтобы DNS-запросы не утекали мимо туннеля.

На Linux остаются и «классические» варианты: redir-port и tproxy-port с перехватом через iptables/nftables — типовой способ поставить mihomo шлюзом для всей сети (тот же подход в мире Hysteria описан в Hysteria/tproxy).

Сниффер: как ядро узнаёт домен

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

Сниффер вскрывает начало соединения и достаёт имя хоста оттуда: из поля SNI в TLS-рукопожатии, из заголовка Host в открытом HTTP, из QUIC-рукопожатия. После этого соединение переоценивается правилами уже с известным доменом.

Проще говоря: сниффер — это способ применить доменные правила к трафику, который пришёл «безымянным». Он же чинит частый сценарий с fake-ip, когда приложение обошло подставной DNS-ответ. Обратная сторона — ядро разбирает начало каждого соединения, поэтому сниффер обычно ограничивают списком портов (443, 80) вместо «всего подряд».

Правила: что добавилось сверх оригинала

Базовые типы правил (DOMAIN, DOMAIN-SUFFIX, IP-CIDR, GEOIP, PROCESS-NAME, MATCH) описаны в Clash/01-clash-core. mihomo добавил к ним ощутимо больше выразительности:

  • GEOSITE — правила по категориям доменов (реклама, стриминг, категория «китайские сайты» и т. п.) из готовых баз, а не по одному имени.
  • IP-ASN — по номеру автономной системы: удобно, когда у сервиса десятки подсетей и они меняются.
  • DOMAIN-REGEX — совпадение по регулярному выражению.
  • Логические правила AND / OR / NOT — условия склеиваются: например, «домен из категории стриминга и запрос пришёл с адреса телевизора».
  • NETWORK, IN-TYPE, IN-USER, IN-NAME — маршрутизация по типу трафика (TCP/UDP) и по тому, через какой входящий слушатель он пришёл. Это то, что делает mihomo пригодным для роли шлюза: трафик от разных устройств разводится по разным маршрутам.
  • sub-rules — именованные наборы правил, к которым можно переходить из основного списка; конфиг перестаёт быть простынёй на тысячу строк.
  • REMATCH-NAME и тип outbound rematch (добавлены в v1.19.28, июль 2026) — повторное применение правил к соединению после того, как о нём стало известно больше.

Наборы правил (rule-providers) подгружаются из файла или по URL и обновляются по расписанию. Поддерживаются три формата: yaml, text и mrs — компактный бинарный формат самого mihomo, который экономит память и время загрузки на больших списках (доступен для наборов с поведением domain и ipcidr; конвертация — командой mihomo convert-ruleset). Готовые наборы и геоданные команда публикует в репозитории meta-rules-dat.

DNS-подсистема

DNS в mihomo — самостоятельная подсистема, а не одна строка с адресом сервера. Поверх режимов fake-ip и redir-host (разобраны в Clash/01-clash-core) добавлены:

  • Шифрованные апстримы — DNS-over-HTTPS, DNS-over-TLS и DNS-over-QUIC, в том числе с указанием, через какой прокси идти к самому DNS-серверу.
  • nameserver-policy — какой сервер спрашивать для конкретных доменов или категорий: локальные имена уходят провайдерскому резолверу, всё остальное — шифрованному.
  • proxy-server-nameserver — отдельный резолвер для доменов ваших прокси-серверов, чтобы не получилось замкнутого круга «чтобы подключиться к серверу, нужно разрешить его имя через этот же сервер».
  • fake-ip-filter — исключения из подстановки адресов для приложений, которым нужен настоящий IP.
  • hosts — локальные переопределения имён.

Смысл этой сложности практический: DNS — самый частый канал утечки. Если запросы уходят провайдеру в открытом виде, наблюдатель видит список посещаемых доменов, даже когда сам трафик надёжно зашифрован, а на части сетей ещё и получает возможность подменять ответы (пример того, к чему это приводит, — в DPI/google-dns-8888-block-july-2026).

Группы и подписки

Помимо классических select, url-test, fallback, load-balance и relay (разобраны в Clash/01-clash-core), mihomo добавил к группам механику, которая экономит ручную работу: фильтры filter и exclude-filter по имени узла (группа сама подхватывает из подписки только нужные страны), default-selected (какой узел активен при старте), empty-fallback (что делать, если группа опустела), настраиваемые таймауты проверок.

proxy-providers — подписки как отдельная сущность: URL, интервал обновления, health-check, фильтры и переопределения полей. Группы ссылаются на провайдер через use, поэтому смена продавца или добавление второй подписки не требуют переписывания правил.

[!note] Группа smart — про неё спрашивают отдельно В сообществе обсуждают «умную» группу, которая выбирает узел не по одной задержке, а по предсказанию модели (LightGBM) с учётом типа трафика и истории успешных соединений. На июль 2026 такая группа известна прежде всего по сторонним сборкам ядра (например, сборкам в рамках проекта OpenClash) и веткам Alpha, а не как базовая функция стабильного mihomo. Прежде чем закладываться на неё, проверьте, есть ли тип smart в документации именно вашей сборки.

Clash API и дашборды

Управляющий HTTP-API (см. раздел про external-controller в Clash/01-clash-core) в mihomo расширен: добавлены ручки статистики памяти, отладочные эндпоинты, управление провайдерами правил и узлов. Официальный дашборд — metacubexd; из популярных сторонних — zashboard и наследники yacd. Всё это одинаково применимо и к ядру внутри графического клиента: большинство оболочек просто открывают тот же API у своего встроенного mihomo.

📚 См. также

  • Clash/02-mihomo — история проекта, состояние и совместимость.
  • Clash/01-clash-core — базовое устройство конфига, правила, группы, fake-ip, Clash API.
  • Clash/07-clients — где всё это включается кнопками.
  • Clash/08-vs-sing-box — как тот же набор функций устроен у соседей.
  • protocols/00-overview — карта: какой протокол какую задачу решает и какое ядро его поддерживает.
  • xray/vless и xray/reality — устройство самых востребованных сегодня протокола и маскировки.
  • Hysteria/00-overview — QUIC-альтернатива TCP-протоколам, поддерживаемая mihomo.
  • 🔗 wiki.metacubex.one — документация по всем полям конфига.
  • 🔗 Релизы mihomo — первоисточник по новым протоколам и функциям.

[!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: исходник этой заметки · весь репозиторий.