Matching rules by domain name requires the client to actually know "what domain does this connection correspond to." Without special handling enabled, the system may only hand Clash the resolved IP — the domain information is already lost, so rules obviously can't match by domain. This is exactly why DNS configuration is critical to rule-matching accuracy.
enhanced-mode: the real difference between the two modes
| Mode | How it works | Trade-offs |
|---|---|---|
| fake-ip | Returns a virtual IP to the application first; when the connection is established, the real domain is looked up from the virtual IP for rule matching | Fast, and domain information is available earlier; a small number of scenarios that depend on the real IP being returned may need exceptions |
| redir-host | Returns the real resolution result directly, relying on traffic-layer domain sniffing or redirection to get the domain | Better compatibility, but depends on real DNS queries, so it's slower and less private than fake-ip |
The mainstream recommendation is fake-ip. Its compatibility issues mainly show up in a handful of LAN protocols that depend on "the DNS query result must be a real IP" (for example, certain device-discovery or screen-casting protocols). When you hit this, just add the relevant domain to the fake-ip-filter exception list — there's no need to give up fake-ip's overall advantages for a few edge cases.
A ready-to-use DNS configuration
dns: enable: true ipv6: false enhanced-mode: fake-ip fake-ip-range: 198.18.0.1/16 fake-ip-filter: - '*.lan' # LAN device domains use real resolution to avoid breaking discovery protocols - '*.local' default-nameserver: [223.5.5.5, 119.29.29.29] # Base DNS used to resolve the DoH/DoT domains themselves nameserver: ['https://doh.pub/dns-query', 'tls://dot.pub:853'] fallback: ['https://1.1.1.1/dns-query', 'https://dns.google/dns-query'] fallback-filter: geoip: true geoip-code: CN # Example only — filters by a specific country code (here, CN); swap in the code matching your own region/ISP
What problem do DoH / DoT actually solve
Traditional DNS queries are sent as plaintext UDP packets, which means your ISP or any network device in between can see exactly which domains you're querying — and can even tamper with the results (commonly known as "DNS pollution/hijacking"). DoH (DNS over HTTPS) and DoT (DNS over TLS) encrypt the query process, preventing it from being snooped on or tampered with by intermediate network devices.
- nameserver should preferably be configured with DoH/DoT addresses to reduce the chance of the query being tampered with.
- default-nameserver must use traditional DNS (direct IP), because the DoH/DoT server itself is also just a domain name — it needs to be resolved to an IP first, otherwise you'd end up in a loop of "resolving the DoH domain also needs DNS."
fallback-filter: precise anti-pollution
fallback-filter works like this: resolution is attempted first using the servers in nameserver. If the resolved IP is determined to fall outside a specified region (for example, with geoip-code: CN enabled, if the IP is judged not to belong to that region), the servers configured in fallback are used to resolve again, and the fallback result is used instead.
This mechanism is mainly used to avoid the situation where "a hijacked/polluted DNS server returns an incorrect local-looking IP, while the real site is actually hosted elsewhere." With this enabled, even if your primary DNS is compromised and returns a bad result, it can automatically be corrected using the result from an alternate DNS resolution.
Common troubleshooting approaches
- A rule that's clearly written correctly isn't taking effect? First check whether enhanced-mode is enabled, or whether the DNS configuration as a whole hasn't taken effect (for example, the system's DNS cache hasn't been cleared).
- Intermittent failures accessing a site, as if it's being hijacked? This is most likely DNS pollution — try testing the nameserver and fallback server groups separately to see whether their resolution results match.
- LAN devices (NAS, smart speakers) having discovery issues? First check whether fake-ip-filter already has the relevant domain added as an exception.
DNS configuration rarely needs frequent changes — once it's set up according to this logic, most "connection issues" problems are already avoided at the source.