Why Fake-IP DNS matters in Clash Verge Rev on Windows
If you searched for Clash Verge Rev Fake-IP DNS, Fake-IP DNS on Windows, or “Clash DNS interception not working,” you are probably dealing with one of several confusing symptoms: websites open in a browser but applications fail, domain rules appear inconsistent, Windows keeps using the wrong resolver, or the Mihomo log shows requests going directly to an unexpected DNS server. These problems are rarely solved by switching a proxy node alone. The DNS resolution method must also match the way Clash Verge Rev receives, classifies, and forwards traffic.
Fake-IP mode gives Clash a controlled answer for domain lookups. Instead of immediately returning the real address of a website, the DNS service returns an address from a reserved virtual range. When an application connects to that address, Mihomo can associate the connection with the original hostname and apply rules such as DOMAIN-SUFFIX, GEOSITE, or GEOIP. This is especially useful when an application does not expose the hostname clearly at the connection stage, or when you want domain-based routing to remain reliable across Windows programs.
This guide focuses on the Windows desktop workflow in Clash Verge Rev. It explains the difference between redirection and fake-IP DNS, shows how to edit the active profile safely, covers the Windows permission and system-proxy layers, and provides tests that help distinguish a DNS problem from a rule, node, firewall, or application problem. The exact labels can vary slightly between releases, but the underlying Mihomo configuration concepts remain consistent.
Fake-IP, redirection, and Windows DNS: three layers to understand
Clash Verge Rev can influence DNS in more than one way, and these mechanisms should not be treated as interchangeable. A normal DNS request asks a resolver for the real address of a hostname. A redirection mode attempts to capture DNS traffic, often by redirecting packets sent to port 53 toward the Clash DNS listener. Fake-IP mode goes one step further: it answers eligible queries with synthetic addresses and remembers the hostname-to-synthetic-address relationship internally.
On Windows, these layers can be separated like this:
- Application DNS behavior: a browser, game, terminal, or background service may use the Windows resolver, its own DNS-over-HTTPS implementation, or a hard-coded resolver.
- Windows network settings: the adapter may point to a router, a public resolver, or another local service. VPN software and security products can also add virtual adapters.
- Clash DNS engine: Mihomo listens on configured ports, selects a nameserver, returns fake addresses when enabled, and later maps those addresses back to hostnames for routing.
Fake-IP does not automatically mean that every packet on the computer is captured. If an application bypasses the system resolver, uses encrypted DNS independently, connects directly to a literal IP address, or runs inside a separate sandbox, the request may never enter the expected Clash DNS path. That is why enabling a setting in the profile is only one part of the job. You must also confirm that the application and Windows are actually using the path you configured.
There is another practical distinction. Enhanced Mode is usually the setting that selects how Mihomo handles DNS addresses, while the dns: section defines which DNS service listens, which upstream resolvers are used, and which domains should bypass or prefer a particular resolver. Changing the mode without reviewing the rest of the section can leave you with a fake-IP engine that has no usable upstream path or an incompatible exception list.
Prepare the profile before changing DNS
Start by opening Clash Verge Rev with the same Windows account that normally runs your proxy. Confirm that the application is connected to a profile you are allowed to modify. A remote subscription profile may be regenerated whenever you update it, which can overwrite manual edits. If the profile is managed by a provider, use a local override or a dedicated local copy rather than repeatedly modifying the remote source.
Before editing, record the current state. Note the active profile name, the current DNS mode, whether the system proxy is enabled, and whether TUN is enabled. Taking a screenshot of the profile and the DNS page is useful because it lets you reverse a change without guessing. Also check that the system clock is correct and that Clash Verge Rev has a current subscription or at least one node that already works for ordinary web traffic. A broken node can make a correct DNS setup look defective.
Close applications that maintain long-lived connections, particularly browsers, game launchers, development tools, and messaging clients. They may cache DNS answers for several minutes or longer. You do not need to close Clash Verge Rev itself, but you should be prepared to reload the profile and restart the test application after the change.
Finally, check for competing network software. Another VPN, a corporate security agent, a virtual machine platform, Docker, WSL, or a DNS filtering product may install adapters or listeners. Two programs attempting to control the same DNS path can produce intermittent results: one lookup appears in Mihomo, while the next lookup goes to a resolver that Clash never sees.
Configure Fake-IP DNS in the active Clash profile
Open the Profiles or 配置 area in Clash Verge Rev and identify the profile currently marked as active. Open its editor or use the application’s local override feature. Locate the dns section. If the profile does not contain one, add it at the top level of the YAML file with consistent indentation. YAML is whitespace-sensitive, so use spaces rather than tabs and keep child properties indented under dns:.
A practical baseline looks like this:
dns:
enable: true
listen: 0.0.0.0:1053
ipv6: false
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
nameserver:
- https://dns.google/dns-query
- https://cloudflare-dns.com/dns-query
fallback:
- tls://1.1.1.1:853
- tls://8.8.8.8:853
fake-ip-filter:
- '*.lan'
- '*.local'
- 'localhost.ptlogin2.qq.com'
- '+.msftconnecttest.com'
- '+.msftncsi.com'The exact upstream resolvers are not universal recommendations. Use resolvers permitted by your network, provider, organization, or local regulations. The important elements are enable: true, enhanced-mode: fake-ip, a valid fake-ip-range, and at least one reachable upstream resolver. Port 1053 is commonly used by desktop Clash clients because another Windows service may already occupy port 53. If your installation exposes a different listener port, keep the application’s expected port and do not copy this value blindly.
The ipv6 choice deserves attention. Setting it to false can simplify troubleshooting on networks where IPv6 is advertised but not routed correctly. It does not improve every connection, however. If your ISP and nodes support stable IPv6 and you specifically need IPv6 destinations, disabling it may create a different class of failure. Treat this as a diagnostic choice first, then enable IPv6 only after ordinary IPv4 tests are stable.
The fake-IP range should not overlap with your home LAN, office network, Docker bridge, or corporate routes. The commonly used documentation range is convenient, but you should change it if your environment already uses that address space. A conflict can make local devices appear unreachable or cause traffic to be sent toward the wrong interface.
Use the fake-IP filter for local and sensitive domains
Not every hostname should receive a synthetic address. Local discovery names, router interfaces, captive-portal checks, and some authentication services often behave better with real DNS answers. Add exceptions deliberately rather than copying a very large filter list that you cannot maintain. A broad filter can silently send important domains outside the fake-IP mechanism and make rule behavior harder to understand.
Common candidates include local suffixes such as *.lan and *.local, the router hostname, printer domains, Windows connectivity-test domains, and services that explicitly require a real address. If a particular application fails only when fake-IP is enabled, temporarily place its hostname in fake-ip-filter, reload the profile, and test again. If that fixes the issue, you have evidence of an application compatibility problem rather than proof that the entire DNS configuration is wrong.
Apply the profile and enable the Windows traffic path
Save the edited profile, return to the profile list, and activate it if Clash Verge Rev does not do so automatically. Reloading the profile is important because changing a file on disk does not always replace the running DNS engine. Look for a reload, refresh, or apply control in the profile page. Then open the DNS or settings panel and confirm that the enhanced mode reports Fake-IP rather than Redir-Host or a disabled state.
Next, decide which traffic path you are testing. For ordinary browser applications, enable the Windows system proxy in Clash Verge Rev. This affects programs that respect the Windows proxy setting, but it does not force every application to use Clash. For applications that ignore system proxy settings, enable TUN only if you understand its permissions and routing effects. TUN can capture more traffic, including programs that never read Windows proxy settings, but it may interact with antivirus software, other VPN adapters, virtual machines, and administrator policies.
If Windows asks for administrator approval when enabling TUN or installing a service, verify that the request belongs to Clash Verge Rev and that the installation path is the one you expect. Do not approve repeated prompts from unknown binaries. After enabling TUN, wait a few seconds for the adapter and routes to settle, then reopen the test application. A browser session created before the change may retain old proxy or DNS state.
Do not test several variables at once. First check DNS interception with system proxy enabled and TUN disabled. Then test an application that normally respects the system proxy. If that works, test a stubborn application with TUN. This sequence gives you a useful baseline and prevents you from blaming fake-IP for a TUN driver or firewall problem.
Verify fake-IP DNS with observable tests
Use the Clash Verge Rev dashboard as the primary source of evidence. Open the Logs or Connections view and visit a new domain in a private browser window. You should see DNS activity or a connection associated with the hostname, followed by a rule decision and an outbound policy. The specific display depends on the version, but the key question is whether the request appears in Mihomo at all.
Windows command-line tools can provide supporting evidence:
ipconfig /flushdns
nslookup example.com
nslookup example.com 127.0.0.1
netstat -ano | findstr "1053"
curl -I https://example.comFlushing the Windows cache removes one source of confusion, but it does not clear every application’s internal cache. The second nslookup command is useful only when your Clash DNS listener is bound to the specified address and port configuration. If your listener is not on port 53, use the application’s DNS test panel or query the correct local endpoint. Do not interpret a failed test against 127.0.0.1 as proof that the profile is invalid when Clash is listening on another address.
Fake-IP responses commonly come from the configured synthetic range. If nslookup returns an address in that range and the request appears in Clash logs with the original hostname, the resolver is probably functioning. If the result is a normal public address, the request may have gone to the Windows resolver, a browser’s encrypted DNS service, or a filtered domain intentionally excluded from fake-IP.
Compare three cases: a normal public website, a domain that should be routed through a proxy, and a local device name. The first confirms basic resolution, the second confirms DNS-to-rule integration, and the third confirms that your exceptions do not break local access. Also inspect the selected rule and policy group. A correct fake-IP answer cannot compensate for a rule that sends the destination to DIRECT when you expected a proxy group.
Troubleshoot the most common Windows failures
No DNS request appears in Clash
If the browser works but no request appears in the Clash log, check whether the browser has enabled DNS-over-HTTPS. Chrome, Edge, Firefox, and security-managed browsers can send encrypted DNS directly to a provider instead of using the Windows resolver. Temporarily disable the browser’s independent secure-DNS option for testing, or configure it according to your organization’s policy. Also inspect whether a security product is forcing its own resolver.
Check the Windows adapter order and active network. A laptop may have Wi-Fi, Ethernet, a VPN adapter, WSL, and a virtual machine adapter active simultaneously. The application may be using a different interface from the one you expected. Restarting the browser after changing DNS settings is often necessary because its resolver process can remain alive after all visible windows close.
Fake-IP breaks one application
Some programs compare returned addresses, perform their own certificate or region checks, or expect local DNS replies to contain real addresses. Add the affected hostname to fake-ip-filter as a test, reload the profile, and clear the application’s cache. If the application then works, keep the exception narrow and document why it exists. If it still fails, inspect the connection log for blocked domains, failed TLS handshakes, or an incorrect rule group.
Local printers or intranet sites stop working
Confirm that local suffixes and router names are excluded from fake-IP where necessary. Review the nameserver-policy or rule-based DNS settings if your profile uses them, because a local domain may be sent to an external resolver that cannot resolve private names. TUN mode can also alter route priority. Temporarily disable TUN while keeping system proxy enabled; if local access returns, the issue is likely routing or adapter precedence rather than DNS alone.
Resolution is slow or inconsistent
Multiple upstream resolvers do not always improve reliability. They can return different answers, expose different regional views, or fail at different times. Test each upstream independently where possible, then keep a small set that is reachable from your network. Avoid adding an unlimited collection of public resolvers. Review timeout behavior, fallback rules, and whether your selected DoH or DoT endpoints are themselves being routed through a policy that depends on DNS.
DNS loops are another possibility. If Clash sends its upstream DNS request through a proxy that needs DNS resolution, while the DNS engine waits for that same proxy path to become available, startup can stall. Use an IP-based or otherwise bootstrappable resolver path where appropriate, and check the Mihomo log for repeated upstream failures. A profile that works after several minutes but fails at startup often has this dependency problem.
Maintain the configuration after it works
Once Fake-IP DNS is stable, export or back up the effective profile and any local overrides. Subscription updates may replace the generated YAML, remove custom DNS fields, or change the profile structure. Keep your personal edits in a separate override layer when Clash Verge Rev provides one. This makes updates safer and allows you to compare provider changes without losing your known-good settings.
Review the fake-IP filter whenever a Windows application is installed or updated. New launchers, enterprise agents, and local development tools may introduce hostnames that need real DNS or a specific resolver policy. Avoid using a filter as a substitute for understanding rules. Every exception increases the number of destinations that bypass the same resolution and routing behavior, so keep comments or external notes explaining the reason and the date of each addition.
When reporting a problem, collect the profile mode, whether system proxy or TUN was active, the DNS listener address, the hostname tested, the selected rule, and the relevant log message. Remove subscription tokens, private IP information, and credentials before sharing screenshots. “The internet is broken” is difficult to diagnose; “the hostname resolves to a fake address, appears in Connections, matches a proxy rule, but the TLS handshake resets only in TUN mode” is actionable evidence.
Frequently asked questions
What does Fake-IP change on Windows?
Fake-IP changes the answer returned for eligible domain queries so Clash can associate later connections with their original hostnames. This helps Mihomo apply domain-based rules even when the application connects using the synthetic address. It does not automatically capture applications that use their own encrypted DNS, hard-coded IP addresses, or an unrelated network tunnel.
Should I choose Fake-IP or Redir-Host?
Fake-IP is often useful when you need consistent hostname-aware routing and want Clash to handle domain classification before a real address is exposed to the application. Redir-Host can be easier for applications that reject synthetic addresses or for networks where fake-IP conflicts with local services. The better mode is the one that matches your applications, local topology, and provider rules; validate it with logs rather than choosing solely by reputation.
Do I need TUN for Fake-IP DNS?
No. Fake-IP DNS and TUN solve related but different problems. System-proxy-aware applications may work with the DNS engine and system proxy alone. TUN is useful for applications that ignore Windows proxy settings, but it adds an adapter, route, and permission layer that must be tested separately.
Is it safe to add every failing domain to fake-ip-filter?
No. A large exception list can hide the real cause and send sensitive or region-dependent requests through an unintended resolver. Add one narrow hostname at a time, reload the profile, and verify whether the change actually fixes the application. Remove exceptions that no longer serve a clear purpose.
Compared with simpler Windows VPN clients that expose one global switch but hide DNS decisions, Clash Verge Rev lets you inspect the resolver path, separate local exceptions from proxy destinations, choose Fake-IP or Redir-Host deliberately, and verify each connection in Mihomo logs. Some alternative tools are easier for a first launch but offer limited control when a browser, game, and development tool need different policies; others can install aggressive virtual adapters without making route conflicts obvious. If you want that combination of visible DNS behavior, profile-based rules, and configurable Windows traffic handling, Clash Verge Rev provides a practical foundation for the workflow described here.