V2Ray FakeDNS Explained: How Fake IP Mapping Works and When to Use It

What Is FakeDNS? It Returns a Mapped Address, Not the Website’s Real IP

A standard DNS lookup usually resolves a domain to the server’s real IP address. FakeDNS instead assigns an address used only to identify traffic within the current proxy setup. For example, when an app looks up example.com, FakeDNS might return 198.18.0.1 and store the domain-to-IP mapping in memory. This address is not the website’s server and should not be sent directly over the public internet.

The app then connects to the synthetic IP. When the proxy receives the connection, it looks up the original domain in the mapping table and applies domain-based rules to decide whether to connect directly or use a proxy. How the real IP is ultimately obtained depends on the outbound type and DNS strategy: the local direct outbound may resolve it, or the domain may be passed to the remote proxy. FakeDNS does not remove the need to reach the real server.

A common example uses 198.18.0.0/15, a special-purpose address range from 198.18.0.0 through 198.19.255.255. It was reserved for network device benchmarking, not as a publicly routable range or a typical private LAN subnet. Before using it as a synthetic address pool, make sure it isn’t already in use on your corporate or test network.

FakeDNS, Sniffing, and TUN: What Each One Does

These three features often appear together in configuration menus, but they serve different purposes. FakeDNS maintains the domain-to-address mapping. TUN uses a virtual network interface to send matching IP traffic to the client. Sniffing or inbound destination recovery extracts a target from the connection for routing and outbound handling. Enabling just one of these options does not guarantee that the full traffic flow will work.

HTTP Host and TLS SNI sniffing are not the same as restoring a FakeDNS mapping. The first two attempt to identify a domain from protocol data, which depends on the protocol, encryption, and app behavior. FakeDNS recovery primarily relies on a mapping saved earlier. A mapping may be unavailable if an app connects directly to a real IP, resolves the address outside the client, or reuses a synthetic IP left over from a previous session.

When to Use FakeDNS: Check Your Domain Rules and Interception Setup

FakeDNS may be useful when a transparent proxy receives connections by IP, but your routing rules need the original domain. It reduces the uncertainty of resolving a real IP first and then trying to determine which domain it belongs to. It can also let some requests proceed without waiting for a real DNS answer from the local network. It won’t make downloads faster or change server bandwidth or network congestion.

• Worth trying: TUN is already running reliably, you need domain-based routing, and the client can handle DNS queries, synthetic IP routing, and destination recovery.
• Usually unnecessary: You only use a system proxy, and apps already pass domains to the proxy through HTTP CONNECT or domain-based SOCKS requests, so your existing rules match correctly.
• Keep real DNS resolution: For corporate networks, LAN device discovery, software that uses real IPs for access control, and network diagnostics that need to show actual DNS results.
• Wait before enabling: Another VPN or transparent proxy is running, and you haven’t confirmed which one controls DNS, the default route, and the synthetic address range.

Also check browser Secure DNS and app-level DoH. Intercepting standard UDP port 53 queries doesn’t mean HTTPS-based DNS requests will go through FakeDNS too. Blocking port 443 would break regular web access, so it isn’t a general solution. Check the app’s DNS settings and decide whether it or the client should handle resolution.

Configuration Fields: Coordinate the Address Pool, DNS, and Inbound Recovery

v2rayN is a desktop client; v2rayNG is an Android client that uses the Xray core; and v2flyNG uses the v2fly core. Each client can generate or load core configuration, but their menus, available options, and generated output differ. Don’t assume a screenshot of one client shows the steps for every version. Check the configuration and logs for the core that’s actually running.

This JSON snippet illustrates how the fields relate in a common V2Ray-style IPv4 FakeDNS configuration. It omits inbounds, outbounds, routing, and real DNS, so it isn’t a complete configuration you can apply directly to a client. Behavior and supported fields may vary between Xray and v2fly versions; check the core you’re running before saving changes.

{
  "fakedns": [
    {
      "ipPool": "198.18.0.0/15",
      "poolSize": 65535
    }
  ],
  "dns": {
    "servers": [
      "fakedns"
    ]
  }
}

A common sniffing snippet for an inbound that restores connections to synthetic addresses looks like this. Here, fakedns is a destination recovery type; it doesn’t enable every HTTP and TLS sniffing feature. Don’t copy option names from other versions just to make the configuration look complete.

{
  "sniffing": {
    "enabled": true,
    "destOverride": [
      "fakedns"
    ]
  }
}

Verify FakeDNS: Check DNS, Mapping, and Routing

The goal isn’t just to see an “enabled” switch. A single visit should produce sensible results from the domain lookup through to the final outbound. First note your proxy mode, DNS settings, and core type, then change one group of settings at a time. Server addresses, ports, and user IDs in your subscription aren’t FakeDNS pool settings and don’t need to change for testing.

1. Establish a baseline. With FakeDNS off, make sure the target website works on the same network. Note whether you’re using a system proxy or TUN, and save a copy of the current configuration.
2. Check the DNS path. After enabling FakeDNS, visit a domain that triggers a fresh lookup and check that the DNS logs show the expected handling. If the query is configured to use FakeDNS, the answer should fall within the configured pool.
3. Check traffic redirection. Review connection or core logs to confirm that a connection to the synthetic IP reaches the proxy and that the domain is restored at a visible logging stage. Different log levels show different details; a single line containing an IP doesn’t prove that recovery failed.
4. Check routing. Test one domain expected to connect directly and another expected to use the proxy, then verify the actual outbounds. Checking whether a webpage loads doesn’t confirm that the right rules matched.
5. Check compatibility. Test LAN services, in-app sign-in, and background connections. If IPv6 is enabled, check AAAA queries too; testing only A records doesn’t verify that all traffic is being intercepted.

On Windows, run ipconfig /flushdns to clear the system DNS cache. Browsers and other apps may keep their own caches and connections, so close and reopen them. On Android, stop the client connection, then restart the app you’re testing. Don’t keep changing networks, servers, protocols, and DNS settings all at once; doing so makes the results hard to compare.

Common Issues: Latency, DNS Results, and Failures After Restart

Disable and Restore: Turn Off DNS Allocation and Traffic Interception Together

Avoid leaving things in an in-between state where DNS still returns synthetic IPs but the inbound or TUN responsible for restoring them has stopped. A safer approach is to pause test apps, restore the DNS and proxy settings that worked together, restart the connection, and clear stale caches. If the client provides an integrated FakeDNS mode, turn it off through the same control instead of manually deleting a single line from the core configuration.

• Restore DNS: Confirm that new queries return the expected real DNS results and that the system isn’t still pointing to an unreachable local DNS server.
• Restore routing: Make sure the client has removed any no-longer-needed routes for the synthetic address pool, virtual interfaces, and interception rules.
• Reconnect apps: Close existing connections, look up the domains again, then check websites, LAN services, and background connections.
• Keep troubleshooting notes: Record where the issue occurs and whether it affects just one app. Remove sensitive information such as subscription addresses and user IDs before sharing logs.

FakeDNS is useful for bringing domain information back into routing decisions in a transparent proxy setup. If your system proxy is already working reliably, keeping things simple is usually easier to maintain. For TUN setups that need domain-based routing, focus on making sure DNS, mappings, inbounds, and outbounds work together. For more basics, see DNS settings in the complete guide. Confirm that standard DNS resolution works before adding synthetic addresses.