DNS — тот раздел конфигурации Clash, который порождает больше всего загадочных проблем. Неточная маршрутизация, стриминг, который не разблокируется, переставшие работать внутренние сервисы — в восьми случаях из десяти след ведёт сюда.
Сначала о том, зачем прокси-клиенту вообще заниматься DNS
Обычно имена резолвит система, а приложение затем подключается к полученному IP.
Под прокси возникает противоречие: правила написаны про домены, а к моменту, когда трафик доходит до ядра, от них может остаться только IP.
Поэтому ядру нужно взять DNS на себя. Сделать это можно двумя способами.
redir-host: резолвить по-настоящему
Ядро получает запрос, действительно разрешает имя, возвращает приложению настоящий IP и внутри себя помечает «этот IP соответствует тому домену».
Плюс: возвращается настоящий IP, поэтому совместимость наилучшая — внутренние сервисы и устройства в локальной сети ведут себя нормально.
Минусы:
- Каждый запрос ждёт ответа от вышестоящего резолвера, это медленно
- Если разрешение зарубежного имени отравлено, вы получите неверный IP
- Ответом может оказаться адрес внутрирегиональной CDN, что искажает решения правил
fake-ip: выдать заглушку
Ядро получает запрос и не резолвит его вовсе. Оно выдаёт фиктивный адрес из зарезервированного диапазона вроде 198.18.0.0/16 и записывает «этот фиктивный IP = тот домен».
Приложение подключается к фиктивному адресу, ядро его узнаёт, находит обратно домен, сопоставляет правила по домену, а настоящее разрешение выполняет выходной узел.
Плюсы:
- Ответы DNS практически мгновенные (ждать нечего)
- Отравление исключается в корне
- Информация о домене сохраняется полностью, так что правила срабатывают максимально точно
- Разрешение на выходном узле делает проверку региона стриминговыми сервисами надёжнее
Минусы:
- Возвращается фиктивный адрес, так что всё, что зависит от настоящего IP, ломается
ping example.comпоказывает198.18.x.x, что выглядит странно (на практике безвредно)- Внутренние имена обязаны попасть в
fake-ip-filter, иначе они не разрешатся
Вывод: почти всегда используйте fake-ip
Рабочая конфигурация DNS
dns:
enable: true
listen: 0.0.0.0:1053
ipv6: false
prefer-h3: false
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
fake-ip-filter:
- "*.lan"
- "*.local"
- "*.localdomain"
- "+.internal"
- "+.home.arpa"
- "+.pool.ntp.org"
- "time.*.com"
- "ntp.*.com"
- "+.market.xiaomi.com"
- "localhost.ptlogin2.qq.com"
- "+.msftconnecttest.com"
- "+.msftncsi.com"
# используется для разрешения имён самих серверов DoH/DoT ниже
default-nameserver:
- 223.5.5.5
- 119.29.29.29
# основной DNS: разрешает внутрирегиональные имена
nameserver:
- https://doh.pub/dns-query
- https://dns.alidns.com/dns-query
# резервный DNS: разрешает зарубежные имена
fallback:
- https://1.1.1.1/dns-query
- tls://8.8.4.4:853
# когда брать ответ от fallback
fallback-filter:
geoip: true
geoip-code: CN
ipcidr:
- 240.0.0.0/4
- 0.0.0.0/32
# отправлять конкретные имена конкретным резолверам
nameserver-policy:
"geosite:cn": [223.5.5.5, 119.29.29.29]
"+.mycompany.com": "10.10.0.53"Чем занимается каждое из четырёх полей
Как решает fallback-filter
Он запрашивает nameserver и fallback одновременно, а затем:
- Адрес от
nameserverвнутри региона → берём его (значит, имя местное) - Адрес от
nameserverвне региона → берём ответ отfallback(зарубежное имя, где местный резолвер может быть отравлен)
Такая схема отправляет местные имена местным резолверам (быстро, и CDN оказывается рядом), а зарубежные — зарубежным (точно и без отравления).
Что такое утечка DNS на самом деле
«Утечка DNS» означает: вы считаете, что трафик идёт через прокси, а разрешение имён по-прежнему уходит к резолверу вашего провайдера. Следствие — провайдер видит, какие домены вы посещаете.
Встроенный DoH браузера — самый часто упускаемый источник утечки: Chrome и Firefox могут по умолчанию включать собственный шифрованный DNS, минуя и систему, и ядро.
- Chrome/Edge: Настройки → Конфиденциальность и безопасность → Безопасность → выключить «Использовать безопасный DNS»
- Firefox: Настройки → Приватность и защита → в самом низу «DNS через HTTPS» → выключить
Таблица типичных неисправностей
| Симптом | Причина | Что делать |
|---|---|---|
| Внутренние имена не резолвятся | Их поймал fake-ip | Добавить в fake-ip-filter |
ping example.com показывает 198.18.x.x | Ожидаемое поведение | Так работает fake-ip; безвредно |
| Не достучаться до устройства в LAN по имени (NAS) | .local / .lan прошли через fake-ip | Добавить "*.lan" и "*.local" |
| Приложение бесконечно крутится | У него свой резолвер, и его перехватили | Проверьте dns-hijack под TUN |
| Локальные сайты стали медленнее | Зарубежный резолвер отправил CDN куда-то далеко | Через nameserver-policy оставьте местные имена на местных резолверах |
| Стриминг определяет неверный регион | Разрешение прошло локально | Используйте fake-ip, чтобы резолвил выходной узел |
| Не синхронизируются часы | Имена NTP прошли через fake-ip | Добавить "+.pool.ntp.org" и "time.*.com" |
| Мессенджер не входит | Конкретному имени нужен настоящий IP | Добавить "localhost.ptlogin2.qq.com" |
Что должно попасть в fake-ip-filter
Принцип: любое имя, которому для работы нужен настоящий IP, обязано туда попасть.
Как проверить, что конфигурация подействовала
Работает ли fake-ip?
nslookup google.com 127.0.0.1Ответ вида 198.18.x.x означает, что fake-ip работает.
Идут ли внутренние имена к правильному резолверу?
nslookup gitlab.mycompany.com 127.0.0.1Должен вернуться настоящий внутренний IP, а не 198.18.x.x. Фиктивный адрес означает, что fake-ip-filter задан неверно.
Сколько занимают запросы?
Переключите уровень логирования в debug, и вы увидите время и использованный сервер для каждого запроса. Много запросов дольше 200 мс означает неудачный выбор вышестоящих резолверов.
Коротко
- По умолчанию используйте fake-ip; он быстрее, точнее и неуязвим для отравления
- fake-ip-filter надо поддерживать: внутренние имена, NTP и проверки связности обязательны
- У nameserver-policy наивысший приоритет — используйте его для точной маршрутизации DNS
- Выключите собственный DoH браузера, иначе всё вышеперечисленное напрасно
- default-nameserver принимает только обычные IP
Смотрите также: внутреннее устройство TUN и раздельное туннелирование на практике.
Смежные документы
Что делает режим TUN с точки зрения пакета: создание виртуального адаптера, переписывание таблицы маршрутизации, перехват порта 53 и выбор между стеками gvisor, system и mixed.
Чем игровой трафик отличается: почему UDP требует TUN, что на самом деле значит тип NAT, почему потери пакетов вреднее задержки, и чек-лист настроек ради низкой задержки.
Что означает каждый столбец и как им пользоваться: поиск программы, съедающей трафик, причины взрывного роста числа соединений, где узкое место скорости и непрерывный мониторинг через API.