How to Set Up Fake-IP DNS in Clash Verge Rev on macOS

What Fake-IP DNS Does in Clash Verge Rev

Fake-IP is a DNS handling mode provided by the mihomo kernel used by current Clash Verge Rev builds. Instead of returning the real address of a domain to macOS, Clash assigns the domain a synthetic address from a reserved range, usually 198.18.0.0/16. When an application later connects to that synthetic address, Clash looks up the original domain internally and forwards the connection according to your rules.

This changes the order of events inside the proxy stack. With ordinary DNS resolution, an application asks the operating system for an address, receives a real IPv4 result, and may then send an IP connection into Clash. With Fake-IP, Clash can preserve the domain name associated with the request and match domain rules before the connection is reduced to an ordinary IP address. That is especially useful for rules such as DOMAIN-SUFFIX, GEOSITE, and domain-based proxy groups.

Fake-IP is not an encrypted DNS protocol by itself. It describes how Clash represents DNS answers locally. The upstream resolvers listed under nameserver can still use plain DNS, DNS over TLS, or DNS over HTTPS. If the goal is to keep resolution away from the local network, choose encrypted upstreams and make sure the traffic capture method is configured correctly.

On macOS, system proxy mode mainly configures HTTP and SOCKS proxy settings for applications that respect those settings. It does not automatically capture every DNS request or every application connection. TUN mode provides broader system-level interception, while Fake-IP supplies the synthetic address mapping used by the DNS module. For a reliable system-wide setup, treat these as two related but separate settings: Fake-IP controls DNS answers, and TUN controls how traffic reaches Clash.

Check the Client, Kernel, and Current Profile First

Before changing the profile, open Clash Verge Rev on macOS and confirm that the running core is mihomo or another Clash Meta-compatible core. The exact label depends on the client release, but it is normally visible in the settings, profile, or core information area. Fake-IP configuration keys belong to the core configuration, not to the macOS system proxy panel, so changing the system DNS manually is not a substitute for editing the Clash profile.

• Update the client carefully. Use a current Clash Verge Rev build that supports the mihomo DNS fields used by your profile. If an imported profile is generated remotely, a local override may be safer than editing the provider's original content.
• Back up the active profile. Save a copy of the YAML before editing. A single indentation error can prevent the profile from loading, and a backup makes rollback immediate.
• Know where the subscription is managed. If the profile is overwritten during an update, locally added DNS settings may disappear. Check whether Clash Verge Rev offers an override, patch, or merge section for the selected profile.
• Close competing network tools. Another VPN, DNS filter, firewall, or proxy utility may intercept port 53, install a virtual interface, or rewrite macOS resolver settings. Disable those tools during the first test.
• Record the baseline. Note which websites work, which proxy group is selected, and the output of scutil --dns. This gives you something concrete to compare after Fake-IP is enabled.

Clash Verge Rev commonly provides a profile editor through the profile list or a menu beside the active configuration. Some releases expose the complete YAML, while others separate the original profile from local overrides. Use whichever method keeps your changes attached to the profile that is actually running. Editing an unused subscription file will not change the active DNS behavior.

Recommended Fake-IP DNS Configuration

The following is a practical starting point for a mihomo-based Clash Verge Rev profile. It enables Clash DNS, selects Fake-IP, defines a synthetic address pool, and uses encrypted upstream resolvers. The hostnames and addresses are examples; replace them with resolvers that are reachable and appropriate for your network.

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  respect-rules: true
  default-nameserver:
    - 223.5.5.5
    - 1.1.1.1
  proxy-server-nameserver:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query
  nameserver:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "localhost.ptlogin2.qq.com"
    - "+.msftconnecttest.com"
    - "+.msftncsi.com"

enable: true activates the DNS module. enhanced-mode: fake-ip selects the behavior discussed in this guide, while fake-ip-range defines the reserved pool used for synthetic answers. Keep that range private to Clash and do not route it through a proxy node as if it were a public network.

The listen value determines where Clash accepts DNS requests. Port 1053 is often a practical desktop choice because another local service may already occupy port 53. If your client or TUN integration expects a different listener, follow the port shown in the client documentation or existing profile. The key requirement is consistency: the system or TUN DNS hijack target must point to the listener that Clash is actually using.

default-nameserver is used to bootstrap resolver hostnames. Use plain IP addresses here rather than a URL beginning with https:// or tls://. The bootstrap chain needs a directly reachable resolver before it can resolve the hostname of an encrypted DNS endpoint. The entries under nameserver are the normal upstreams used for everyday queries, and the proxy-server-nameserver list helps resolve proxy server hostnames when those names cannot be reached directly.

respect-rules: true allows DNS requests to follow relevant routing behavior where supported by the profile. It is useful when different domains need different resolution paths, but it is not a universal guarantee that every query will travel through the proxy. The actual result still depends on the mihomo version, TUN settings, rule providers, and whether the upstream resolver itself is reachable.

Edit and Apply the Profile on macOS

Make the change while the correct profile is selected, then apply it before testing. The names of buttons may differ between Clash Verge Rev releases, but the sequence is the same: open the active profile, add or modify the top-level DNS block, save the file, reload the profile, and confirm that the running configuration has changed.

1. Open Clash Verge Rev and go to the profile or configuration view. Identify the profile marked as active rather than editing an older downloaded subscription.
2. Create a backup or duplicate of the profile. If the client supports local overrides, use that feature when you want to preserve changes across subscription refreshes.
3. Add the dns: block at the top level. Use spaces for indentation and keep list items aligned beneath their parent key.
4. Save the YAML, then use the client's reload, apply, or switch-profile action. A saved file is not necessarily the same as a loaded runtime configuration.
5. Open the client logs or status panel and look for configuration parse errors. Resolve errors before enabling more features.
6. Enable the macOS system proxy for browser and standard HTTP applications. If you need coverage for applications that ignore system proxy settings, enable TUN mode and approve the macOS network extension or administrator prompt.
7. Clear old DNS state only after the new profile is running. Restarting the relevant application is usually safer than changing several macOS network settings at once.

When enabling TUN, review the options rather than selecting every switch blindly. Auto-route normally adds routes needed for system-wide capture, while DNS hijack redirects selected DNS destinations to Clash. If the client exposes a DNS hijack list, point it at the configured Clash DNS listener. A mismatch between listen: 0.0.0.0:1053 and a hijack target aimed at port 53 can produce a setup that appears enabled but never receives system queries.

macOS may ask for a password when Clash installs or updates its privileged helper, changes system proxy settings, or activates a network extension. Approve only prompts clearly associated with the client you opened. Afterward, confirm the active network service in macOS and check that no separate VPN has taken priority over the Clash virtual interface.

Choose Fake-IP Filters Without Breaking Local Services

Fake-IP works well for ordinary public domains, but some software expects a real local address or performs its own address validation. The fake-ip-filter list tells Clash to return normal DNS results for selected names instead of synthetic addresses. Start with a small list and add exceptions only when a reproducible application problem justifies them.

Local Network Names

Names such as printer.lan, nas.local, or a home router hostname may need local resolution. Patterns such as *.lan and *.local are common starting points, but the exact behavior depends on your local DNS and multicast DNS setup. If a local device uses a custom suffix, add that suffix rather than excluding every domain from Fake-IP.

Captive Portal and Connectivity Checks

Operating systems periodically contact connectivity-check domains to determine whether a network requires a sign-in page. If those checks receive an unexpected synthetic response, macOS may display incorrect Wi-Fi status or fail to open a captive portal. Excluding the relevant check domains can help, but do not use a broad wildcard such as *.com; that would effectively disable Fake-IP for a large portion of the internet.

Applications With Their Own DNS Logic

Some browsers, security products, development tools, and game launchers use built-in DNS-over-HTTPS, hardcoded resolvers, or separate network processes. These requests may bypass the normal system resolver. Disable the application's independent secure DNS option during troubleshooting, or configure it to use the system resolver if you want Clash to handle DNS centrally. A successful Fake-IP result from dig does not prove that every application follows the same path.

Verify DNS, Routing, and Leak Behavior

Test one variable at a time. First confirm that Clash is answering DNS, then confirm that the selected rule is correct, and finally check whether traffic and DNS are escaping through another interface. Do not judge the setup solely by whether one webpage opens.

1. Open Terminal and run dig example.com. With Fake-IP active, a normal public domain may return an address in the configured 198.18.0.0/16 pool. The exact address can change after the cache is cleared.
2. Run scutil --dns and inspect the active resolver information. This shows macOS resolver state, but it does not by itself prove that every application is using Clash.
3. Open the Clash Verge Rev connections or logs panel, request a domain in a browser, and confirm that the connection appears with the expected domain and policy group.
4. Temporarily switch between DIRECT and a proxy group for a test domain. If the selected policy changes the connection result, rule matching and outbound selection are functioning.
5. Run a reputable DNS leak test while all other VPN and DNS utilities remain disabled. Compare the reported resolvers with the path you intended to use.
6. Repeat the test with TUN disabled and enabled. A difference is expected for applications that ignore the macOS system proxy; this identifies whether the problem is proxy support or DNS configuration.

Fix Common Fake-IP Problems on macOS

If the profile fails to load immediately after editing, check YAML structure first. The dns: key must be aligned at the root level, list items need consistent indentation, and every URL must be quoted if it contains characters that your parser treats specially. The client log usually reports a line number; inspect the lines above it as well, because an indentation mistake often affects the following key rather than the line where it becomes visible.

If DNS starts working but websites fail, inspect the proxy group's selected node and the connection log separately. A synthetic address is not a proxy connection, and Fake-IP cannot repair an unavailable node, an incorrect rule, or a blocked upstream. Test a known direct domain and a known proxied domain, then compare their policy selections.

If only some domains fail, clear the Clash DNS cache or restart the client, then retry with a fresh query. Old mappings can survive a profile change. Check nameserver-policy, rule-provider updates, and any domain listed in fake-ip-filter. A filter added for troubleshooting should be removed if it is no longer needed.

If macOS still uses an unexpected resolver, inspect TUN status, DNS hijack settings, and network extensions. Also check whether IPv6 is enabled in the profile while the selected upstreams or rules only support IPv4. Temporarily setting ipv6: false can narrow the diagnosis, but restore IPv6 after testing if your network and rules are prepared for it.

Finally, refresh the profile and verify persistence. Subscription updates can replace the entire YAML, while local overrides may remain separate. After every refresh, confirm that enhanced-mode: fake-ip is still present in the loaded configuration and that the active core has not switched to an older implementation with different supported fields.

A Safe Operating Checklist

For most macOS users, the dependable sequence is straightforward: run a mihomo-compatible Clash Verge Rev build, back up the active profile, enable the Clash DNS module, select Fake-IP, use a sensible reserved range, configure reachable upstream resolvers, apply the profile, and then test system proxy and TUN coverage separately. Keep local and captive-portal exceptions narrow, because excessive filtering can silently return real DNS answers for domains that should remain under Clash control.

When a problem appears, avoid changing five settings at once. Check whether the profile loaded, whether Clash received the query, whether Fake-IP returned a synthetic address, whether the rule selected the intended outbound, and whether the application bypassed the system proxy. That sequence identifies the failing layer much faster than repeatedly switching nodes or changing macOS DNS servers.

For a broader installation workflow, including profile import, permissions, system proxy mode, and TUN basics, use the site tutorial. When you need a fresh client package or want to compare available desktop builds, open the download center.