When an app resolves a domain first and then connects using only its IP address, FakeDNS can maintain a domain-to-virtual-IP mapping so the connection reaches the proxy core with its domain name intact. This guide walks through DNS queries, address mapping, sniffing, and routing, then shows how to check TUN, DNS, and sniffing settings in v2rayN. If you only use a standard system proxy, it can also help you decide whether FakeDNS is necessary.
Where domain names get lost
Domain-based routing requires the destination domain to be available when the routing decision is made. When a browser sends a request through an HTTP proxy, the proxy can usually read the domain directly. In TUN mode, however, an app may use system DNS to resolve the domain to a real IP address, then connect to that IP. TUN captures the destination IP, and the original domain may not reach the core with the connection. Even if your routing rules specify domains, the core may have to fall back to IP-based rules.
FakeDNS doesn't look up the real address of a remote website. Instead, it turns a DNS query into a temporary lookup: the core returns a virtual IP to the app and records which domain that IP represents. The app connects to that address as usual; when the core receives the connection, it uses the mapping to recover the domain. Routing rules and the outbound then determine what happens next. FakeDNS is neither a proxy protocol nor a new server node.
Both parts of the traffic flow must pass through the same processing chain: the DNS query must reach FakeDNS, and the connection to the returned address must reach a core that can read the mapping. If the query uses an external system DNS server, or the connection bypasses TUN, enabling FakeDNS alone won't restore the domain. Likewise, if an app connects directly to a hard-coded IP, there's no domain for FakeDNS to save.
How virtual IPs are assigned and mapped back to domains
A commonly used IPv4 virtual address pool is 198.18.0.0/15. This range is reserved for network benchmarking; it is not a public destination address to use when accessing websites. FakeDNS selects an address from the configured pool, returns it to the requesting app, and stores the corresponding mapping inside the core. The pool range, number of available addresses, and cache behavior depend on the configuration and core implementation. A virtual IP should not be treated as a permanent identifier for a domain.
“Sniffing” doesn't only mean reading a domain from a TLS handshake or HTTP request. A core that supports FakeDNS can also restore the domain from a previously created virtual IP mapping. HTTP Host and TLS SNI are other possible sources of domain information. The protocol an app uses, whether it's encrypted, and whether it carries domain information all affect conventional sniffing—but not the basic requirement for FakeDNS: first receive a FakeDNS response, then match the mapping.
What to check: does the connection match a mapping?
Seeing a virtual IP in a DNS response doesn't prove that domain-based routing is working. Check whether the same core receives the subsequent connection and whether the destination appears as a domain in the routing logs. If it remains a virtual IP, check TUN capture and sniffing settings first.
After a core restart, a mapping may be cleared while an app continues using a cached DNS response. The app can then connect to a virtual IP whose domain mapping is no longer available. If a site stops loading right after you switch configurations but works again later, have the app issue a fresh DNS query first. If necessary, close and reopen the app rather than immediately changing the server address.
Checking TUN settings in v2rayN
In v2rayN, start with Settings → Parameter Settings. Check the active core and its TUN-related options, then review the DNS and traffic sniffing configuration. Section names and toggle locations can vary by version, so use the labels in your current interface. FakeDNS, DNS interception, TUN capture, and sniffing need to work together; enabling just one doesn't mean the entire chain is working.
DNS query path
- Where to check
- Settings → Parameter Settings
- Check these settings
- Active core, TUN, and DNS options
- Expected behavior
- The configured DNS handles app queries
- Possible cause
- Still receiving a real public IP
First confirm that the query reaches the core, then check whether the returned address belongs to the configured virtual IP pool.
Connection and routing path
- Where to check
- v2rayN core logs and routing settings
- Check these settings
- Sniffing enabled, domain rules, outbound
- Expected behavior
- The connection matches rules using the restored domain
- Possible cause
- Logs show only a virtual IP
Routing also depends on rule order. FakeDNS restores the domain; it doesn't decide which outbound to use.
For a test, choose a domain explicitly listed in a domain-based routing rule. Record the routing result before enabling the relevant features, then check the DNS response, connection capture, and rule match one at a time. Don't use “the page loads” as your only test: both a direct connection and a proxy outbound can load the same page. And don't test public-domain rules with an internal device name; they usually use different DNS paths.
A subscription provides server connection details, not your local DNS or TUN configuration. After switching to a VMess or VLESS node, you still need to check the FakeDNS query path on your device. A working node doesn't prove that domain-based routing is working as intended. To isolate the issue, keep the same node and change just one local setting at a time so the logs are easier to compare.
When to use FakeDNS—and when to keep real DNS answers
FakeDNS is particularly useful when an app resolves a domain first and TUN captures the connection afterward: the app connects to an IP, but routing rules still need the original domain. It can also reduce the chance of domain information being lost before the connection reaches the core after an app has obtained a real DNS result. But FakeDNS isn't a universal fix for DNS problems. Upstream resolution, routing rules, and app-specific DNS behavior still need to be checked separately.
| Traffic type | What to check first | Recommendation |
|---|---|---|
| Public domains accessed through TUN | Whether DNS queries and connections both reach the core | If you need domain-based routing, test the FakeDNS mapping |
| LAN devices and internal domains | Local DNS and LAN direct-connection rules | Prefer real IP addresses to avoid disrupting LAN access |
| Direct connections to IP addresses | IP-based routing rules | FakeDNS has no original domain to restore |
| Apps using their own encrypted DNS | Whether the app's DNS queries bypass the local DNS path | Check where queries enter the network first; system DNS settings alone aren't conclusive |
Be especially careful with LAN printers, router admin pages, and internal business services. They may rely on local DNS to return actual private IP addresses. If a query is changed to a virtual IP and the subsequent connection doesn't reach the core as expected, access will fail. Set up explicit local resolution and direct routes for these domains or destination ranges first, then test FakeDNS with public domains. Don't send every query to the virtual address pool.
Bottom line: decide based on the traffic path
If you mainly use a standard system proxy and your domain rules already match correctly, there's no need to change your existing DNS path just to add another DNS feature. Test FakeDNS only when you've confirmed that domains are being lost in TUN mode, and handle local resources separately.
Another possibility is that an app sends encrypted DNS queries itself or hands them to another network component. In that case, v2rayN may not see ordinary DNS queries. Even if TUN captures the subsequent connection, there may be no virtual IP mapping to look up. Start troubleshooting by finding out where the app actually sends its queries, rather than assuming that FakeDNS failed to assign an address.
Can't connect after enabling FakeDNS? Troubleshoot by symptom
Start by sorting the problem into three categories: no virtual IP, a virtual IP but no connection, or a successful connection that doesn't match the expected domain rule. These point to the DNS entry path, connection capture and mapping, or routing match, respectively. Keep the DNS result from a single test alongside the core logs from the same time period; this prevents unrelated requests from being mistaken for one another.
FakeDNS is enabled, but DNS still returns the website's real IP?
In Settings → Parameter Settings, check the active core and TUN and DNS options, then confirm that the app making the query uses this DNS path. If the query never reaches FakeDNS, changing sniffing rules won't affect the DNS response.
Got an address in the 198.18 range, but the page keeps loading?
Check whether TUN captures the subsequent TCP or UDP connection, and look for the request in the core logs. If the connection bypasses the core, the virtual IP can't be accessed like a real website address. If you recently restarted the core, have the app query DNS again.
Public websites work, but LAN devices don't?
Check local DNS and LAN direct-connection settings so internal domains and private network addresses use real DNS results. After making changes, query the device domain again and confirm that it returns the actual private IP, not an address from the virtual pool.
The domain is restored, so why is the wrong outbound still being used?
Check the routing rules and their priority order. Make sure another rule isn't matching the domain first. FakeDNS restores the domain needed for routing; the routing configuration still determines the final outbound.
If the problem occurs in just one app, compare it with a browser: do both use the same DNS entry path, pass through TUN, and connect to the same domain? A browser working normally doesn't mean every app makes the same DNS queries. If the issue appears only briefly after switching configurations, the app may have cached an old virtual IP. Have it query DNS again, then check whether the problem persists.
Check the node and protocol layer last. Whether VMess or VLESS servers in v2rayN can connect is separate from whether FakeDNS mappings work. Continue troubleshooting the node connection only if the logs show the domain rule matched and an outbound was selected, yet the request still times out. Narrow things down layer by layer—DNS, sniffing, routing, then outbound—instead of changing your subscription, routing, and DNS settings all at once.