V2Ray Advanced Setup Guide

Subscription groups and server filters

The main purpose of subscription groups is to keep sources separate, not to change connection protocols. Create a separate group for each source so you can control its update scope, entry ownership, and disablement independently. In v2rayN, add a name and URL through the subscription-group settings. In v2rayNG and v2flyNG, manage sources in the subscription settings. Menu labels vary by client, but the process is the same: add a source, update it, then check what was imported.

Group by source, then choose what to show

Name groups by purpose, such as “Daily,” “Backup,” or “Manual.” Do not include credentials, full subscription URLs, or billing details in group names. Keep sources separate even when they provide similar entries. If one source stops updating, you can disable its group without sorting through a mixed list. Store manual entries in a separate group to keep them apart from subscription entries.

Keep the full query string when entering a subscription URL. Some subscriptions use a token in the URL to identify your account, and removing anything after the question mark can break updates. If you import a URL from a QR code or clipboard, check for leading or trailing spaces, line breaks, and full-width punctuation. Do not submit URLs containing credentials to public conversion services. Prefer a trusted local method for format conversion; see the subscription URL format guide for details.

Know when filtering takes effect

“Search,” “display filter,” and “import filter” are not the same. Search usually changes only what appears in the list; it does not delete servers. An import filter may prevent non-matching entries from being added to the group. Deletion changes the local set of entries. Before adjusting a filter, read its description and check whether it affects the next subscription update. If you are unsure, use list search rather than entering a complex expression in the subscription settings.

If your client supports regular expressions, use simple, well-scoped rules to filter names. Test on a small number of entries before applying a rule to an entire source. Providers control subscription names, which may include prefixes, spaces, or multiple languages, so a name match does not establish geographic location. If filtering returns no results, remove the filter and update again to confirm the source contains entries. Then check case sensitivity, separators, and regex syntax.

^(Daily|Backup)-
^(?!.*Test).*$

These are two independent regex examples. The first matches names beginning with “Daily-” or “Backup-”; the second excludes entries whose names contain “Test.” Use them only in fields explicitly marked as supporting regular expressions; a standard search box may not interpret these symbols. Name filters are for organizing lists, not proving protocol compatibility, service availability, or the route a connection will take.

Check entry changes after updating

After updating a specific group, check that protocol, address, port, and transport settings were parsed correctly. A change in entry count may result from updates at the source, filtering rules, or differences in format recognition; it does not necessarily mean the client lost configuration. If the entire group disappears or is empty, check the update response and parsing errors first, then restore the previous filter settings. Repeatedly clicking Update will not fix an incompatible format and may trigger rate limits at the source.

Do not rely on manually renaming subscription entries or changing their transport settings as a permanent fix. The next update may overwrite those changes or recreate the entry. If a temporary adjustment is necessary, copy the entry into a manual group, label its purpose, and record how it differs from the original. Leave the subscription entry unchanged so you can tell whether the issue comes from the source data or your local changes.

Switching groups does not necessarily switch the server currently in use. After an update, confirm the selected entry again, especially if the previous one was removed or recreated. On mobile, check whether the service needs a restart to load changes. Trust the active destination and outbound in the startup log rather than the list highlight alone. Once the list is organized, move on to routing so source management issues are not mistaken for routing problems.

DNS setup and resolution paths

Break DNS issues into three questions: who makes the query, who handles it, and which route the query takes to reach its upstream resolver. The browser, operating system, proxy core, and TUN component may all handle DNS. Changing the DNS address in the client does not mean every app immediately uses it; app-level encrypted DNS, system caches, and existing connections can all affect what you observe.

Define what the built-in DNS does

A proxy core's built-in DNS is generally used for internal domain resolution, routing decisions, or specific outbound behavior. It does not necessarily become the system's default resolver. With a system proxy, some apps resolve domains through the system first and send the resulting IP to the proxy; others pass the domain to the proxy entry point. These paths behave differently. Taking over system DNS queries usually requires DNS interception through TUN or corresponding system settings.

v2rayN may expose separate DNS settings for different cores. In v2rayNG, interpret remote DNS, local DNS, and related routing options in the context of the current mode; do not assume that “remote” means traffic must use the proxy. Keep the client's default setup initially, verify that a standard connection works, then adjust upstream resolvers and domain routing. Before replacing the DNS configuration, note the purpose of existing rules and fallback resolvers.

{
  "dns": {
    "servers": [
      {
        "address": "223.5.5.5",
        "domains": ["geosite:cn"],
        "skipFallback": true
      },
      "1.1.1.1"
    ],
    "queryStrategy": "UseIP"
  }
}

This Xray-style DNS snippet shows domain-based resolver selection and a fallback resolver; it is not guaranteed to suit every network. domains selects a server for the specified domains, while skipFallback prevents that server from handling normal fallback queries for other domains. It does not mean the selected domains can never be tried against another server; the full fallback behavior depends on other options too. Verify upstream reachability and routing in the active configuration.

Encrypted DNS and bootstrap resolution

When an encrypted DNS service is addressed by domain name, the client must resolve that name before it can establish the encrypted connection. This is the bootstrap resolution problem. If bootstrap resolution depends on the same service that has not connected yet, the process loops. Use a known-reachable bootstrap path or a static mapping supported by your core. Simply replacing a regular DNS address with an encrypted one does not guarantee the resolution path is complete.

The proxy server's domain name is part of this chain too. If the server address can only be resolved through the proxy, but the proxy must connect to that server first, startup will stall on the initial lookup. Check whether the server domain resolves before the service starts, then check whether upstream traffic is mistakenly routed back to itself. Encrypted DNS protects queries in transit; it does not fix routing, server certificates, or an incorrect system clock.

IPv4, IPv6, and cache effects

UseIP allows results of both address types; it does not guarantee working IPv6 connectivity on your system. If the network returns an IPv6 address but the route is unavailable, an app may wait for the connection to fail before falling back, making the first load slow. Compare the actual IPv4 and IPv6 paths before choosing an IPv4-only query strategy. Disabling one query type also cannot override apps that resolve names themselves or connect directly to IP addresses.

System lookup tools show results from the system resolver, but do not necessarily prove that the proxy core's built-in DNS is working. Check client logs and app connection records as well. After making a change, account for system, browser, and core caches. Clearing or restarting them one at a time is more informative than repeatedly changing upstream resolvers. A successful visit while a cache is still valid does not prove the new resolver handled the query.

If a domain resolves but cannot be reached, check whether the returned address matches the routing outbound instead of continuing to troubleshoot DNS. If only short LAN names fail, check the search domain and whether local DNS is being intercepted. Internal business domains, printer names, and home network devices may depend on local DNS. Set explicit local-resolution exceptions rather than sending everything to a public resolver.

FakeDNS and domain mapping

FakeDNS assigns a synthetic IP to a queried domain and keeps an internal mapping between the name and address. When the app connects to that address, the interception component can recover the original domain for routing or pass it to the proxy outbound for resolution. A synthetic address is not the destination server's real IP or a new remote server. FakeDNS preserves domain context when an app might otherwise resolve a name to a real IP and lose that information.

A complete mapping path is required

FakeDNS requires at least three parts to work together: queries must reach the designated resolver, connections to synthetic addresses must be captured by the same interception path, and the domain must be recoverable when the connection is handled. Adding a name to the DNS server list without intercepting the corresponding traffic may cause the app to send the synthetic IP through the normal gateway. Conversely, sniffing alone does not route system DNS queries to FakeDNS.

First identify which component handles synthetic addresses. The TUN component in v2rayN may already provide its own fake-IP feature, so do not add Xray FakeDNS on top without checking. Each component may assign addresses and maintain its own cache; domain recovery can fail if the mapping is missing. The settings and supported features in v2rayNG and v2flyNG also vary. Check the current client and core instead of assuming similar names mean identical implementations.

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

This is an Xray-style feature snippet, not a complete DNS interception setup. The address pool uses a reserved test range, but that does not mean it is conflict-free in your environment. If your LAN, corporate network, or another virtual interface already uses the range, choose a different setup first. Pool size determines mapping capacity, not the concurrent connection limit. Increasing it cannot fix missing query interception or domain recovery.

Inbound recovery and sniffing limitations

When Xray directly handles the relevant traffic, the inbound must also enable the recovery mechanism that works with FakeDNS. Configure the inbound that receives connections to synthetic addresses, not an arbitrary listening entry. The snippet below shows a common sniffing setup and must be adapted to the actual inbound structure. If an interception component already restores the domain upstream, follow that component's configuration instead.

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

Standard HTTP or TLS sniffing and FakeDNS mappings come from different sources. Sniffing attempts to obtain a domain from the app protocol; FakeDNS relies on a previous DNS query record. Some protocols, encrypted handshakes, and direct IP requests do not provide a usable domain. Sniffing cannot be relied on to recover every destination name. Check the current core's options to determine whether sniffing affects routing only or also replaces the connection target.

Cache, switching, and compatibility

After enabling FakeDNS, query a domain that is not cached. Confirm that the app receives a synthetic address, then check whether the connection recovers the domain. After stopping the service or switching interception components, an app may retain an old synthetic IP that the new service cannot map, making some sites suddenly unreachable. Clear the relevant DNS cache and restart the app rather than enlarging the address pool or repeatedly switching remote servers.

LAN service discovery, apps that check resolved addresses, and diagnostic tools that rely on real IPs may not work well with synthetic addresses. Add explicit real-resolution exceptions for these destinations and verify that they cover both DNS and the connection path. A browser's built-in encrypted DNS may also bypass the interception resolver, causing different requests in the same app to take different paths. Record that setting during troubleshooting.

If FakeDNS provides no clear benefit, a standard DNS setup is easier to maintain. To roll back, stop interception, restore DNS settings, clear caches, restart the app, then test direct and proxied destinations. Do not just remove the FakeDNS fields while the system continues to use stale synthetic addresses. Restore both the configuration and caches to get a reliable comparison.

Custom outbounds and configuration rollback

An outbound determines how a connection leaves the proxy core, and routing rules reference it by tag. Common uses include direct, proxy, and block paths, or connecting to another proxy entry already running on the local machine. Custom outbounds are for specific routing needs, not a replacement for importing a standard server. Before you start, know which service each tag refers to, where it listens, and what happens if that service stops.

Tags link configuration components

tag is a user-defined identifier; it does not create protocol capabilities. If a routing rule refers to proxy, the configuration must contain an outbound with that exact name. Similar names are not interchangeable. In native Xray configurations, the first outbound usually handles traffic that matches no rule, so outbound order matters. Client-generated configurations may add their own default rules; check the active configuration structure rather than just a partial snippet in the editor.

This complete Xray-style configuration can be used to test a local connection path: a local app connects to a SOCKS inbound, regular destinations are forwarded to another local SOCKS service, and private addresses connect directly. It contains no remote server credentials and assumes that the referenced upstream service is listening on the specified port. Do not route the upstream service back to the current inbound, or forwarding will loop.

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "local-in",
      "listen": "127.0.0.1",
      "port": 10810,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": false
      }
    }
  ],
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "socks",
      "settings": {
        "servers": [
          {
            "address": "127.0.0.1",
            "port": 10809
          }
        ]
      }
    },
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ],
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

Check protocols and ports before rules

Before using this, confirm that 10810 is available and that 10809 provides a SOCKS service. Do not enter an HTTP proxy port as a SOCKS outbound just because both are called proxy ports. These are example test ports, not client defaults. The listening address is limited to the local loopback interface to avoid exposing an unauthenticated entry point to the LAN. For remote access, design authentication, firewall rules, and access scope separately.

This example disables UDP on the inbound and is intended for TCP path testing only. It does not mean the same setup can support every UDP app. To add UDP, check support in the inbound, upstream SOCKS service, and the rest of the connection path. A direct or block outbound is only a definition; it is used only when a routing rule selects it or it becomes the default. Adding an outbound named block does not automatically block any destination.

Limits when integrating custom configurations

When using a custom configuration in v2rayN, select a core that matches the file syntax and check how the client identifies the local listening port. Some management options may no longer modify the file, while system proxy settings may still point to an old port. Mobile import capabilities differ from desktop, so use a configuration type supported by the current client. Being able to save a file does not mean the service will start as expected.

Chaining multiple proxies adds dependencies and makes troubleshooting harder. Verify the upstream and downstream separately before connecting them, and check whether either layer intercepts the other's outbound traffic. If you only need different routes for a few domains, use clear routing rules and separate outbounds rather than adding unnecessary proxy layers. For protocol comparisons, see common protocol differences; actual capabilities still depend on the connection path.

Roll back in reverse order

If startup fails, read the first clear error and address the specific cause: JSON syntax, an unknown field, a port conflict, or a missing outbound reference. If startup succeeds but connections fail, check whether the upstream is listening, the protocols match, and the default outbound is correct. If you temporarily increase log detail, reproduce only the necessary request, then restore the normal level afterward. Avoid retaining logs that include destination details.

To roll back, first disable newly added interception and custom entries, then restore the previous routing and DNS settings. Finally, select a verified server and establish a new connection. Restore the system proxy port too if you changed it. Recording each change as “purpose, change, validation, rollback” is easier to maintain than keeping a large configuration with no clear source. For the initial setup, follow the quick-start guide. For specific symptoms, continue with Troubleshooting.