Advanced V2Ray Configuration

Subscription Groups and Server Filtering

Subscription groups keep sources and update schedules organized; server filters narrow the list you are viewing. Neither changes the server-side protocol or configures traffic routing. Create groups by source first, then filter by purpose. Avoid merging everything into one list and guessing where entries came from. When troubleshooting, establish three facts: which address supplied an entry, whether its last update succeeded, and whether the selected server still belongs to that group.

Create groups with traceable sources

In v2rayN, add a group in the subscription group settings, enter a short alias and subscription URL, save it, then update that group. Update the new group on its own first rather than refreshing every source. Check that servers appear in the list, then open an entry and verify its address, port, and transport type. UI labels can vary by release; look for the subscription, group, and update functions rather than relying on a button's exact location.

In v2rayNG and v2flyNG, create a subscription entry before updating the selected subscription. Importing an individual share link from the clipboard usually creates a server entry, not a subscription that can be refreshed. To keep future updates linked to the source, use the subscription URL option instead of pasting returned entries into the list one by one. See how to import subscription links and understand their formats.

Name groups by their management purpose, such as “Daily,” “Testing,” or “Backup.” A group name says nothing about protocol capabilities; entries in the same group may use different protocols and transports. Subscription URLs can contain access credentials, so keep them out of screenshots, public documentation, and shared logs. Use a recognizable alias and any necessary notes to track a source. Keep the full URL in the client and handle it through a secure process when migrating.

Start with the full list, then filter step by step

Before filtering, clear the search box and any region or protocol filters, then confirm that the full list is present. Add one condition at a time, such as a name keyword followed by a protocol. A name search only matches text; it cannot verify a server's location or actual egress. If the list suddenly appears empty, clear the filters first, then check the subscription update. Do not assume a hidden entry means its source is unavailable, and do not delete the whole group on that basis.

Some clients or builds support regex filters, but a regular search box may treat input as plain text. Use expressions only when the UI explicitly offers regex mode. The example below matches three standalone purpose labels; it is not core JSON. Test it against a few existing names first to confirm case sensitivity, separators, and whitespace behavior. If regex mode is unavailable, filter by individual keywords instead of pasting the expression.

(^|[\s_-])(work|daily|backup)([\s_-]|$)

Keep sorting separate from filtering. Sorting by test results changes the display order, but may not switch the active server. A successful test also does not prove every destination is reachable. After selecting an entry, check the active indicator and then visit a real website. Do not assume the top item is active. Keep testing entries in their own group to avoid making an unsuitable configuration your everyday connection after a temporary sort.

Handle updates and local changes

Subscription updates often rebuild or replace entries from a source, so local changes to names, ports, or transport settings may be overwritten. Keep manual configurations you need long term in a separate manually managed area and record why you changed them. Do not assume edits to subscription entries will survive the next update. Before copying an entry, verify that you copied its full connection settings, not just its display name, so authentication and transport details are not lost.

If entries disappear after an update, clear the filters and check the group's update result before deciding whether the source withdrew them, the format is incompatible, or the request failed. Keep a working connection while investigating; repeated deletion and reimporting can erase useful evidence. If the response is empty or parsing fails, follow the subscription update troubleshooting checklist. Once fixed, update only the affected group, verify it, then resume normal management.

Routing Rules in Practice

Routing sends connections that have already entered the core to a specified outbound. It does not automatically direct an app's traffic into the client. If the system proxy is not working, adding more domain rules will not change an app's direct connection path. Before troubleshooting routing, confirm that the local listener, app proxy settings, and core are working. Then check the connection logs for the destination and outbound tag. A rule's match result matters only after the traffic has reached the core.

Put specific rules before broad ones

Rules with common fields are checked in order, and the first match determines how a connection is handled. Conditions within a rule usually all need to match; multiple entries in a domain list are alternative matches. Put a few specific exceptions first and broader domain sets later. Do not start with a catch-all rule and expect later exceptions to take effect. After changing the order, reconnect to the same destination to compare the results.

In domain conditions, full: matches an exact domain, domain: matches a domain and its subdomains, and regexp: uses a regular expression. Prefer the first two when they meet your needs. A plain string may match more broadly than expected and pull unrelated domains into a rule. IP conditions are for addresses or subnets, not web URLs with protocol prefixes. Enter ports and network types in their respective fields.

This is a routing snippet, not a complete configuration. It sends an exact test domain to the outbound tagged block, and loopback and common private IPv4 ranges to direct. Both tags must exist in your actual outbounds. If you need to preserve other rules, insert the relevant rules from this snippet into the array rather than replacing the entire routing configuration.

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["full:blocked.example"],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "ip": ["127.0.0.0/8", "10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16"],
        "outboundTag": "direct"
      }
    ]
  }
}

Understand domains, IP addresses, and when resolution happens

AsIs means routing does not proactively resolve domain names to addresses. If an app submits only an IP, domain rules may have nothing to match; if it submits a domain, IP rules may not have a resolved address to match under this strategy. IPIfNonMatch attempts resolution if domain matching finds no result, then checks the address. IPOnDemand may resolve a domain when an IP condition requires it. If you enable either option, check the DNS path as well.

Sniffing can extract domains from some protocol handshakes, but it cannot do so for every connection. Encrypted handshakes, nonstandard protocols, and connections made directly to an IP can limit what it detects. Sniffing is not a universal substitute for correct DNS configuration. If a client offers an option such as “routing only,” check whether it merely supplies matching information or changes the destination used for the connection. The exact behavior depends on the core's fields.

Verify with logs, not just website results

To verify a rule, close existing connections, visit a specific destination, and check the logs for the inbound tag, target domain or address, and selected outbound. Browser connection reuse may keep a refresh on the old connection, so restart the app or create a new connection after changing rules. If the rule does not match, first check whether the traffic is proxied, whether the domain format matches, and whether the tag is spelled correctly. Then check rule order and resolution strategy.

Distinguish “the rule matched, but the outbound failed” from “the rule did not match.” In the first case, check the selected server and protocol; only the second calls for changes to match conditions. When no rule matches, common configurations use the first outbound. Do not assume that this will be the proxy or direct connection. Clients may reorder outbounds when generating a configuration, so inspect the actual running configuration rather than relying on the server order shown in the UI.

When using geolocation-based domain or IP sets, confirm that the resource files exist, are compatible with the current core, and have an understood update process. A missing resource can prevent the core from starting, rather than simply skip a rule. Start with a precise domain and a minimal verifiable rule before adding large sets. If something breaks, restore the last working configuration and follow the troubleshooting steps for a connection with no web access.

Optimize DNS Configuration

DNS configuration is about who sends a query, where it goes, and how the result is used—not just choosing a resolver. A visit may involve the system resolver, a browser's secure DNS, the core's built-in DNS, and resolution by a remote server. Changing one does not automatically take over the others. Map the actual path from app to resolver first, then decide whether you need core-level resolution, a server for specific domains, or encrypted DNS transport.

Check three types of domain names separately

First, the proxy server's own hostname must resolve to a usable address before the connection can be established. Second, the destination hostname visited by the user may be resolved locally or remotely. Third, the DNS service's own hostname may need bootstrap resolution when using an encrypted DNS URL. If all three depend on a proxy tunnel that has not yet been established, you can create a circular dependency. Keep a clear, reachable resolution path for the initial connection.

This simplified baseline uses the system resolver and allows both IPv4 and IPv6 results, making it useful for understanding the fields. localhost means the system's resolution capabilities are used; it does not mean the core opens a DNS server port on the local machine. This snippet also does not force a browser to stop using its own secure DNS. It is not an optimization for every network; its purpose is to make the resolution source clear before you refine the configuration.

{
  "dns": {
    "servers": ["localhost"],
    "queryStrategy": "UseIP"
  }
}

UseIPv4 and UseIPv6 can restrict which address families are requested, but do not permanently disable one just because a single site was slow. First check whether the system receives the relevant address, whether the route is reachable, and whether the outbound supports it. An IPv6 result does not guarantee that the connection will use IPv6; the app, core, outbound configuration, and system network stack all affect the final choice.

Narrow down the issue by failure stage

A DNS timeout and a connection timeout are different failures. A DNS timeout may mean no address was returned; a connection timeout means an address was obtained but the connection could not be completed. A failed page load alone cannot distinguish them. Compare query results with subsequent dial errors in the core logs, and temporarily enable info-level logging if needed. Avoid verbose logs long term, and do not share full logs containing destination domains or subscription URLs.

At the system level, run nslookup example.com to check system resolution; this does not mean the query went through the core's built-in DNS. When comparing results, note the network, time, and app resolution settings so differences between resolution paths are not mistaken for a broken configuration. If system resolution works but the client still fails, focus on the core's DNS transport path, related routing conditions, and whether the proxy server hostname depends on the same failing path.

Then consider split DNS and caching

Internal hostnames usually rely on the resolver provided by the local network. Switching everything to a public resolver can make them stop working. When assigning a DNS server to specific domains, use a matching method supported by your core, and check whether fallback queries may be sent to other servers. Cores differ in support for fallback fields and priorities; do not copy every advanced field directly between v2rayNG and v2flyNG.

Encrypted DNS changes how queries are transported, but the resolver must still be reachable, certificate validation must succeed, and system time must be accurate. For a service URL using a hostname, resolve the hostname first; for an address-based URL, check certificate and server-name requirements too. Do not change the DNS server, routing mode, and TUN settings all at once, or you will not know what caused the result. Keep a recoverable configuration copy after each step.

Caching can make tests continue using old results after a change. To verify, restart the relevant app and client, and clear the resolver cache using the method provided by the system if necessary. Do not repeatedly change server addresses just to “refresh” results. After switching from a home network to a work network, recheck internal hostnames and interface-related settings. You have verified this section when you can explain where each type of query comes from and where it goes—not just when one site happens to load again.

TUN Mode and Traffic Capture

TUN mode receives network-layer traffic through a virtual network interface, which can help with apps that ignore system proxy settings. It changes what traffic is captured; it does not fix incorrect server settings or guarantee that every protocol follows the same path. Before enabling it, verify that regular proxy mode works, then check permissions, routes, and DNS. Otherwise, existing connection problems combined with capture issues can make the entire system appear offline.

Establish a recoverable baseline first

On desktop, first connect through the system proxy in v2rayN and note the active server, routing mode, and DNS settings. Stop other virtual network adapters or tunnel tools that are capturing traffic, then enable the client's TUN option. Some implementations require administrator privileges or a helper service, or use a separate component for traffic capture. Use the features provided by the current client; do not assume the TUN toggle maps directly to a top-level core field.

On Android, v2rayNG and v2flyNG typically capture app traffic through the system VPN interface. Read the system authorization prompt the first time and confirm that it names the current client. The system generally does not allow multiple capture services of this kind to run at once, so stop the previous client before switching. This system interface describes the capture mechanism; it does not mean the client has a usable remote service. Server settings must still be configured separately.

Check permissions, default routes, and loopback

After enabling TUN, confirm that the virtual interface is up, the core keeps running, and the default traffic path is as expected. If the client repeatedly reconnects as soon as it starts, its own connection to the proxy server may be routed back into the virtual interface, creating a loop. A correct implementation must exclude its own outbound traffic or bind it to the physical network interface. Do not mask the problem with broad direct rules; first check interface selection, automatic routing, and process exclusions in the client.

Test local network access separately. Printers, shared folders, and internal services may use private or link-local addresses or special internal hostnames. Routing common private address ranges directly is only part of the solution; also check the virtual interface routes, name resolution, and firewall. If a device works by address but not by name, return to the DNS section. If the address does not work either, check interface routes and subnet conflicts rather than immediately changing the server protocol.

Separate capture coverage from transport support

Whether UDP works after traffic enters TUN still depends on the capture component, selected protocol, server capabilities, and routing rules. A working browser does not prove that real-time communication or other UDP apps will work. Test the apps you actually need and check their network type and error logs. If something is incompatible, narrow the capture scope or use the app's own proxy option instead of changing every setting at once.

Adjust MTU only after verifying the basic connection. Consider fragmentation or path MTU issues if only some larger transfers stall; there is no single value that works for every network. Change one step at a time and retest the same destination, keeping a record of the original setting so you can restore it immediately if needed. If basic DNS resolution and short connections fail, fix permissions, routing, and DNS before experimenting with MTU.

The physical interface name and gateway can change after waking from sleep, switching Wi-Fi networks, or connecting Ethernet. If the setup works at startup but fails after a network change, stop and restart traffic capture, then check whether automatic interface selection updated. Recording the conditions that trigger a failure is more useful than repeatedly reimporting subscriptions. Subscription management does not maintain system routes; fetching the server list again will not fix a failed interface.

After completing this section, test three kinds of destinations separately: a regular website, an app that does not normally use the system proxy, and a local network service you need. The results help distinguish capture coverage from remote transport and local network exceptions. A status indicator showing that the service is running is not enough to prove capture is working. Also confirm that the network recovers when the client closes, so apparent success is not relying on stale routes.

FakeDNS Address Mapping

FakeDNS maps domain names to synthetic addresses from a controlled pool, then restores the original domain when traffic enters the core. It preserves domain information for routing; it is not a public DNS service that replaces all resolution. A usable destination and outbound are still needed for the real connection. Before enabling FakeDNS, understand the DNS query path and TUN capture boundary. Otherwise, an app may receive a synthetic address while its connection never reaches the core that can restore the mapping.

Make sure the query and connection paths form a complete loop

A complete path has three steps: the app sends a query through a resolution path that provides FakeDNS, receives a synthetic address, then makes a connection that the corresponding core captures and maps back to the original domain. Any missing step causes failure. Adding an address pool to the configuration does not automatically route system queries through it; enabling TUN does not mean the core sends every DNS query to FakeDNS. Verify the query source, returned address, and connection inbound separately.

This Xray-style core snippet shows how the address pool, DNS servers, and SOCKS inbound sniffing relate. It is not a complete client configuration or a universal template for all cores. The listener is local only; sniffing on the SOCKS inbound applies only to connections it receives and does not automatically capture system DNS. To use similar settings with TUN, use the capture and DNS options provided by the client rather than copying this inbound directly.

{
  "fakedns": [
    {
      "ipPool": "198.18.0.0/15",
      "poolSize": 65535
    }
  ],
  "dns": {
    "servers": ["fakedns"]
  },
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      },
      "sniffing": {
        "enabled": true,
        "destOverride": ["fakedns"]
      }
    }
  ]
}

The address pool is not a server list

ipPool defines an address range for synthetic mappings, and poolSize sets the mapping pool capacity. The number of addresses is not the number of servers or available connections. Do not save pool addresses as real remote server addresses in a subscription or manual entry. If your network already uses the same range, conflicts may occur. Check existing routes and internal network plans before enabling it; valid configuration syntax alone is not enough.

The range in the example is for specific uses such as benchmarking; it is not a publicly reachable destination. After an app receives one of these addresses, the connection must follow the correct mapping path. If logs show the client trying to send the range directly over the real network, the mapping is not being consumed or the connection bypassed capture. Adding ordinary proxy rules is usually not the fix; first check sniffing support, inbound placement, and whether the DNS response came from the same running instance.

Account for core differences and app behavior

v2rayNG and v2flyNG use different cores, so check FakeDNS field support, configuration format, and integration separately. Similar-looking client interfaces do not mean you can copy an entire custom JSON configuration between them. v2rayN may also use different components for traffic capture, so first confirm which core is actually running and how the configuration is generated. For background on the different branches, see the relationship between Xray and V2Fly cores.

An app that uses its own encrypted DNS may bypass the configured system query path and get a real address instead of a synthetic one. Other apps may use cached addresses or fixed IPs, leaving no domain mapping to restore. One successful browser test does not prove that every app uses FakeDNS. Test a newly queried domain and compare query and connection logs; if needed, temporarily align the test app's DNS settings.

Mappings usually exist only in the current core process, so cached synthetic addresses may no longer map to their original domains after a restart. If only some apps fail after restarting the client, clear their DNS caches or restart those apps before refreshing subscriptions. When disabling FakeDNS, handle cached results too, so apps do not keep treating synthetic addresses as real destinations after the client stops. Check again after network changes and waking from sleep.

Routing can apply domain conditions after the original domain has been restored; correct routing does not guarantee that remote resolution will work. If logs show the original domain and expected outbound, continue troubleshooting at the real DNS resolution and connection stages. Enable FakeDNS in a test environment first, and confirm that normal resolution works again after disabling it before expanding its use. If you do not need to preserve domain names explicitly, your existing working DNS setup is usually easier to maintain.

Managing Multiple Subscriptions and Update Strategies

The goal of managing multiple subscriptions is to isolate update risk and make switching decisions clear, not to build the longest possible list. Each source has its own URL, format, validity period, and connection requirements. An update failure in one source should not affect other working groups. Track each source, its purpose, and the active entry separately. This helps distinguish duplicate names and prevents reliance on old entries that a source has withdrawn.

Separate by source, choose by purpose

Create a separate group for each subscription URL, then use aliases to distinguish everyday, testing, and backup use. Do not concatenate different source URLs into one address, or paste the contents of multiple subscriptions into the same import field and expect the client to preserve their source relationships. Merged static entries may lose their update links, making later additions, removals, and parameter changes hard to track even if they connect at first. Keep the client's native subscription records wherever possible.

The same name does not mean two entries have the same connection settings. When checking for duplicates, compare at least the protocol, server address, port, and transport settings. Verify authentication details locally. Different sources may use the same alias for different services, and the same address can represent different entries if their authentication or transport differs. Before cleaning up, confirm which group the active connection comes from and keep a working baseline. Do not delete the only usable configuration just to tidy the list.

A group is not an automatic failover mechanism. Naming a group “Backup” does not make the client switch to it when the current connection fails. Automatic selection, load balancing, and probing are separate features; their availability and behavior depend on the client and core. Unless these mechanisms are explicitly configured, treat a backup group as a manual fallback and record how to select and verify it. Do not infer runtime behavior from the group name.

Use a consistent update sequence

When adding a source, update it on its own first and check the parse result and one representative entry before scheduling regular updates. Before enabling scheduled updates, confirm that the client will be running at the scheduled time, the network will be available, and which path the update request will use. Clients may handle update requests through the current proxy differently; check the relevant option and test it. A successful subscription update and a reachable server are separate measures, not a single result.

When an update fails, check the error type before changing the request path. A connection timeout may be caused by the current network; authentication errors or an expired URL require checking the source; an empty parse result may indicate an incompatible format. Avoid retrying every source repeatedly in a short period: it adds noise and may trigger rate limits at the source. Work on the affected group only, leave others unchanged, and compare it with the most recent successful update.

After updating the server list, check whether the active entry still exists, was recreated, or switched to a default. Some clients try to preserve the selection, while certain actions may change it; behavior is not uniform. Confirm the active indicator, reconnect, then test common destinations and any required local network access. If only the display name changed and the actual connection settings did not, there is no need to redo routing configuration.

Separate management data from connection data when migrating

When moving to another device, check subscription records, manual entries, routing rules, DNS settings, and system capture options separately. Exporting a server share link usually does not include group update schedules or the complete system proxy or TUN state. After migration, verify the connection in regular proxy mode before restoring advanced settings one at a time. Do not copy interface names, subnet assumptions, or permission state from the old device without checking the new environment.

Backups may contain subscription access credentials, server authentication details, and personal access preferences. Keep them in controlled storage, not in public troubleshooting materials. When sharing diagnostic information, include only the error type, field names, and snippets with sensitive details removed. A text backup is not automatically safe to upload. Before restoring it, confirm which client and core it belongs to so you do not overwrite a working configuration.

Before removing a source, switch to another verified connection, stop that group's update schedule, then delete the subscription record and entries you no longer need. Finally, check for client rules or custom outbound references that still point to old entries. After cleanup, test a connection again to make sure it is not relying on an old session that has not yet closed. This keeps multiple subscriptions traceable instead of appearing to work only because of stale state.

Custom Outbounds and Configuration Validation

An outbound defines how a connection leaves the core; routing selects one by tag. A server entry, an outbound object, and a routing rule are related but distinct. Clients usually generate an outbound from the selected server. If you use a full custom configuration instead, switching servers in the UI may no longer update that configuration. Before editing, confirm whether the current field accepts complete JSON, an outbound snippet, or a client-specific rule format.

Validate the structure with a minimal configuration that has no remote authentication

This complete baseline configuration is for local feature testing. It uses common SOCKS, direct, and block structures found in V2Fly and Xray. It does not connect to a remote proxy; it only verifies the local listener, tag references, and routing behavior. If the port is already in use, stop the conflicting service or change the listening port. Do not import this as a subscription server entry. Use an option that supports full core configuration and save your existing settings first.

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ],
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["full:blocked.example"],
        "outboundTag": "block"
      }
    ]
  }
}

In this configuration, direct and block are user-defined tags, not reserved keywords that work just because of their names. The actual behavior is determined by protocol; if you rename a tag, update every reference to it. In this example, unmatched connections use the first, direct outbound, while the exact test domain goes to the block outbound. The test domain is only for observing rule behavior and does not serve real website content.

Check syntax, meaning, and runtime in three stages

For syntax, check quotation marks, commas, and closing brackets for arrays and objects. Standard JSON does not allow comments or trailing commas. For semantics, confirm that fields belong to the current core, tag references exist, and ports and addresses are valid. Only then start the core and observe the result. Being able to parse the file with a JSON tool proves only that the syntax is valid; it does not prove protocol support, server reachability, or correct routing.

At runtime, first confirm that the listener starts successfully. Then configure a test app to use the local SOCKS address and port. For domain rules, the app must send the domain to the proxy for resolution. If the app resolves it locally and submits only an IP, an exact domain rule may have nothing to match. After confirming ordinary access, test the sample domain and observe the block behavior. Make sure the result comes from the current core, not a failed request from an app that bypassed the proxy.

The sample listens on a loopback address, which is suitable for local testing. Listening on all interfaces changes who can access the service; in particular, other devices on the same network may use an unauthenticated SOCKS service. If sharing is necessary, plan authentication, firewall rules, and allowed sources rather than simply changing the listening address. Understand the scope of a client's “Allow LAN” option too; do not enable it temporarily for troubleshooting and leave it on.

Keep a rollback path when adding a real outbound

Generate a real remote outbound from verified server settings, then adjust its protocol fields for the current core. Do not mix V2Fly-only and Xray-only parameters, or copy a protocol name while omitting related transport, security, or server-name settings. If details are missing, return to the client's normal server editor to check them. To choose a core, use the client comparison as a guide; do not switch clients repeatedly to hide missing parameters.

Give each outbound a unique, descriptive tag and document why each routing rule selects it. For chained connections, confirm which connection methods and fields the core actually supports, and distinguish selecting an outbound from dialing through another outbound. These relationships do not form automatically just because two objects exist. For the first test, add one real outbound and one specific rule; expand only after it works to avoid circular references or a hard-to-trace default route.

A client may regenerate its running configuration at startup, when switching servers, or after subscription updates, so edits to a temporary generated file may be lost. Put persistent settings in a custom configuration option explicitly supported by the client, and confirm they survive a restart. To roll back, restore the previous configuration, restart the core, then check system proxy and TUN status. Do not just replace a file and keep using an old process, or the UI and runtime state may no longer match.