Clash Verge Rev Fake-IP DNS on Windows: Setup and Testing

1. What Fake-IP DNS Changes—and What It Does Not

Fake-IP is a DNS response strategy used by Clash-compatible cores such as mihomo. Instead of returning a website’s real public IP address to an application, the core returns an address from a reserved synthetic range. When the application connects to that address, the core can associate the connection with the original domain, apply domain-based routing rules, and then connect to the appropriate destination.

This can help when a connection needs to be routed by domain, including cases where an application resolves a hostname before the proxy core sees its traffic. It can also reduce repeated DNS lookups by keeping a mapping between a domain and its synthetic address. Fake-IP does not make a proxy server faster, encrypt DNS by itself, or guarantee that every Windows application uses Clash. Traffic still needs to reach the core through the system proxy, TUN, or another supported path.

Keep three parts separate when troubleshooting: the DNS settings in the active configuration, the way Windows or an application sends traffic to Clash, and the outbound rule or proxy group selected for that traffic. A successful DNS answer does not prove that the selected proxy node is reachable; a working browser proxy does not prove that all Windows DNS requests use Clash DNS.

2. Check the Active Profile and Back Up Its Current DNS Settings

Clash Verge Rev is the graphical client; the core attached to the active profile processes DNS and proxy connections. A DNS section in an inactive profile has no effect on current traffic. Before editing anything, confirm which profile is selected, whether it loads without errors, and which core is running. Menu labels can vary between Clash Verge Rev releases, so use the profile or configuration controls shown in your installed version rather than relying on a particular button name.

1. Open Clash Verge Rev and select the profile you currently use. Confirm that it is active, not merely present in the profile list.
2. Record the client version and core name and version if the interface displays them. Fake-IP support and accepted configuration fields depend on the core, not just on the client’s name.
3. Save a copy of the current configuration or make a copy of the local profile before changing it. Keep the backup somewhere outside a generated or temporary profile directory if subscription updates may replace that file.
4. Note the current DNS mode, listener address and port, fake-IP range, and any existing fake-IP filters. Also note whether TUN is enabled and whether Windows system proxy is enabled.
5. Check that no second proxy client or VPN is changing Windows proxy or DNS settings during the test. Close other clients temporarily if you cannot tell which one owns those settings.

Prefer the profile’s supported override, merge, or configuration-editing feature when available. A subscription-generated profile may be rebuilt on refresh, so direct edits to generated content can disappear. If you use an override, verify how the client merges duplicate YAML keys: YAML does not safely combine two separate top-level dns: blocks. Keep one effective DNS section, and make sure the active configuration—not only the text you edited—contains the intended values.

3. Add a Minimal Fake-IP DNS Configuration

For a controlled first test, use a single DNS block and a listener bound to the local computer. The following example uses port 1053; it enables Fake-IP for IPv4 and supplies encrypted DNS resolvers as upstream name servers. It is a configuration fragment, not a complete Clash profile. Merge it into the active configuration using the client’s supported method instead of replacing the entire profile.

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
    - 1.1.1.1
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://cloudflare-dns.com/dns-query
  fake-ip-filter:
    - "*.lan"
    - "*.local"

The two upstream URLs are examples, not mandatory choices. Select resolvers you trust and can reach from your network. In mihomo-style configurations, default-nameserver provides DNS resolution for the hostnames of DNS servers that need to be resolved; nameserver lists upstream resolvers for ordinary DNS queries. A resolver’s availability and behavior can differ by network, so a timeout from one upstream does not automatically mean Fake-IP itself is broken.

• enable: true: Enables the core’s DNS module. Confirm that the active core accepts the fields in your configuration.
• listen: 127.0.0.1:1053: Opens a local DNS listener on loopback. Port 1053 is chosen to avoid assuming that port 53 is available on Windows.
• ipv6: false: Keeps this initial test focused on IPv4. If your network and profile are configured for IPv6, review that behavior separately rather than drawing conclusions from an IPv4-only test.
• fake-ip-range: 198.18.0.1/16: Selects a synthetic address range. Do not use this range as a real destination address or add rules that treat it as an ordinary public website address.
• fake-ip-filter: Lists names that should not receive Fake-IP responses. The example covers common local suffixes; add entries only when a specific local device or application needs real DNS answers.

Before applying the change, inspect the full YAML around the edited area. Check indentation, colons, list markers, and duplicate keys. A malformed configuration may fail to load, while an override that is valid but merged in an unexpected way may leave the original DNS settings in control. After saving, reload or reapply the profile as required by the client, then check the core or configuration log for parse errors. Do not proceed to testing if the profile failed to load.

4. Apply the Change and Test It from Windows

Use one fresh query and one fresh application connection so that cached DNS answers or existing connections do not confuse the result. If your client exposes a DNS log or core log, keep it open during the test. A query result, an entry in the core, and a connection’s selected rule together provide stronger evidence than any one indicator alone.

1. Start or reload the active profile. Confirm that Clash Verge Rev reports the profile as running and that the core log contains no DNS configuration or YAML parsing error.
2. Keep TUN off for this first pass if you are testing system-proxy behavior. Enable the Windows system proxy in the client, then use a browser or another application known to honor Windows proxy settings.
3. If the core DNS listener is 127.0.0.1:1053 and you have dig installed, query that listener directly from PowerShell. Replace example.com with a domain you are permitted to test:

dig @127.0.0.1 -p 1053 example.com A

For an eligible A-record query, a response in 198.18.0.0/16 is consistent with the example Fake-IP range. If dig is unavailable, do not assume that nslookup can query port 1053: standard Windows nslookup usage does not provide a simple, portable port option for this purpose. You can instead use a DNS query tool that supports a custom server port, or temporarily configure a local listener on port 53 only if it is available and you understand how Windows DNS settings will use it.

4. Check the DNS or core log for the queried hostname and a successful response. Then open a new browser session or a private window and visit the test domain. A cached browser connection may not generate a new lookup, so a fresh hostname or a fully closed and reopened application can make the test clearer.
5. Check the connection entry for the new request. Confirm that it shows the expected domain when available, the rule that matched, and the selected outbound policy. The rule and policy describe routing; they are separate from the synthetic DNS answer.
6. Compare with the Windows proxy turned off only if necessary, and then restore it immediately. A change in browser behavior can help isolate proxy capture, but it does not by itself demonstrate that every Windows app uses the core’s DNS listener.

If the query returns a normal public address, verify that you queried the listener and port actually configured in the active profile. Also check whether the hostname is covered by fake-ip-filter, whether a different DNS block overrides the example, and whether the running core is the one attached to the profile you edited. A public answer may be intentional for filtered domains or for queries that did not reach the Fake-IP DNS module.

5. Troubleshoot Failed Lookups and Unexpected Results

Start with the exact failure rather than changing several settings at once. A timeout, a malformed profile, a normal public answer, and a successful DNS response followed by a failed website connection point to different causes.

When an upstream DoH server is specified by hostname, the core needs a working way to resolve that server’s hostname. That is one reason to keep default-nameserver valid and reachable. If the network blocks a resolver, try another trusted resolver rather than adding multiple unrelated settings without checking which server answers the query.

If Windows applications behave differently, identify how each one sends traffic. A browser may honor the Windows system proxy, while a command-line tool or game may use its own proxy setting or connect directly. TUN can capture traffic that does not use an HTTP proxy, but it introduces additional factors such as virtual adapter permissions, route exclusions, and conflicts with other VPNs. First confirm that the DNS listener test works; then test system proxy or TUN as a separate step.

Do not diagnose a routing problem from the address alone. A synthetic address is not the site’s real destination, and an application may connect through the core while the core uses the original domain for matching. Review the core’s connection details and the rule that matched. If DNS succeeds but a proxy group has no usable node, the connection can still fail after resolution.

6. Restore, Verify, and Keep the Configuration Maintainable

If Fake-IP causes problems, revert the smallest change first. Disable the added DNS override or restore the backup, reload the same profile, and confirm that the previous DNS behavior returns. If you also changed TUN, system proxy, DNS filters, or routing rules, restore those changes one at a time. This preserves a clear path to finding the setting responsible.

1. Restore the previous DNS section or remove the override through the client’s supported profile controls.
2. Reload the active profile and confirm that it parses successfully. Check that the intended profile is still selected.
3. Restore the original Windows system proxy and TUN state. Avoid leaving a second client or VPN configured to overwrite those settings.
4. Repeat a DNS query using the same test method as before, then test a fresh application connection. Compare the result with the notes you made before editing.
5. Keep the backup only if you need it, and store it securely if it contains subscription URLs, server details, or credentials.

For an ongoing setup, keep the DNS configuration in one clearly managed place, document why each filter exists, and retest after changing the core or refreshing a profile. A subscription update may replace generated content or alter merge behavior. After an update, verify that the active profile still contains the intended DNS settings and that the core loads them; do not rely on an old test result to confirm a new configuration.

The most reliable confirmation uses several independent checks: the active profile loads, the local DNS listener answers, an eligible query returns an address from the configured synthetic range, and a fresh application connection appears in the core with the expected rule and outbound policy. If one check fails, troubleshoot that layer before adding more configuration.