Clash DNS Configuration Guide: nameserver, fallback, fake-ip & DNS Hijacking

Check the core before changing DNS settings

Whether Clash DNS settings take effect depends on two things: whether the current core supports the fields, and whether application DNS requests actually reach the core. Changing only dns.enable to true does not make every Windows app use these DNS settings. Enabling the system proxy also does not automatically intercept system UDP port 53 queries.

Clash for Windows is no longer maintained. It provides the client interface; the core it uses handles connections. The feature sets of the legacy Clash, Clash Premium, and Clash Meta (now called mihomo) are not identical. This guide explains common DNS fields first, then provides a separate mihomo TUN example. Do not replace an older client's entire configuration with one written for a newer core.

1. Check the core information on the client's General page. If it is not shown there, look for startup details in Logs.
2. In Profiles, confirm which profile is selected and save a copy before making changes. Subscription updates may overwrite direct edits.
3. Check whether Mixin or configuration overrides are enabled. When troubleshooting, inspect the final effective configuration, not just the original subscription file.
4. Change one set of options at a time, then reload and check the logs. If you see an unknown field, startup failure, or listener error, restore the last known-good configuration first.

DNS basics: listeners, upstreams, and bootstrap resolution

Here is a basic DNS snippet for troubleshooting, using redir-host to return real IP addresses. It is not a complete subscription; merge it into the top level of an existing configuration. Keep only one dns: mapping per file to avoid duplicate keys causing overrides or parse errors.

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: redir-host
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://doh.pub/dns-query

Don't confuse ports 1053, 53, and 7890

Standard DNS queries usually use port 53. This example uses 1053 to avoid conflicts with existing services, but Windows network adapter DNS settings generally do not let you specify a custom port. Test with a query tool that supports custom ports, or use TUN to pass DNS requests to the core. Proxy ports such as 7890 handle HTTP/SOCKS and other proxy connections; they are not DNS ports.

DoH encrypts DNS traffic, but does not guarantee connectivity

https://dns.alidns.com/dns-query is a DNS over HTTPS endpoint. The core must know the resolver's IP address before it can establish an HTTPS connection, so bootstrap resolution is required. DoH encrypts query contents in transit, but the server can still see the queries sent to it. Resolution can still fail if the route is unavailable, certificate validation fails, or the system clock is wrong.

Don't add a dozen upstreams just to try to make DNS faster. Start with one or two resolvers that are reliably reachable from your local network, confirm they respond, and only then add other logic. These addresses illustrate valid syntax; they do not guarantee availability or latency on every ISP network.

nameserver and fallback: select by response, not just by timeout

It's easy to think of fallback as “try the second DNS server only if the first one times out.” In Clash, however, fallback-filter also helps determine which set of results to use. When both upstream groups are configured, the core generally queries them in parallel. For ordinary queries, it favors the nameserver results, then uses the filter conditions to decide whether to accept the fallback results instead.

The snippet below shows the traditional GeoIP filtering syntax. Merge it into the dns section from the previous section rather than adding a second top-level dns mapping. The GeoIP check in this example depends on the database loaded by the core.

  fallback:
    - https://1.1.1.1/dns-query
    - https://dns.google/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 240.0.0.0/4
    domain:
      - '+.example.com'

How to interpret fallback-filter conditions

• domain: When a domain matches a specified condition, the fallback result is preferred directly. +.example.com is a reserved example domain used to illustrate the syntax. Replace it with a domain you actually need, or remove this entry.
• ipcidr: If an address returned by nameserver falls within one of the listed ranges, that result is treated as a candidate for replacement with the fallback result. 240.0.0.0/4 is a common example, not a complete list of anomalous address ranges.
• geoip: When enabled, this checks whether the primary result belongs to the expected region according to geoip-code. With CN set, a primary result outside CN triggers the fallback result logic.

For example, if nameserver returns an address that the database identifies as CN for a domain, and no other filter condition matches, that result is generally kept. If it returns an address outside CN, the fallback result is used instead. This describes the decision flow, not a test result. CDN addresses, database classifications, and query results can all change.

Also, putting a DoH endpoint in fallback does not guarantee that it will go through a proxy. DNS upstream routing depends on the core type, version, and related settings. If these resolvers are not directly reachable from your current network, first confirm that a route is available. Switching to “foreign DNS” is not a substitute for troubleshooting. If you don't have a specific filtering need, start with nameserver alone; it's usually easier to diagnose.

fake-ip vs. redir-host: virtual or real IP addresses

The key difference between these modes is the DNS response sent to the app. redir-host usually returns the real address resolved upstream and maintains a domain-to-address mapping. fake-ip assigns a virtual IP to the domain. When the core receives a connection to that address, it looks up the domain in the mapping before applying rules and routing the connection.

Basic fake-ip configuration

  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - '*.lan'
    - '*.local'

198.18.0.0/16 is part of a reserved benchmarking address range, not the real public IP address of a destination site. If a query returns 198.18.x.x, don't assume DNS has been poisoned; this may be expected in fake-ip mode. App connections must still pass through a core that recognizes the mapping, or the virtual address cannot be used normally.

fake-ip-filter prevents matching domains from receiving virtual IPs, but it does not automatically create direct-connection rules for them. After filtering LAN domains, make sure a resolver is available for those names. In particular, .local is often used with mDNS. Multicast discovery also depends on the system and LAN environment, so adding a filter entry alone may not fix it.

Using fake-ip does not mean you must enable TUN; what matters is whether connections associated with DNS results reach the core. Conversely, TUN can also be used with redir-host. After switching modes, clear the system DNS cache and restart affected apps to prevent them from continuing to use stale real or virtual addresses.

TUN DNS hijacking: send port 53 queries to the core

TUN creates a virtual network interface and routes IP traffic that matches its routing conditions into the core. dns-hijack identifies DNS requests among that traffic and passes them to the built-in DNS module. It does not modify every DNS packet or decrypt encrypted traffic; requests must first enter TUN for the hijack rules to handle them.

mihomo example for UDP and TCP port 53

The following uses a common combination of mihomo fields and requires an enabled dns section. First confirm that the current core supports these options; don't apply them directly to the core bundled with older versions of Clash for Windows. On Windows, a client service or sufficient permissions may also be needed to create interfaces and routes.

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53
    - tcp://any:53

• stack: mixed selects a mixed network stack. This is a core capability option, not a universal switch supported by every older version.
• auto-route: true configures related routes automatically, but does not guarantee coverage of every app, network adapter, or route created by another VPN.
• auto-detect-interface: true detects the outbound interface automatically; verify the result if multiple network adapters or virtual adapters are present.
• any:53 matches UDP queries on port 53, while tcp://any:53 adds TCP port 53. Large responses and retries may use TCP.

Why DNS connections may still go elsewhere when hijacking is enabled

A browser's “Secure DNS” setting may connect directly to a DoH service, while Android's “Private DNS” typically uses DoT. These are not ordinary UDP/TCP port 53 queries, so the two rules above cannot redirect them to the core's DNS module. An app's own DoH request may enter the proxy as a regular HTTPS connection, but routing traffic through the proxy and sending a query to the core's DNS module are two different things.

For troubleshooting, temporarily turn off Secure DNS in the browser and compare results using the system resolver, then decide whether to turn it back on. Don't conclude that DNS is leaking based on a single online DNS test; it may show the recursive resolver's exit address, not your device's or proxy node's address. Check connection logs, the actual exit route, system settings, and packet captures together.

Verify in order: listener, resolution, interception, rules

If websites stop loading after you enable TUN, don't change the proxy node, DNS settings, and network stack all at once. The sequence below helps isolate the failing step and prevents a DNS failure from being mistaken for a proxy node issue.

1. Check the listener: Confirm the configuration has been reloaded and the logs show no address-in-use or permission errors. This guide tests 127.0.0.1:1053; if your configuration uses a different port, update the test command too.
2. Query the core's DNS directly: Specify the local server and port to bypass the system's default resolver. If this fails, check upstream connectivity, bootstrap resolution, and configuration syntax first.
3. Check the default path: After enabling TUN, run a query without specifying a server and compare it with the core logs to see whether system requests are being intercepted.
4. Check the actual connection: In the client's connection list, check the destination domain, matched rule, policy group, and outbound node. If resolution succeeds but the connection times out, continue troubleshooting the rules, node, and network route.

Windows queries and cache clearing

In Command Prompt, enter nslookup to start interactive mode, then run the following three lines in order. example.com is used for a basic query; no response value is assumed in this example.

server 127.0.0.1
set port=1053
example.com

After exiting interactive mode, run the following command to clear the Windows DNS cache. Browsers may also have their own cache, so fully quit and reopen them if needed.

ipconfig /flushdns

Query examples for macOS and Linux

On a system with dig installed, you can test UDP and TCP separately. Both commands query the local port 1053 directly; they do not verify whether the system's default DNS settings have changed.

dig @127.0.0.1 -p 1053 example.com A
dig @127.0.0.1 -p 1053 example.com A +tcp

Troubleshooting and final configuration checks

The final checks come down to four points: the DNS listener is reachable, upstreams are accessible, app queries follow the expected path, and connections match the right rules. Verify each one before adding fallback filters, fake-ip exceptions, or more complex split DNS. This keeps a reproducible baseline and makes it easier to restore the configuration after a subscription update or client change.