Начните бесплатный 3-дневный пробный период
Зарегистрируйтесь и попробуйте все премиум-функции бесплатно.
*Только для новых пользователей. Один пробный период на пользователя.
Mihomo Fake-IP и Redir-Host: диагностика DNS
Ryan Foster
11 октября 2026 г.· 9 мин чтения
Mihomo Fake-IP и Redir-Host различаются адресом, который получает приложение, а не делят интернет на безопасный и небезопасный. Fake-IP выдаёт синтетический адрес, связанный внутри Mihomo с доменом; Redir-Host возвращает результат разрешения имени. Для диагностики проследите один домен через DNS, приложение, захват трафика и исходящее соединение.［1］［2］
Ключевые выводы
- Синтетический ответ обозначает внутреннее соответствие, а не публичный адрес сайта.
- DNS браузера, приложения и системы могут идти разными путями.
- Меняйте один режим или исключение, затем создавайте новое соединение.
- Сохраняйте доступ к локальным службам и каналу управления.
Когда сравнивать Mihomo Fake-IP и Redir-Host?
Процедура предназначена для экземпляра Mihomo, которым вы вправе управлять. Поля DNS сверены со стабильной версией v1.19.32 и официальным справочником. Это документированный порядок диагностики, а не авторский сквозной тест и не гарантия одинакового поведения всех оболочек. Запишите версии ядра и оболочки: последняя может заново сформировать YAML и затереть ручную правку.［1］［3］
Планирование самостоятельного обслуживания помогает назначить владельца настроек и восстановления. Если вопрос заключается в том, какие приложения попадают в прокси, сначала сравните охват TUN и системного прокси. Режим DNS не перехватит соединение, которое вообще не поступает в Mihomo.
Подготовьте закрытую резервную копию, прежние настройки DNS и независимый канал управления. На общей машине согласуйте окно работ и не меняйте чужой прокси. Если уже используется повседневный прокси- или VPN-клиент, сохраните его состояние и выберите отдельное разрешённое тестовое устройство: несколько слоёв захвата делают сравнение неоднозначным.
Шаг 1: Зафиксируйте домен и путь разрешения
Выберите один публичный домен, к которому разрешены запросы, и одну принадлежащую вам локальную службу. Запишите имя, тип записи, клиент, время, профиль Mihomo, DNS-слушатель и конкретную ошибку. Тайм-аут, ошибка сертификата и отказ приложения использовать адрес — разные наблюдения; не называйте всё это утечкой DNS.
Следующие команды обращаются непосредственно к локальному DNS на порту 1053. Замените демонстрационный домен выбранным именем, а порт — фактическим портом службы. Выполняйте запрос на машине, где находится слушатель: loopback другого устройства указывает на другое устройство.
dig @127.0.0.1 -p 1053 example.com A
dig @127.0.0.1 -p 1053 example.com AAAA
Сохраните тип ответа и TTL в закрытой записи. Не отправляйте подписку, полную конфигурацию или историю запросов публичному проверяющему сервису. Сравните ответ с системным DNS и проблемным приложением, не меняя домен и сеть. Браузер со своим зашифрованным DNS может обходить системный резолвер; результат dig не доказывает путь браузера.
Не вводите 127.0.0.1:1053 в обычное поле DNS операционной системы: многие такие поля принимают адрес без произвольного порта. Используйте уже поддерживаемую интеграцию оболочки либо оставьте запрос прямой диагностикой. Открывать слушатель на всех интерфейсах ради проверки означает добавлять ненужную поверхность доступа.［1］
Шаг 2: Проверьте активный режим и соответствие адресов
Читайте именно загруженную ядром конфигурацию с учётом переопределений оболочки. Ниже показана часть полей уже работающего DNS, а не полный профиль интернет-прокси. Сохраните разрешённые вышестоящие резолверы, правила, политику IPv6 и прежние исключения.
dns:
enable: true
listen: 127.0.0.1:1053
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
fake-ip-filter-mode: blacklist
fake-ip-filter:
- 'printer.home.arpa'
Замените printer.home.arpa точным локальным именем под вашим управлением либо уберите демонстрационное исключение. В режиме blacklist совпадение исключает синтетический ответ, но не создаёт DNS-запись и не выбирает доступный локальный резолвер. У других режимов фильтра иная семантика: список blacklist нельзя бездумно переносить в whitelist или rule.［1］
В Fake-IP разделяйте адрес, полученный приложением, и цель, которую затем разрешает или выбирает исходящий путь. Соответствие должно оставаться действительным в том экземпляре Mihomo, куда поступает соединение. Переданный другой машине синтетический адрес, старый кеш после смены профиля или обход захвата могут сломать доступ при исправном публичном домене. Redir-Host меняет адресное поведение, но не отменяет DNS-политику и маршрутизацию.［2］
Адрес из 198.18.0.0/15 не доказывает ни публичную доступность, ни злонамеренный перехват. Сохраняйте серверные меры против SSRF: не разрешайте специальные и частные адреса только потому, что настольный прокси использует синтетический DNS. Серверу, загружающему URL, нужен собственный доверенный путь разрешения и проверки назначения; это объяснение не создаёт исключение безопасности.
Шаг 3: Проверьте, от чего зависит совместимость DNS Mihomo
Сравнивайте один ресурс в разных приложениях. Создавайте новые соединения, а не сопоставляйте старый сокет браузера со свежим запросом командной строки. Одновременная смена зашифрованного DNS браузера, upstream, захвата и режима DNS не позволяет выделить причину.
| Наблюдение | Что сравнить | Чего оно не доказывает |
|---|---|---|
| Прямой запрос возвращает синтетическую A-запись | Активный режим и совпадение фильтра | Что браузер использует этот слушатель |
| Браузер работает, отдельное приложение нет | DNS приложения, поддержку прокси, кеш | Что всем приложениям нужен Redir-Host |
| Не разрешается имя принтера | Локальный DNS и точное исключение | Что частные имена следует отправить публичному DNS |
| A работает, AAAA отличается | Настройку DNS IPv6 и реальный маршрут IPv6 | Что трафик IPv6 защищён |
| Оба режима дают тайм-аут | Upstream и начальное разрешение его адреса | Что смена режима исправит upstream |
Для Ubuntu используйте диагностику владельца системного DNS и split DNS. В вопросах приватности отличайте формат ответа от выхода DNS-запроса за предусмотренный путь. Ни синтетический ответ, ни открывшаяся страница сами по себе не показывают, куда ушёл каждый запрос.
Для исключения в LAN убедитесь, что авторитетный локальный резолвер знает имя, а полученный адрес доступен по нужному маршруту. Исключите управление и обнаружение устройств из эксперимента, если они не являются согласованной целью. Имена mDNS могут обслуживаться иначе, чем обычный unicast DNS; фильтр не заменяет механизм обнаружения.
Шаг 4: Измените одну переменную и повторите запрос
Скопируйте эффективную конфигурацию в закрытое место и выясните, как оболочка сохраняет изменения. Если данные указывают на одно локальное имя, сначала проверьте узкое исключение вместе с правильным локальным резолвером. Если приложение в целом не принимает синтетические адреса, сравните enhanced-mode: redir-host, сохранив upstream, правила захвата и сеть.［1］
До загрузки проверьте правку документированным валидатором выбранного ядра или оболочки. Принятый синтаксис не подтверждает маршруты, учётные данные или совместимость приложения. Если непонятно, как вернуть прежний профиль, прекратите опыт, особенно когда от него зависит единственный доступ к машине.
Диагностика Fake-IP требует обновлять только соединения тестового приложения и относящийся к опыту кеш через документированные средства. Постоянные соответствия Fake-IP и обычный DNS-кеш — разные состояния. Не удаляйте общую базу кеша, не сбрасывайте все приложения и не перезапускайте чужие сетевые службы ради чистого сравнения.
Если изменение помогло, сохраните имя, путь запроса, класс ответа, результат приложения и неизменённые контрольные условия. Если не помогло, восстановите прежнюю конфигурацию до проверки следующей гипотезы. Захват и маршруты разбирайте отдельно по сравнению механизмов прозрачного прокси Linux.
Шаг 5: Какие проверки должен выполнить читатель?
Таблица содержит ожидаемые признаки для ваших проверок, а не уже полученные автором результаты. Записывайте фактический исход и непроверенные ветви. Ответ DNS, запись о потоке в прокси и ответ назначения дополняют друг друга; ни один не заменяет остальные.
| Метод | Ожидаемый признак | Действие при ошибке |
|---|---|---|
| Запрос A и AAAA к выбранному слушателю | Ответы соответствуют активной политике | Проверить загруженный профиль и ошибки DNS |
| Исходная задача приложения с новым соединением | Ресурс доступен по записанному пути | Вернуть правку и сравнить DNS приложения |
| Запрос к своей локальной службе | Её идентичность и управление доступны | Восстановить локальный DNS и исключение |
| Просмотр только тестового потока в журнале | Домен и outbound соответствуют правилу | Проверить захват и владельца соответствия |
| Повторное открытие профиля через его владельца | Настройка сохранена | Исправить сохранение до принятия изменения |
Если опыт меняет интернет-выход, проверьте IP именно этого запроса, отдельно проверяя DNS, IPv6 и отказ. Страница IP описывает собственный запрос, а не все приложения. Из этой диагностики нельзя выводить анонимность, ускорение или универсальный охват.
Шаг 6: Восстановите настройки и тестовое состояние
Загрузите сохранённый профиль через того же владельца, который применил правку. Верните намеренно изменённый тестовый резолвер или DNS-настройку приложения и закройте тестовые соединения. Удалите добавленное исключение, если не решили оставить его осознанно.
Очищайте только относящиеся к опыту записи там, где приложение поддерживает такую область. При невозможности выборочной очистки дождитесь документированного истечения или используйте изолированный профиль вместо удаления общих данных. После восстановления подтвердите прежний класс DNS-ответа, локальную службу и канал управления.
Удалите временные подробные журналы и защитите оставленную диагностическую запись. Резервная копия с прокси-паролями также содержит секреты. Если восстановление не подтверждается, прекратите новые изменения и используйте независимый канал, не отключая firewall или другой прокси в качестве компенсации.
Итоги
- Установите владельца DNS и путь захвата до сравнения режимов адресации.
- Сохраняйте upstream при проверке режима или точного исключения.
- Проверяйте исходное приложение и локальные службы новыми соединениями.
- Восстанавливайте настройки и тестовый кеш перед следующим опытом.
Часто задаваемые вопросы (FAQ)
Означает ли Fake-IP перехват DNS?
Синтетический ответ может быть намеренным, если приложение использует настроенный вами DNS Mihomo. Сначала подтвердите владельца резолвера и активную политику, затем делайте вывод о возможном вмешательстве.
Всегда ли Redir-Host совместим лучше?
Redir-Host иногда помогает приложению, не принимающему синтетические цели, но совместимость зависит также от DNS, захвата и маршрутов. Сравнивайте проблемную задачу, а не выбирайте универсального победителя.
Исправляет ли fake-ip-filter все локальные имена?
Фильтр меняет выдачу синтетического адреса, но не создаёт авторитетную запись. Сохраните подходящий локальный резолвер и маршрут, затем проверьте идентичность конкретной службы.
Почему dig и браузер дают разные результаты?
Браузер может использовать собственный зашифрованный DNS или уже открытое соединение. Сопоставьте новый запрос браузера с его фактическими настройками, а не принимайте прямой запрос за доказательство его пути.
Нужно ли отключить IPv6 ради простоты?
Не отключайте IPv6 как универсальное исправление. Запишите A, AAAA и доступный маршрут: отсутствие AAAA не доказывает, как подключается каждое приложение и какой путь оно выбирает.
Можно ли пропустить диапазон Fake-IP через SSRF-фильтр?
Соответствие настольного прокси не превращает специальные адреса в безопасные серверные цели. Сохраняйте проверку назначения и доверенное разрешение на сервере вместо исключения всего диапазона.
Нужно ли очищать все кеши после смены режима?
Обновите тестовые соединения и соответствующий кеш штатными средствами. Когда выборочная очистка недоступна, дождитесь истечения или изолируйте опыт, не уничтожая общее состояние приложений.
Отказ от ответственности: Процедура основана на перечисленных официальных материалах. Полное авторское развёртывание или проверка совместимости не заявляются; меняйте только разрешённую среду с подготовленным восстановлением.
Источники:
- Mihomo — DNS configuration — https://wiki.metacubex.one/config/dns/
- Mihomo — DNS resolution process — https://wiki.metacubex.one/config/dns/diagram/
- Mihomo — v1.19.32 configuration source — https://github.com/MetaCubeX/mihomo/blob/v1.19.32/config/config.go
Sources checked 11 октября 2026 г.
Статьи по теме:
