Начните бесплатный 3-дневный пробный период
Зарегистрируйтесь и попробуйте все премиум-функции бесплатно.
*Только для новых пользователей. Один пробный период на пользователя.
API управления Mihomo: защита доступа и панели
Marcus Reid
11 октября 2026 г.· 9 мин чтения
API управления Mihomo — административный интерфейс ядра, поэтому его слушатель и учётные данные защищают отдельно от портов прокси-трафика. Ограничьте HTTP-контроллер, задайте сильный Secret, выберите доверенную панель и проверьте отказ без разрешения вместе с успешным авторизованным доступом. Открывшаяся страница не доказывает безопасность управления.［1］
Ключевые выводы
- Аутентификация прокси и HTTP-контроллера защищает разные интерфейсы.
- Loopback уменьшает доступность, но не делает браузерный код и локальные процессы доверенными.
- Unix socket и Windows Named Pipe не проверяют HTTP API Secret.
- Удалённое управление требует контролируемого входа, защищённого транспорта и проверенного удаления.
Какие возможности предоставляет API управления Mihomo?
Процедура описывает поля HTTP-контроллера и аутентификацию, сверенные с Mihomo v1.19.32 и общим справочником. Авторское сквозное развёртывание и тест совместимости всех панелей и оболочек не заявляются. До изменений запишите ядро, оболочку, ОС и источник панели.［1］［2］
Распределение эксплуатационной ответственности помогает определить владельца паролей, обновлений и вывода из эксплуатации. Административный доступ раскрывает сведения о соединениях или меняет маршруты, а открытый прокси создаёт отдельный риск злоупотреблений. Проверяйте оба интерфейса, не считая один пароль общей защитой.
Работайте только со своим разрешённым экземпляром. Сохраните закрытую копию активной конфигурации и канал восстановления вне контроллера. На общей машине согласуйте обслуживание и выясните, какие клиенты используют эти учётные данные, до ротации. Не останавливайте повседневный прокси- или VPN-клиент либо чужой прокси, чтобы освободить порт.
Шаг 1: Найдите слушатели и владельцев секретов
Определите запущенный процесс ядра, загруженный профиль, все API-слушатели, порты прокси, файлы панели и службы перенаправления. В Linux локально используйте ss -lntup, на другой ОС — штатный инспектор. Свяжите адрес и порт с владельцем вместо завершения неожиданного процесса.
mixed-port, SOCKS и HTTP proxy передают трафик приложений. external-controller обслуживает управление, а secret защищает соответствующие HTTP-маршруты. Настройка прокси authentication выполняет другую задачу. Поэтому изменение allow-lan не является полной проверкой доступности контроллера.［1］
Учтите IPv4, IPv6, контейнеры, опубликованные порты и reverse proxy. Loopback внутри контейнера не исключает доступ через отдельно настроенного посредника; loopback рабочей станции, наоборот, не указывает на сервер. Проверьте фактический путь каждого разрешённого администратора.
Считайте URL подписки секретным входом согласно правилам обращения с подписками. Не вставляйте профиль и Secret в публичный issue, онлайн-редактор YAML, непроверенную удалённую панель или скриншот. Для диагностики достаточно описать слушатель и результат отказа без самой учётной строки.
Шаг 2: Ограничьте HTTP-слушатель и задайте Secret
Для локального управления оставьте HTTP-контроллер на loopback и создайте новый случайный Secret. Пример показывает только относящиеся к изменению поля, а не весь профиль. Замените заполнитель до загрузки, сохранив остальные маршруты и прокси-пароли.［1］［3］
external-controller: 127.0.0.1:9090
secret: 'REPLACE_WITH_A_UNIQUE_RANDOM_SECRET'
Создайте значение локально доверенным менеджером паролей или источником случайности ОС. Оно должно быть уникальным и высокоэнтропийным; опубликованный заполнитель не является секретом. Храните Secret в закрытой конфигурации, ограничьте доступ к файлу и не раскрывайте его через аргументы процессов, URL, историю shell или общий журнал.
Удалите из целевой конфигурации ненужные альтернативные слушатели: одно поле не обязательно отменяет все остальные. Проверьте переопределения оболочки и фактический адрес после применения. До перезагрузки через штатного владельца проверьте конфигурацию валидатором выбранной версии.
Почему сокеты и каналы проверяют отдельно?
Официальный справочник указывает, что external-controller-unix и external-controller-pipe не валидируют Secret. Доступ зависит от прав пути Unix socket либо access controls Named Pipe. HTTP-проверка отказа ниже не подтверждает безопасность этих интерфейсов.［1］
Оставляйте их отключёнными без реальной необходимости. Если сокет нужен, используйте закрытый родительский каталог и проверьте владельца и фактические права; pipe ограничьте разрешёнными аккаунтами. Повторите проверку после перезапуска: права создания и идентичность службы могут отличаться от уже существующего файла.
Не включайте необязательный DoH endpoint контроллера в рамках этой задачи: справочник также описывает его как не проверяющий API Secret. Экспозиция DNS требует отдельного плана. Отсутствие ненужной службы сокращает число самостоятельных границ, которые надо проверять.［1］
Шаг 3: Что включает защита панели Mihomo и удалённого входа?
Панель — код браузера, которому вы передаёте административные учётные данные. Получайте файлы из прослеживаемого выпуска проекта, фиксируйте версию и избегайте непроверенного стороннего хостинга и автообновлений во время изменения. Знакомый внешний вид не подтверждает происхождение, а локальная раздача не отменяет доверие к файлам.
Если используется external-ui, укажите нужный локальный каталог и проверьте, что действительно раздаётся. Справочник разделяет UI-файлы, слушатель контроллера и Secret. Форма входа не заменяет API-аутентификацию: прямой запрос к защищённому маршруту также должен получить отказ.［1］
Разрешайте только реально необходимые dashboard origins. Не добавляйте wildcard или private-network access лишь для устранения ошибки браузера. CORS регулирует браузерные взаимодействия, но не аутентифицирует CLI-клиент и не заменяет Secret. Дополнительные origins оболочки должны иметь обоснование и пройти проверку эффективной конфигурации.
Для редкого удалённого управления подходит ограниченный SSH local forward. Используйте проверенный host key и уже разрешённый аккаунт сервера, оставив HTTP ядра на серверном loopback. Запускайте команду на рабочей станции, заменив имя и аккаунт; локальный порт специально отличается.
ssh -o StrictHostKeyChecking=yes -o ExitOnForwardFailure=yes \
-N -L 127.0.0.1:19090:127.0.0.1:9090 admin@controller-host.example
SSH шифрует удалённый участок, но HTTP на локальном loopback по-прежнему требует API Secret. Не заменяйте bind на wildcard. После работы закройте SSH и убедитесь, что 19090 больше не слушает. Если host key нельзя проверить, остановитесь, не принимая его вслепую.
HTTPS-вход — другой вариант: нужны действительный сертификат, проверка клиентом, аутентификация и ограниченная доступность. Учтите прямой HTTP-слушатель, который может обойти этот вход. Не используйте отключение проверки сертификата или публичный raw HTTP ради обхода ошибки TLS. Не создавайте WAN forwarding только для доступа к панели.
Шаг 4: Как проверяется секрет API Mihomo?
Выполняйте проверки на собственном защищённом /configs. Первый запрос не содержит учётных данных, второй содержит намеренно неверное значение; ни один не должен отдавать защищённую конфигурацию. Для SSH-forward замените 9090 на 19090.［2］
curl --noproxy '*' --max-time 5 --silent --show-error \
--output /dev/null --write-out '%{http_code}\n' \
http://127.0.0.1:9090/configs
curl --noproxy '*' --max-time 5 --silent --show-error \
--header 'Authorization: Bearer intentionally-wrong-secret' \
--output /dev/null --write-out '%{http_code}\n' \
http://127.0.0.1:9090/configs
Для v1.19.32 ожидается HTTP 401. Тайм-аут или отказ соединения не подтверждают проверку Secret, хотя доступа к данным нет. Проверьте действительные учётные данные через доверенную локальную панель или закрытый конфигурационный файл curl: защищённый маршрут должен работать. Не вставляйте настоящий Secret в опубликованную команду или query string.［2］
| Метод | Ожидаемый признак | Действие при ошибке |
|---|---|---|
| Осмотр активных сокетов | Только нужные адреса и порты API | Удалить лишний слушатель или forwarding |
| Анонимный защищённый запрос | HTTP 401 без данных | Закрыть внешний вход и исправить аутентификацию |
| Запрос с неверным Secret | HTTP 401 | Проверить активный профиль и посредника |
| Запрос с действительным Secret | Защищённый маршрут доступен | Проверить загрузку учётных данных и владельца маршрута |
| Доступ с исключённого разрешённого тестового хоста | Нет непредусмотренного пути | Закрыть forwarding или firewall-доступ |
| Закрытие удалённого входа и новая попытка | Вход недоступен | Найти оставшегося посредника |
Это условия приёмки читателя, не авторские результаты. Проверяйте ядро и посредника отдельно: отказ reverse proxy может скрывать незащищённый backend. Убедитесь, что панель выполняет лишь нужное управление и не сохраняет учётные данные в общем профиле браузера.
Шаг 5: Смените учётные данные и удалите удалённый доступ
Создайте новый Secret, обновите закрытую активную конфигурацию через её владельца и примените штатным способом управления службой. Обновите доверенных клиентов, повторите положительные и отрицательные проверки. Работы нового значения недостаточно: старое должно отвергаться на новом защищённом запросе.
Завершите прежние сеансы панели и административные соединения согласно жизненному циклу выбранного клиента: уже открытый поток отличается от нового запроса с аутентификацией. Удалите старые токены из браузера, приватных клиентских файлов и forwarding-настроек. При утечке не возвращайте скомпрометированный Secret из backup ради исправления клиента.
После ошибочной настройки верните сохранённые параметры слушателя с нескомпрометированным Secret. Закройте тестовый SSH forward, удалите только созданные для него ingress-правила и снова осмотрите слушатели. Проверьте обычную работу прокси и независимое управление; не выключайте весь firewall ради панели.
Для Mihomo под управлением маршрутизатора порядок установки и восстановления OpenClash учитывает, что плагин заново создаёт настройки ядра. Если обслуживание панели, учётных данных и сервера избыточно для задачи, сравните ответственность собственного и управляемого сервиса до сохранения этой управляющей плоскости.
Итоги
- Инвентаризируйте все API-слушатели и посредников отдельно от прокси-портов.
- Сохраняйте HTTP-аутентификацию даже на loopback.
- Проверяйте отказ, разрешённый доступ, ротацию и удаление входа.
- Разделяйте права сокета, доверие браузеру и защиту TLS.
Часто задаваемые вопросы (FAQ)
Защищает ли allow-lan false API контроллера?
Настройка относится к доступу к прокси-трафику, а у API собственный слушатель и аутентификация. Проверьте активные адреса контроллера и защищённый маршрут отдельно.
Можно ли не задавать Secret на loopback?
Сохраните аутентификацию loopback HTTP-контроллера. Локальные процессы и браузерный код не становятся доверенными автоматически, а новый forwarding может расширить фактическую доступность.
Доказывает ли форма входа работу аутентификации?
UI может запрашивать пароль без надёжной проверки backend. Подтвердите, что ядро отвергает прямые анонимные запросы и запросы с неверными учётными данными к защищённому маршруту.
Проверяют ли Unix sockets тот же Secret?
Документированные Unix socket и Named Pipe не валидируют API Secret. Ограничьте права ОС либо отключите их; HTTP-тесты не подтверждают их разрешения доступа.
Заменяет ли CORS контроль доступа?
CORS ограничивает отдельные взаимодействия браузера, а не все HTTP-клиенты. Сохраняйте аутентификацию, узкие слушатели и ограниченный удалённый вход даже при точном списке origins.
Достаточно ли закрытого SSH-forward без других мер?
Проверенный SSH защищает удалённый транспорт, но не отменяет HTTP API-аутентификацию. Сохраняйте узкий локальный bind и удаляйте перенаправление после администрирования.
Что подтверждает успешную ротацию Secret?
Новые учётные данные должны работать, а старые — отвергаться на свежем защищённом запросе. Также завершите прежние административные сессии и удалите сохранённые старые значения штатным способом клиента.
Отказ от ответственности: Описаны документированные меры и проверки читателя, а не заявленные авторские результаты. Меняйте только разрешённые системы и сохраняйте восстановление, не зависящее от API.
Источники:
- Mihomo — General configuration — https://wiki.metacubex.one/en/config/general/
- Mihomo — v1.19.32 controller routing and authentication — https://github.com/MetaCubeX/mihomo/blob/v1.19.32/hub/route/server.go
- Mihomo — v1.19.32 configuration source — https://github.com/MetaCubeX/mihomo/blob/v1.19.32/config/config.go
Sources checked 11 октября 2026 г.
Статьи по теме:
