Clash DNS Setup Guide: nameserver, fallback, and DNS hijacking

Bottom line: On Android, first make sure DNS queries are actually reaching Clash, then adjust the DNS servers. nameserver is the regular upstream resolver; fallback is another set of upstreams used to filter and select results—not simply a backup that kicks in only after the primary server goes down. fake-ip determines what address is returned to apps, while DNS hijacking determines which queries are routed into the core. These settings operate at different layers and are not interchangeable.

1. How Android DNS Queries Reach Clash

When an app opens a domain, it typically asks the system resolver for an address before connecting. After you grant VPN permission, an Android client can receive traffic through a virtual network interface. Whether it also intercepts DNS depends on the client's VPN implementation, DNS settings, and app access controls.

1. The app calls the system resolver, which sends a query to the DNS address configured for the current network.
2. The VPN interface receives traffic that meets the interception criteria, and the client or core passes DNS queries to its internal resolver.
3. The internal resolver checks its cache, domain policies, and settings such as nameserver, then queries an upstream server when needed.
4. The core returns a real address or a Fake IP to the app. The app then connects to that address, and the core uses its rules to decide whether to connect directly or through a proxy node.

So, “VPN connected” only means the service is running; it doesn't guarantee that every app's DNS queries reach the core. Apps excluded from the VPN and browsers with their own encrypted DNS may use a different path. To troubleshoot, test with a browser that isn't excluded, temporarily turn off its “Secure DNS,” and compare the results with the logs.

DNS Hijacking Mainly Intercepts Standard Port 53 Queries

Typical DNS hijacking targets UDP or TCP on port 53. Android's “Private DNS” strict mode generally uses DNS over TLS on port 853; built-in browser DNS over HTTPS typically uses port 443. A standard port 53 hijack rule won't directly turn these into DNS queries handled by the core.

The “Private DNS” setting moves around between Android versions. It's usually under Settings → Network & internet → Private DNS, though some devices put it under Connections & sharing. When troubleshooting, note the current setting, temporarily disable strict mode, and reconnect the VPN to test. Decide whether to restore it after testing; don't treat disabling it as a universal requirement.

2. What Each dns Field Does

default-nameserver Does Not Resolve Every Website by Default

For example, if an upstream is set to https://dns.alidns.com/dns-query, the client first needs the address for dns.alidns.com to connect to that HTTPS service. A bootstrap server handles this initial lookup. Using an IP address for the bootstrap server avoids a loop where you need to reach a DNS server in order to resolve that same server's hostname.

Classic configurations often use regular IP addresses for default-nameserver. Supported protocols for this field vary by core, so keep the simpler format when migrating an older config. Don't mistake a failure to resolve an upstream hostname for every proxy node failing at once.

Don't Set listen to 7890

7890 is commonly used for HTTP or mixed proxy traffic; DNS listening is a separate service. The example below uses 127.0.0.1:1053 for local DNS, avoiding a low-numbered port that may require special permissions. Android clients may choose internal ports themselves or not use this listener at all, so check the runtime config. Setting listen alone won't make Android send queries to it.

3. Basic nameserver and fallback Configuration

This snippet illustrates how the fields relate; it is not a complete config for every subscription. It uses one regular DoH upstream and one fallback DoH upstream, with GeoIP filtering disabled and a reserved address range to demonstrate filtering. Both HTTPS services must be reachable on your current network and routing setup.

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  nameserver:
    - https://dns.alidns.com/dns-query
  fallback:
    - https://1.1.1.1/dns-query
  fallback-filter:
    geoip: false
    ipcidr:
      - 240.0.0.0/4

• 198.18.0.1/16 configures the Fake IP address pool, which maps domains to virtual addresses. Don't use it for proxy node addresses.
• 240.0.0.0/4 is used here as an example of filtering an abnormal response. This is not a complete list of reserved ranges and won't catch every invalid resolution.
• geoip: false disables GeoIP-based fallback selection, keeping differences in geographic databases out of this test.
• ipv6: false helps narrow down the issue. If you need IPv6, confirm that your node, network, and interception path all support it, then enable and test it separately.

More upstreams aren't necessarily better. Multiple servers can increase query volume and return different results. Start with a reachable, predictable set of upstreams to establish a baseline, then add domain policies or fallback. Encrypted DNS protects queries in transit between your device and that resolver; it doesn't automatically route subsequent website connections through a proxy.

4. How fallback-filter Selects Between Results

In common implementations of classic Clash, queries to both groups may run concurrently when fallback is configured. The core uses the filter conditions to decide which answer to use; it doesn't necessarily wait for nameserver to time out before querying fallback. Check the core you're using for its exact behavior around concurrency, caching, and errors.

Three Common Filter Types

• GeoIP: Classic configs often use geoip: true with geoip-code: CN, using the geographic location of the primary result to choose an answer. The decision uses the IP location recorded in the GeoIP database, so database versions can affect the result.
• IP ranges: ipcidr matches specified address ranges in the primary response. For example, if the result matches the reserved range in the config above, the fallback result is used.
• Domains: domain can route matching domains to fallback results. Check the core's documentation for the exact matching syntax; don't paste a full proxy rule into this list.

With GeoIP filtering enabled, a legitimate site using an overseas CDN address may also trigger fallback. That's a result of the filter, not proof that the primary DNS response was tampered with. Conversely, an abnormal answer may fall within an apparently valid range. Don't treat fallback-filter as a security checker that can automatically verify every DNS response.

mihomo Domain Policies and Node Hostname Resolution

mihomo offers nameserver-policy to choose resolvers for specific domains, and proxy-server-nameserver to resolve proxy node hostnames specifically. The latter helps you troubleshoot node address resolution separately from DNS lookups for sites you visit. Don't apply these extensions directly to older Clash cores.

# Example fields inside mihomo's dns block only
nameserver-policy:
  '+.example.com':
    - https://dns.alidns.com/dns-query
proxy-server-nameserver:
  - https://dns.alidns.com/dns-query

Here, example.com is a syntax example, not a domain that will match your sites. To select an upstream by domain, enter the domain you actually need to handle and check that the client preserves the fields. Don't change the policy, fallback, and node resolution at the same time, or it will be hard to tell which change affected the result.

5. Choosing Between fake-ip and redir-host

For general proxy browsing, you can usually start with the client's default fake-ip mode. When an app connects to a virtual address, the core can recover the associated domain and apply its rules to establish the actual connection. The real address of the target site doesn't have to be resolved before an address is returned to the app every time; however, the actual egress route, IP-based rules, and specific routing may still require DNS resolution.

If only casting, LAN device discovery, or one particular app is affected, consider using fake-ip-filter to return a real address for specific domains. Identify the domain first and add the narrowest possible exception; don't exclude every domain from the start. Filter modes and matching support vary by version, so check the config loading logs after adding this field.

After switching to redir-host, apps may still have old DNS or connection data cached. Stop and restart the proxy service, then fully close and reopen the app you're testing. Pinging a Fake IP is not a reliable way to check whether a proxied website is reachable.

6. Android DNS Hijacking and TUN Configuration: What's Different

VPN traffic handling in the original Clash for Android is implemented jointly by the Android client and the core. It isn't the same as copying desktop TUN settings onto a phone. First, check the client's Settings for options related to DNS overrides, network stack, and app access controls. Menu names vary between forks, so don't assume a button is in the same place across clients.

For clients that explicitly support mihomo TUN settings, the fields below are a common example. They illustrate interception targets; they aren't a complete setup that replaces the Android client's VPN settings.

tun:
  enable: true
  dns-hijack:
    - any:53
    - tcp://any:53

any:53 is used for common UDP DNS interception, and tcp://any:53 adds TCP DNS. Whether they work depends on whether traffic enters the TUN, whether the client permits these settings, and whether additional routes exclude it. When the Android client creates the VPN interface, use its supported configuration options first. Don't create a second interception setup just to apply this snippet.

7. Verification Steps and Common Problems

1. Confirm the config loaded. Save and reload the config. Check for YAML indentation errors, unknown fields, or invalid address formats, and make sure the selected profile is the one you just edited.
2. Check for runtime overrides. If the client has “Overrides” or “DNS settings,” compare its switches and server list with your config. Editing the subscription file doesn't necessarily change the settings currently in use.
3. Keep test conditions consistent. Use one browser, one network, and one node; note whether you're on Wi-Fi or mobile data. First rule out the browser's built-in DoH, then visit a domain you haven't opened before.
4. Check the logs. Temporarily enable the most detailed logging level supported by the client and look for upstream timeouts, TLS errors, or node hostname resolution failures. Restore your usual log level afterward, and remove subscription URLs and credentials before sharing logs.
5. Change one thing at a time. Test in this order: interception path → upstream reachability → mode → fallback filtering. Once connectivity is restored, add custom settings back one by one.

No Websites Open After Enabling DNS Hijacking

First check whether DNS upstreams are timing out. If an upstream is reachable only through a proxy, but the proxy node's hostname also needs that upstream to resolve, you can end up with a startup dependency loop. Fix the bootstrap resolution path first. With mihomo, you can also consider configuring node hostname resolution separately. Don't try to hide the issue by repeatedly switching rule modes.

Websites Load, but Local Devices or Casting Stop Working

Check whether local domains need your router or corporate DNS to resolve. Public DNS usually doesn't know device names maintained by a home router or records on a corporate network. If the core supports it, assign a local upstream to those domains and add Fake IP exceptions if needed. Also check that LAN addresses aren't being incorrectly sent through the proxy.

DNS Changes Disappear After a Subscription Update

Remote subscriptions usually replace the previous file with new content. If the client supports persistent overrides, merging, or patching, use that mechanism to keep your DNS customizations. Otherwise, keep a local copy and note which fields need to be merged again after an update. Don't assume a temporary edit is saved permanently.

Finally, verify “which address was resolved” separately from “where the connection goes.” The former depends on DNS settings, caching, and the interception path; the latter also depends on proxy rules, policy groups, and node status. For the full config structure, see the complete guide—DNS changes alone may leave rules or network routing unaddressed.