mihomo DNS Explained: fake-ip vs redir-host Settings Guide

More "mysterious" proxy problems trace back to DNS than to anything else. A node can be fast and a rule list flawless, yet pages hang — because the name lookup happened in the wrong place, got a polluted answer, or leaked to a resolver you never intended to use. That is why mihomo ships its own DNS resolver and, in most setups, takes over name resolution entirely.

The heart of the mihomo DNS config is enhanced-mode, which has two settings: fake-ip and redir-host. This guide explains what each one actually does, when fake-ip needs exceptions, what the various nameserver fields mean, and ends with a sensible dns block you can copy.

Why a proxy client takes over DNS

Three reasons. First, on some networks plain DNS answers are tampered with, and a poisoned IP makes the destination unreachable no matter how good your proxy is. Second, sending queries to the ISP's resolver while your traffic exits elsewhere is a classic DNS leak — your lookup history stays visible locally. Third, routing itself needs trustworthy resolution: rules like GEOIP only work well when the client controls how names become addresses. Handling DNS inside mihomo addresses all three at once.

fake-ip vs redir-host: the two enhanced modes

With enhanced-mode: fake-ip, mihomo answers every query instantly with a fake address from a reserved range (commonly 198.18.0.0/16). The application connects to that placeholder, mihomo intercepts the connection, maps it back to the original domain, and resolves the real address only where needed — often on the remote node. Lookups are effectively instant and local poisoning becomes irrelevant, because the answer your apps see never came from the hostile network.

With redir-host, mihomo resolves the name upstream and hands the application the real IP. It is the more literal-minded mode: apps see genuine addresses, which a few of them require, but you inherit the classic weaknesses — resolution latency on every new name and more exposure to bad answers. Modern configs default to fake-ip; treat redir-host as the compatibility fallback.

When fake-ip breaks something: fake-ip-filter

A small class of software genuinely needs real IPs: LAN discovery, some game launchers, captive-portal login pages, time sync services. Symptoms are distinctive — exactly one app misbehaves while browsers are fine. The fix is to exclude those names from fake-ip:

dns:
  fake-ip-filter:
    - "*.lan"
    - "+.local"
    - "+.msftconnecttest.com"

Names matching the filter get real resolution even in fake-ip mode. * matches one label, + matches any depth of subdomains.

nameserver, fallback and default-nameserver

• nameserver — your main upstream resolvers. Encrypted endpoints (DoH/DoT) are preferred so queries cannot be casually read or rewritten.
• fallback — a second resolver set consulted for results that look suspicious, typically foreign domains on networks known to pollute. Optional in simple setups.
• default-nameserver — plain-IP resolvers used solely to bootstrap: before mihomo can use https://dns.google/dns-query it must resolve dns.google somewhere, and this field is that somewhere. Always use bare IPs here.

A safe example dns block

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "+.local"
  default-nameserver:
    - 223.5.5.5
    - 1.1.1.1
  nameserver:
    - https://dns.google/dns-query
    - https://1.1.1.1/dns-query

This is a conservative starting point, not a golden config — swap the upstreams for resolvers that perform well from your region. Note that TUN mode leans on this block especially hard: with TUN enabled, a broken DNS section usually means no connectivity at all.

Symptoms and what they mean

• One app fails while everything else works — it probably wants a real IP. Add its domains to fake-ip-filter.
• First connection to every site is slow — your upstream resolvers are slow from your location. Try different nameserver entries.
• Domestic sites route through the proxy — GEOIP is judging polluted or foreign answers; resolution and rule matching interact, so fix DNS before rewriting rules.
• Nothing loads at all with the proxy on — that is rarely just DNS; run through the layered troubleshooting guide to isolate the failing stage.