V2Ray Advanced Setup

Routing Rules & Match Order

Routing rules determine which outbound handles a connection that has already reached the core. They do not make an app use the proxy automatically, nor can they fix an unavailable server. Before working with routes, distinguish the entry point, match criteria, and outbound: the entry receives connections, criteria check domains, destination IPs, or ports, and the outbound connects directly, through a proxy, or blocks traffic. If an app never reaches the entry point, even a complete set of rules has no effect.

Check the Tags in the Generated Configuration

v2rayN and v2rayNG provide routing settings for editing rules and presets through a graphical interface. Before editing, check the active configuration or runtime logs to confirm the actual tags for proxy, direct, and block outbounds. The example assumes outbounds tagged proxy, direct, and block. These are readable labels, not proof that your client uses those exact tags.

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "domain": ["full:blocked.example"],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "domain": ["domain:example.com", "geosite:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": ["geoip:private", "geoip:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

This routing snippet illustrates rule order; it is not a complete client configuration. Replace the example domains with domains used by your services, and make sure the referenced rule sets are available. Rules are checked from top to bottom, and the first match determines the route. The final catch-all rule handles all remaining TCP and UDP traffic, so it must not precede specific rules; otherwise, later domain and IP conditions will never be checked.

Know the Limits of Domain and IP Conditions

full: matches an exact domain; domain: matches a domain and its subdomains; geosite: references a domain set; and geoip: references an IP set. When a rule includes both a domain and a port, a connection usually has to match both conditions—not either one. To route “this domain or this IP” directly, create two separate rules.

domainStrategy controls whether the routing stage resolves domains for matching. AsIs uses the original destination where possible; IPIfNonMatch attempts resolution and then checks IP rules if no domain rule matches; IPOnDemand may trigger resolution when a rule requires an IP check. This is not a DNS server list, and it does not guarantee that the core will handle lookups performed directly by an app.

When a domain resolves to a shared service IP, IP-based classification alone may send different services through the same outbound. For services that need precise routing, use specific domain rules and place them before broader rules. Software may depend on multiple domains for sign-in, images, verification, and updates, so adding only the main site may not be enough. Use connection logs to identify dependencies instead of routing all traffic through a broader rule.

Sniffing & LAN Rules

Enable traffic sniffing to try to recover domain information from supported connection content and route by domain. It cannot identify every protocol or decrypt encrypted content. A connection made only to an IP address may not yield a domain. If an app behaves unexpectedly after sniffing is enabled, check how sniffing overrides the destination, then revert that setting on its own. Changing DNS and routing at the same time makes the cause harder to identify.

Direct LAN access usually requires private IP rules, and may also depend on the client’s Bypass LAN setting, system routes, and TUN exclusions. A direct rule in the core does not guarantee that all LAN traffic bypasses the virtual interface. Do not route private address ranges through a remote server without a specific reason. Configure enterprise network domains and addresses to match the actual network plan, especially when remote and local private ranges overlap.

For verification, keep the same server selected and test an exact domain, a categorized domain, and an unmatched destination in turn. Check the outbound tag in the logs. If edits have no effect, confirm that the modified routing profile is active and whether the connection needs to be restarted. If a category data set is missing, fix the loading error rather than blindly adding a broader direct rule. For basic concepts, see the Help Center.

FakeDNS & Virtual Address Mapping

FakeDNS does not return the destination server’s real address to the app. Instead, it assigns an internal virtual address and stores a mapping to the domain. When the app connects to that address, the traffic-capture component must recover the domain and apply routing and outbound rules. The point is to preserve domain information, not to make the virtual address reachable on an ordinary network. Outside the mapping environment, the address usually has no meaning as a destination.

Meet All Traffic-Capture Requirements

For FakeDNS to work, DNS queries must enter its processing path, and connections to the virtual addresses must be captured by the same traffic-handling setup. If only one part works, resolution may succeed while connections fail. A browser using encrypted DNS on its own may bypass FakeDNS. An app with a cached address may keep using a real IP, making behavior appear inconsistent across the same device.

In v2rayNG, check Enable FakeDNS alongside VPN mode, DNS settings, and sniffing options. A graphical toggle may generate several core settings, so comparing one boolean value is not enough. v2rayN’s TUN DNS may use a similar mechanism in its traffic-capture component, but its configuration fields and state may differ from those in the Xray core. Do not paste a snippet from one client into another without checking compatibility.

v2flyNG uses the v2fly core, so confirm supported features in the current interface and by checking whether the configuration parses. If you encounter an unknown field, use the configuration structure supported by that core rather than dismissing the warning and continuing. The client, interface toggle, and core configuration are separate layers. A feature with the same name does not guarantee compatible fields, especially when moving DNS settings between clients.

How the Mapping Pool and Sniffing Work Together

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

This shows only a mapping-pool snippet from an Xray configuration that supports this structure; it is not a complete FakeDNS setup. DNS must also use FakeDNS, the relevant inbound must recover the domain, and the virtual address range must be captured. ipPool sets the allocation range, while poolSize sets the mapping capacity; neither represents the number of servers or network performance. Prefer a compatible configuration generated by the client. Do not add this snippet alone and start testing.

The mapping range must not overlap with your current network or other virtual networks. Corporate lab networks and other tunnel tools may already use the same range, so plan around any conflicts. Do not add the virtual address pool to the traffic-capture bypass list, or app connections will go directly onto the ordinary network. Do not treat the range as a real destination in a remote direct-routing policy either; the mapping must be resolved at the correct local processing layer.

Traffic sniffing and FakeDNS can work together, but they do different things. Standard sniffing tries to recover a domain from connection content; FakeDNS recovery relies on an existing mapping. If that mapping is gone when a connection arrives, ordinary sniffing may not be enough to recover the domain. A client restart, an evicted mapping, or out-of-sync components can leave an app holding a virtual address with no corresponding domain.

When to Use FakeDNS & How to Recover

FakeDNS may be worth testing after the basic connection works if you need reliable domain-based routing and the entry point usually sees only IP addresses. Apps that connect to fixed IPs, discover LAN devices, or validate DNS results may not work well with it. For those apps, consider explicit traffic-capture exclusions or ordinary DNS instead of changing more global settings without a specific reason.

After enabling FakeDNS, test a regular web page, then sign-in, media, and background services. If only some apps fail, note whether they use their own encrypted DNS, connect to fixed IPs, or were already running when FakeDNS was enabled. Fully close the app and retry. If the issue persists, disable FakeDNS without changing anything else and test the same destination to determine whether address mapping is the cause.

When reporting a problem, share only the domain, traffic-capture mode, and outbound tag; there is no need to publish your full configuration. If disabling FakeDNS fixes the issue and enabling it brings it back reliably, check DNS capture, address-pool routing, and mapping recovery. If both modes fail, return to server connectivity and ordinary DNS rather than adjusting unrelated FakeDNS settings.

Verify Configuration & Recover One Layer at a Time

The goal of verifying advanced settings is not to see whether a page loads once. You should be able to explain where a request enters, how its domain is resolved, which rule it matches, and which outbound handles it. Establish a minimal working baseline, then add subscription filters, routing, TUN, and FakeDNS one at a time. Keep a recoverable state at every step so you can narrow down problems instead of reinstalling the client.

Use a Consistent Test Set

A baseline should include one verified server, ordinary DNS, a simple routing rule, and a clearly defined traffic entry method. Choose a fully qualified domain you use regularly, a LAN resource, and a service that requires the proxy as fixed test cases. Keep the device network and server unchanged during testing. If you switch Wi-Fi while changing resolvers, you cannot tell which change affected the result.

Before each change, note the original value, what you plan to change, and the expected result. For example, after adding an exact-domain direct rule, expect the outbound tag in the logs to change—not just a vague improvement in “stability.” Save, restart the connection, close the test app’s existing connections, and try again. For subscriptions, first verify that entries are generated; for TUN, check the interface and routes; for FakeDNS, confirm that virtual addresses can be resolved back to domains.

Use Logs to Identify the Failing Stage

Configuration parsing errors usually occur at startup and involve fields, syntax, or tags. Listener failures often involve port conflicts or permissions. Timeouts after a connection attempt begins require checking the network and remote endpoint. Find the first error rather than copying repeated connection failures that follow it. If an earlier layer has not succeeded, later errors may only be symptoms; changing a later layer will not fix the cause.

Temporarily increasing log detail can help identify the destination and outbound, but do not leave verbose logging enabled. Logs may contain domains, addresses, and activity. Redact them before sharing. Check screenshots for subscription URLs, connection credentials, and full share links as well. After troubleshooting, restore your usual log level and remove temporary files you no longer need so sensitive configuration is not left in your Downloads folder or shared directories.

A single service may open several connections. If the main page loads but sign-in fails, a dependency domain may be following a different rule. Image failures may involve a resource domain, DNS result, or address family. Add and verify rules for the failed request instead of routing all traffic the same way after seeing one problem. If needed, briefly test a simpler routing setup for comparison, then restore your original policy.

Roll Back Changes in Reverse Order

If problems began after several changes, first undo the most recent one: disable the newly added FakeDNS, restore ordinary DNS, remove new routing rules, and finally disable TUN or VPN capture to return to the original entry method. Test the same cases after each rollback. Do not clear groups, delete servers, and reset system networking all at once; even if service returns, you will not know what caused the original issue.

If the network remains unavailable after stopping the client, check for leftover system proxy settings, virtual routes that were not restored, and other network tools that are still running. Do not immediately delete unknown interfaces or change system routes in bulk. Preserve the current state and identify what each item belongs to first. If only a browser is affected, check its own proxy and encrypted DNS settings. If only one app fails, check per-app capture and its network options.

To retrace the setup, return to the Quick Start Guide and repeat the import, mode, connection, and verification steps. For a specific symptom, use the Help Center. Choose an installation package on the Downloads page. The snippets in this guide explain individual configuration layers; they are not complete configurations. Before using one in your environment, check the client, core, and generated configuration structure.