How To Configure Fake-IP DNS In Clash Verge Rev On macOS

Why Use Fake-IP DNS on macOS?

Clash Verge Rev can do much more than send browser traffic through a selected proxy. When its Mihomo core handles DNS requests in Fake-IP mode, it returns an address from a reserved virtual range instead of immediately exposing the real destination address to macOS. Clash then maps that virtual address back to the original domain and applies your routing rules before establishing the connection.

This design is useful when you want DNS requests and proxy decisions to follow the same rule set. Without a carefully configured DNS section, macOS may resolve a domain through the system resolver while Clash handles the subsequent connection. That split can lead to inconsistent routing, local DNS leaks, incorrect geolocation results, or rules that match later than expected. Fake-IP reduces this mismatch by allowing Clash to keep the domain-to-address relationship inside the core.

Fake-IP is not a magic replacement for a reliable proxy node. It does not improve a slow server, repair an invalid subscription, or make every application proxy-aware. It is a DNS and traffic-classification method that works best when combined with a valid Mihomo profile, a correctly enabled TUN or system proxy mode, and a small set of sensible exclusions.

1Check the macOS and Profile Requirements

Before editing YAML, confirm that Clash Verge Rev is using a core with Fake-IP support. Current Clash Verge Rev installations normally use the Mihomo core, but the exact version can vary. Open the client’s settings or dashboard and check the displayed core information. If the core is very old, update the application before troubleshooting DNS behavior.

You also need an active profile containing your proxy providers, proxy groups, and rules. DNS settings belong to the profile that Clash actually loads; editing an unused file will have no effect. In Clash Verge Rev, open Profiles, identify the profile marked as active, and use its edit option. If your provider regenerates the profile after every update, consider maintaining a separate local override or applying the DNS section through the client’s profile management feature, when available.

• Confirm the active profile: The profile should be selected and successfully parsed without a red validation error.
• Confirm the core: Mihomo should be running rather than an incompatible or missing backend.
• Back up first: Save a copy of the original YAML so you can restore it if a change causes startup failure.
• Close competing tools: Other VPN clients, DNS filters, and network extensions can intercept queries before Clash receives them.
• Know your access level: TUN mode may require an administrator password and macOS approval for a network extension.

2Build a Practical Fake-IP DNS Section

Place the following block at the top level of your active YAML profile. The word dns must start at the far-left margin, while its settings are indented consistently with two spaces. This example provides a conservative starting point for macOS users. You can adjust the upstream resolvers later, but first make the basic configuration work.

enable: true turns on the Mihomo DNS module. enhanced-mode: fake-ip selects the virtual-address method, while fake-ip-range defines the address pool used for generated responses. The 198.18.0.0/15 and related ranges are reserved for benchmarking and laboratory networks, so they are commonly used by proxy cores for this purpose. Do not route this range directly through your physical network interface.

The nameserver list is the primary resolver group. The fallback entries provide encrypted DNS-over-HTTPS alternatives when the primary path fails or when the fallback filter considers a response suspicious. A fallback server is not automatically a proxy server; whether its request travels through the proxy depends on the core version and the rest of your DNS settings. The important objective is consistency, not simply collecting a long list of public resolvers.

Setting ipv6: false is a compatibility choice, not a universal requirement. If your ISP, proxy provider, and local network all support IPv6 correctly, you can enable it later. During initial testing, disabling IPv6 removes one common source of bypasses and makes the results easier to interpret.

3Choose Fake-IP Exclusions Carefully

Fake-IP works well for ordinary web domains, but some software expects a real DNS answer. Local network discovery, router administration pages, captive portals, time synchronization, and certain security applications can fail if they receive a virtual address. The exclusion list tells Mihomo to resolve matching domains in redir-host style instead of assigning Fake-IP addresses.

The entries shown above are starting points rather than a mandatory universal list. For example, *.lan and *.local cover common home-network names, while Microsoft connectivity-test domains help macOS and other systems determine whether an internet connection is available. Time servers are excluded because inaccurate time can cause TLS certificates, subscription links, and authentication tokens to fail.

Add an exclusion only when you can explain why it is needed. An unnecessarily broad pattern such as * effectively disables Fake-IP for every domain. That may hide the original problem and return you to the DNS behavior you were trying to correct. Prefer a narrow domain or suffix:

• Use +.example.com when the parent domain and its subdomains need real answers.
• Use an exact hostname when only one endpoint has a compatibility issue.
• Use local suffixes such as *.lan for devices on your private network.
• Exclude router names, printer discovery domains, and internal company domains only when they are actually used.
• Avoid placing public websites in the exclusion list simply because they load slowly; that is usually a routing or node problem.

Some applications use hard-coded IP addresses, DNS-over-HTTPS inside the application, or their own encrypted resolver. Fake-IP cannot control those requests in the same way as ordinary system DNS. For such software, check its network settings separately and disable its private DNS feature temporarily while testing.

4Apply the Configuration in Clash Verge Rev

After the profile reloads, enable the traffic mode that matches your goal. System Proxy is suitable for applications that respect macOS proxy settings, especially browsers and many desktop tools. TUN mode is more comprehensive because it creates a virtual network interface and can capture applications that do not use the system proxy. TUN mode may display a macOS permission prompt; approve it only for the Clash Verge Rev installation you trust.

Do not enable multiple VPN or network-tunnel products at the same time. They can compete for the default route, install conflicting DNS resolvers, or cause a loop in which Clash tries to proxy its own DNS connection. If you need another security product, test it separately after Fake-IP is confirmed to work.

5Test DNS Resolution and Proxy Behavior

Test in stages rather than opening one website and assuming the configuration is correct. First verify that the profile loaded, then check whether a normal domain receives a Fake-IP address, and finally confirm that traffic follows the intended proxy rule.

Use Terminal for Basic Checks

Open Terminal on macOS and query a domain that is not in your exclusion list. The exact output depends on the active network service, but a working Fake-IP setup commonly returns an address in the configured virtual range:

Do not treat a public resolver shown by scutil --dns as proof that Clash is bypassed. macOS may display the configured resolver while the TUN interface or system proxy captures the request. Use the Clash Verge Rev connection log and DNS panel as additional evidence. Look for the queried domain, the selected rule, and the proxy group used for the connection.

Next, test a domain that you intentionally excluded, such as an internal router hostname or a local service. It should resolve to its real private address rather than an address from 198.18.0.0/16. If both ordinary and excluded domains behave identically, check the spelling of the filter patterns and confirm that the edited profile is active.

Check Browser Access and Public IP

Open a private browsing window and visit a DNS leak test or an IP-checking service. A public IP check confirms the selected proxy route, while a DNS test can reveal whether requests are escaping through the local ISP. Results are not always immediate because browsers cache connections and DNS answers, so close all test tabs, clear the Clash DNS cache, and run the test again if necessary.

• Ordinary proxied domains should appear in the Clash connection log.
• Domains assigned to DIRECT should use the direct route by design.
• Excluded local domains should resolve to usable private or real addresses.
• A Fake-IP address should not be opened directly in a browser as if it were a public website.
• Application-specific DNS settings should be reviewed when the system test passes but one application still bypasses Clash.

6Troubleshoot Common macOS Problems

Websites stop loading after enabling Fake-IP. First confirm that the proxy node itself is reachable. Then inspect the log for failed DNS requests and temporarily reduce the configuration to one primary resolver and one fallback resolver. A malformed YAML block, incorrect indentation, or an unreachable DoH endpoint can make the DNS module appear broken.

Local devices cannot be reached. Add the relevant local suffix or exact hostname to fake-ip-filter. Check that your rules send private address ranges directly where appropriate. Router pages often use names such as router.lan, while some devices are accessed through raw IP addresses and do not need DNS at all.

The DNS leak test still reports the ISP resolver. Make sure the system proxy or TUN mode is actually enabled, and inspect macOS network settings for another manually configured DNS service. Quit other VPN clients and DNS filtering tools. Also remember that a browser with Secure DNS enabled may send its own DoH requests; disable that feature temporarily for a controlled test.

Only one application fails. The application may ignore the system proxy, use QUIC independently, maintain a private resolver, or require TUN mode. Try TUN mode, review the application’s proxy and DNS preferences, and check whether its domains need a narrow exclusion. Avoid switching to Global mode as the first response, because it can hide a missing or incorrect rule.

Connections work until the Mac wakes from sleep. Sleep and network changes can leave stale mappings or an outdated interface route. Restart the affected application, toggle the system proxy or TUN mode, and clear the Clash DNS cache. If the issue repeats, check whether the Wi-Fi network changes DNS settings after reconnection.

7A Stable Baseline for Daily Use

Once the basic tests pass, keep the configuration simple. Use Fake-IP for normal internet domains, maintain a short exclusion list for local and compatibility-sensitive services, and let rules decide whether traffic is PROXY, DIRECT, or REJECT. Choose one primary operating mode for daily use instead of repeatedly switching between system proxy, TUN, and Global mode without testing.

Review the setup after changing subscriptions, networks, or macOS versions. Providers may overwrite DNS settings when they regenerate a profile, and a new rule provider may alter how domain matching works. Keep dated backups of known-good profiles and record which exclusions you added and why. This makes future troubleshooting much faster than copying random DNS blocks from unrelated configurations.

Fake-IP should ultimately be judged by behavior: stable domain routing, no unexpected local DNS exposure, working local services, and predictable proxy logs. If those four conditions are met, the configuration is doing its job. If performance remains poor, investigate node latency, congestion, MTU, and application behavior instead of adding more DNS servers.

Download Clash for Free – Get Started Now →