V2Ray Advanced Configuration Reference

Separate subscriptions, configurations, and groups

A subscription link is not a single server. It is closer to a configuration list maintained by a service provider. When a client updates a subscription, it reads that list and creates multiple server entries; groups are the client-side management layer used to organize them. Their lifecycles differ: a subscription may update on a schedule, server names and parameters may change with it, while local groups should usually remain stable. Once this distinction is clear, the strategy follows naturally: subscriptions receive source changes, filters select the entries you need, and groups hold fixed purposes. Do not rely on manually dragging dozens of entries into order, because the next update may regenerate the list and make that manual ordering meaningless.

In v2rayN, a reliable approach is to create subscription groups by source, such as “Daily primary,” “Backup,” and “Testing,” then assign update settings, filters, and aliases to each source. On Android, v2rayNG is better kept to a small number of groups: screen space is limited, and overly granular groups make switching slower. v2flyNG follows a similar management model to v2rayNG, but its core system differs, so verify that protocols and transport parameters were imported correctly. When moving between clients, migrate subscription URLs or standard configurations rather than treating a client-specific display order as a universal setting.

Use positive filters to build predictable lists

Server filters commonly support remark matching, protocol selection, address matching, and port conditions. Start with positive conditions—explicitly define which entries to keep—then add only a few exclusions. If subscription remarks include region, purpose, and multiplier information, keep entries containing “frequent-use” or a specific region label, then exclude entries marked “expired,” “maintenance,” or “testing” from daily selection. The clearer the positive conditions, the easier it is to spot naming changes by the provider. Maintaining only a long exclusion list can let new unwanted labels enter the selectable list unnoticed.

Write filter expressions around naming patterns that actually exist in the subscription. A common regular expression such as ^(?!.*(?:maintenance|expired)).*(?:frequent-use|backup) excludes entries containing “maintenance” or “expired” while keeping names containing “frequent-use” or “backup.” Full-width punctuation, spaces, and capitalization can all affect the result. When writing a rule for the first time, copy several real remarks into a local text file and compare them one by one before adding the expression to the client. Do not start with a complex expression; two simple, maintainable rules are often more reliable than one complicated combination.

{
  "group": "Daily primary",
  "include": "(frequent-use|backup)",
  "exclude": "(maintenance|expired|testing)",
  "updateIntervalHours": 24
}

What to preserve before and after an update

Before updating a subscription, confirm that at least one configuration currently connects and note its subscription and remark. After the update, first check for an unexpected change in entry count, then verify that the selected item still exists. If the count suddenly drops to zero, suspect subscription access, filter conditions, or group selection before changing protocol parameters. If it falls sharply, temporarily disable filtering and inspect the raw results. If the raw entries are complete, the problem is local filtering; if they are incomplete too, inspect what the subscription itself returned.

Updates also involve an overwrite strategy. Entries generated by a subscription should generally remain under subscription management, so avoid permanently changing their address, port, user identifier, or transport parameters directly; a later update may overwrite those changes. For experiments, copy an entry into a local testing group and prefix its name with “Local test” so it is easy to identify. Once testing succeeds, subscription-side changes should be corrected at the source. If the change concerns only local routing or DNS, put it in the client’s global settings or routing rules instead of editing servers one by one.

Handling empty lists and duplicate entries

When no servers appear after importing a subscription, check in this order: confirm that you are viewing the correct group, run a manual update, disable all include and exclude conditions, and then check the client log for parsing errors. If disabling filters restores the list, re-enable the rules one at a time to find the conflict. If the log says the content format is unsupported, verify that the subscription returns a configuration format supported by the client—not a login page, notice, or expired response. For related fundamentals, see the Help Center.

Duplicate entries usually come from importing the same subscription twice, two subscriptions containing the same server, or choosing append instead of overwrite during an update. Do not identify duplicates by remark alone: entries with the same name may have different addresses or transport parameters. Compare the address, port, protocol, transport, and security settings. Keep one copy of genuinely identical entries under a stable subscription; rename same-name entries with different parameters to show their sources. The goal is not the largest possible list, but a list where every entry has a traceable source, a clear purpose, and remains understandable after updates.

Routing decisions happen before a connection is established

Routing rules do not change server parameters; they select an outbound for each target connection. After an application initiates a request, the core reads available information—such as the destination domain, address, port, network type, and process source—and searches for a match in rule order. Once a rule matches, the connection is handed to its outbound, such as proxy, direct, or block. If no rule matches, it falls through to the final default outbound. When troubleshooting routing, ask “Which rule caught this connection?” rather than looking only at the currently selected server.

A domain and an address are not always available at the same time. Some connections enter the core with a domain, allowing direct domain matching; others provide only an already-resolved address, so domain rules may not apply. With domain sniffing enabled, the core may recover a destination domain from some protocol traffic, but sniffing is not reliable in every situation and should not replace sound DNS design. A stable routing setup considers both domain and address rules and makes clear which rules depend on sniffing.

Rule order determines the result

Most clients match from top to bottom, and the first matching rule immediately determines the outbound. Put the narrowest, highest-priority rules first and broad fallback rules later. For example, an internal domain that must use direct access should precede a broad proxy-domain rule; a direct rule for local network addresses should precede the default proxy; only then should a catch-all handle everything else. If the order is reversed, the broad rule matches first and later precise rules never run, even when written correctly.

A maintainable rule set often follows this order: “specific blocks, specified direct access, specified proxy, address ranges, default behavior.” Keep block rules restrained and limited to targets that clearly should not connect. Direct rules cover local networks, client-update targets, and services known to be reachable locally. Specified proxy rules handle domains or applications that genuinely require it. Address-range rules handle connections that provide only an address. The default behavior handles everything uncategorized. With a clear hierarchy, outbound labels in the log are easier to interpret.

Xray routing structure example

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["domain:intranet.example"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["domain:docs.example"],
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

Understand domainStrategy instead of applying a value mechanically

domainStrategy determines when a domain is resolved into an address during routing. With AsIs, routing prioritizes the original domain and does not actively resolve it for address rules; IPIfNonMatch tries domain rules first, then resolves the address and continues with address rules if nothing matches; IPOnDemand may trigger resolution earlier when a rule requires address information. No value suits every network. If domain rules dominate and you want to minimize extra lookups, start with AsIs; when address-based routing is essential, IPIfNonMatch is usually easier to reason about.

Resolution during routing is also affected by the DNS module. If DNS queries use the wrong outbound, routing may receive an unexpected address and match a different rule. If changing domainStrategy makes the same domain use different exits intermittently, also check DNS server selection, caching, and domain-rule matches. Routing and DNS are connected systems and should not be tuned blindly in isolation.

Narrow the scope by port, network, and application

Port conditions are useful for clearly defined services, such as assigning a particular TCP port to one outbound, but they should not replace domain classification. Many services share port 443, so port-only rules cannot distinguish their targets. Network conditions can distinguish TCP from UDP and help when an outbound lacks UDP support or real-time traffic needs separate handling. Application conditions depend on client capabilities: v2rayNG’s per-app proxy determines which Android apps enter the VPN; once inside the core, those connections can still use domain, address, and port routing.

Choose include or exclude mode for per-app proxying around one clear goal. If only a few apps need to enter the client, include mode is easier to control; if most apps should enter and only a few local apps are exceptions, exclude mode requires less maintenance. After an app update or package-name change, an old rule may stop matching. If an app suddenly changes behavior after a system upgrade, check the app selection list before rewriting domain rules.

Use logs to verify matches, not just webpage results

To verify routing, first clear background connections that could confuse the test, then open the client log and access only one test target. Focus on the destination domain or address, the matching rule, and the final outbound label. If the log shows only an address, inspect DNS and sniffing settings. If the outbound label is correct but access fails, the issue is more likely the destination server, selected node, transport parameters, or local network. If the label is wrong, temporarily move the relevant rule to the top to confirm that the rule itself matches, then restore a sensible order.

After changing routing rules, restart the connection so the new configuration loads completely. A browser may reuse an existing connection or retain DNS cache, so refreshing the page alone is not enough. A safer process is to disconnect the client, close the test app’s background process, reconnect, and make a new request. For a systematic checklist when the client shows connected but access fails, see the step-by-step proxy port, routing mode, and DNS checklist.

Map the resolution path first

DNS failures are difficult to troubleshoot because system DNS, client DNS, browser encrypted DNS, and remote resolution may all coexist. After an app submits a domain, the query may be handled by the operating system or intercepted by TUN; if the browser has independent encrypted DNS enabled, it may bypass the client settings. Once the core receives the query, it must select a DNS server by domain rules and decide whether the query uses direct or proxy access. The returned address may enter a cache and then be passed to routing. A change at any layer can look like “the domain fails but the address works” or “the same domain returns inconsistent results.”

The first optimization step is not adding more DNS addresses; it is defining one primary path. In ordinary system-proxy mode, let the client resolve domains that need proxy access while leaving local resources to system resolution. In TUN mode, queries entering the virtual interface should be handled centrally by the core whenever possible. During testing, temporarily disable the browser’s independent DNS to avoid a parallel path. Once the client path is confirmed, decide whether to restore the browser setting and verify that its traffic follows the intended route.

Roles of local and remote DNS

Local DNS is suitable for local network names, corporate domains, and targets that should clearly be answered by the current network. Remote DNS is suitable for domains whose queries travel through a proxy outbound, keeping the resolution location aligned with the access exit. This is not simply a choice between “fast” and “slow”; the two servers cover different namespaces. Sending internal domains to a remote server usually produces no useful address, while always sending domains that should match a proxy exit to a local server may return an address unsuitable for that exit.

Assign servers by domain set and keep one clear default resolver. If the client supports DoH, you can use an HTTPS endpoint such as https://1.1.1.1/dns-query; with ordinary UDP DNS, make clear whether requests use a proxy outbound. DoH is only a transport format and does not guarantee correct routing. The endpoint’s own domain also needs an initial lookup, so strict environments may require an explicit server address or bootstrap-resolution strategy to avoid a circular dependency where resolving the DNS server requires reaching that same DNS server.

Choose DNS servers by domain scope

{
  "dns": {
    "hosts": {
      "router.internal.example": "192.168.1.1"
    },
    "servers": [
      {
        "address": "192.168.1.1",
        "domains": [
          "domain:internal.example"
        ],
        "skipFallback": true
      },
      {
        "address": "https://1.1.1.1/dns-query",
        "domains": [
          "geosite:geolocation-!cn"
        ]
      },
      "localhost"
    ],
    "queryStrategy": "UseIP"
  }
}

queryStrategy and address-family selection

queryStrategy controls whether to query IPv4, IPv6, or both. With UseIP, both address types are generally allowed, though the actual result depends on the server and network. IPv4-only can reduce waiting when IPv6 is unavailable; IPv6-only requires complete support from the local network, proxy outbound, and destination service. Do not disable IPv6 merely because an IPv6 address appears in the log; first determine whether the failure actually occurs during the IPv6 connection. A stable network can keep dual-stack enabled, while an incomplete network should use the address family it can genuinely reach.

Address-family issues often appear as a slow first load that later recovers, or as different behavior for the same target in different apps. One cause may be different address-selection algorithms; another may be one address family failing before fallback. Inspect A and AAAA results separately and confirm the final destination address attempted in the client log. Changing only the DNS response type without checking outbound capability may exclude an otherwise usable address family.

Caching, fallback, and pollution-related misdiagnosis

DNS caching reduces repeated queries but can extend the impact of an incorrect result. After changing servers or routing rules, disconnect and reconnect the client and, if necessary, restart the test app so old cache entries are cleared. If the system still retains a result, wait for it to expire or use the system’s cache-refresh method. Do not switch through several DNS servers and compare them immediately: the browser, system, and client may each hold results from different stages, so the observation will not represent one configuration alone.

Fallback sends queries to an alternate resolver when the preferred server is unsuitable or its result meets a defined condition. The condition must be explicit; otherwise multiple servers may return different answers and make the result harder to understand. For internal domains, skipFallback can prevent queries from leaking to servers that do not know the internal namespace. For ordinary domains, design fallback around domain sets or address ranges instead of listing several servers and expecting the client to choose the “best” answer automatically. The more complex the setup, the more important it is to use logs to confirm which resolver actually handled the query.

Troubleshooting order for remote DNS failures

When remote DNS does not respond, first check whether the endpoint connection can be established, then determine whether its request uses a proxy or direct outbound. If the endpoint uses a domain, confirm that bootstrap resolution returns an address. For HTTPS, check the device clock, since a time mismatch can affect TLS setup. Next, check whether routing sends the DNS endpoint to a block or unsupported custom outbound. Finally, inspect response-format and timeout details in the client log. This order distinguishes an unreachable endpoint, a routing error, and an unsuitable resolution result.

On Android, enabling VPN mode also requires attention to the system Private DNS setting. System Private DNS, the browser’s independent DNS, and v2rayNG remote DNS can run at the same time and produce an unexpected query path. During troubleshooting, keep only v2rayNG’s path, confirm stable resolution and access, then restore system features one by one. On desktop, distinguish system proxy from TUN in v2rayN: a system proxy does not necessarily capture DNS from every program, while TUN is closer to full network-layer capture. The two modes cannot be evaluated in exactly the same way.

TUN and system proxy operate at different layers

A system proxy depends on an application actively reading the operating system’s proxy settings, making it suitable for browsers and software that follows system network configuration. TUN creates a virtual network interface and receives traffic at a lower network layer, so it can cover programs that do not support HTTP or SOCKS proxy settings. Its coverage is broader, which also means more details need attention: routing tables, DNS interception, UDP, address families, local-network access, and other virtual-network software may all be involved. TUN is not simply a “stronger switch”; it is a different traffic entry point.

Choose the mode based on application needs. For everyday web access and software that clearly supports the system proxy, start with system proxy mode because it is simpler and has fewer failure points. Enable TUN when a program ignores the system proxy, UDP must be handled, or more applications need unified capture. Do not add TUN before the basic connection is confirmed. Verify the server, protocol, and subscription in ordinary proxy mode first, then switch the entry point so new issues are limited to TUN, DNS, or the routing table.

System preparation before enabling TUN

When enabling TUN in desktop v2rayN, the system usually must allow creation of a virtual network adapter and modification of routes. Insufficient permissions can make the switch appear enabled while the interface is not correctly established. Check the client log for interface creation, address assignment, and route installation instead of relying only on the button state. Security software, firewalls, and other virtual-adapter tools may block drivers or change route priority. For the first test, close unnecessary networking tools, keep one variable at a time, and confirm that v2rayN can run independently.

Android v2rayNG uses the system VPN interface for capture, and the system displays the VPN status. Per-app proxy rules, always-on VPN, system Private DNS, and battery-saving policies can all affect the result. If another VPN service is selected at the same time, both services generally cannot occupy the same interface. Before switching clients, disconnect the current connection and wait for the state to be fully released before starting the new one. Background restrictions may pause the client, so allow it to run reliably under the device’s battery-management rules.

Stack type, MTU, and UDP

TUN implementations may offer different network-stack options. The system stack follows operating-system behavior more closely and is usually compatible; a user-space stack handles more networking inside the client and can provide greater cross-platform consistency. Names vary by client interface, but the principle is the same: start with the client’s recommended default and switch only when logs point to a compatibility issue, UDP anomaly, or specific app failure. Rebuild the connection after switching and repeat the same test against the same target.

MTU is the amount of data a network interface carries at once. If it is too large, packets may need fragmentation or be dropped on some paths, producing symptoms such as small pages loading while large content stalls, uploads failing, or a connection carrying no data after setup. If it is too small, overhead increases. Start with the system or client default; when fragmentation is suspected, reduce it slightly and record each change. Do not apply extreme values directly, because the effective limit varies by network, transport, and encapsulation layer.

UDP requires support from both the outbound and the server configuration. TUN receiving UDP does not mean the remote side can forward it. If web access works but real-time traffic, voice, or some DNS lookups fail, check whether UDP entered the correct outbound and whether the current server configuration permits it. For diagnosis, temporarily switch DNS to HTTPS-based queries to distinguish ordinary UDP DNS failure from a broader UDP failure; then test the real use case again rather than treating the temporary workaround as a permanent fix.

Bypassing the local network and preventing routing loops

After TUN takes over, local printers, router management pages, and file shares may be sent through the proxy by mistake. Keep direct rules for private addresses near the front of the routing rules and add local domains as needed. Common private ranges can be handled by the core’s geoip:private, but corporate networks may use additional ranges that must be added based on the actual network. Test the gateway address, a local-device address, and an internal domain separately to confirm both direct access and internal DNS.

A routing loop occurs when traffic from the client to the proxy server or DNS endpoint is captured by TUN again and sent back to itself. Clients often exclude their own process or server address automatically, but custom outbounds, chained proxies, and unusual networks can break that protection. Typical signs include losing network access immediately after connecting, repeated appearances of the same target in logs, or constant server reconnections. Ensure the proxy server address, required bootstrap DNS, and the client’s own traffic have clear reachable paths, and avoid sending all traffic indiscriminately back to the same entry point.

Basic routing framework for TUN

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["domain:internal.example"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

Conflict diagnosis and recovery path

If all access stops after enabling TUN, disconnect first and confirm that system networking recovers. If it does not, exit the client and check for a leftover virtual adapter or system route. Reopen the client without TUN and use ordinary proxy mode to verify the server. Once ordinary proxy mode works, disable other VPNs, virtual-machine networking tools, and software that may rewrite routes, then enable TUN again. If access returns, the cause is a software conflict; if it still fails, inspect logs for interface creation, DNS capture, and default-route installation.

When only some apps fail, do not reset the entire configuration. First determine whether the app is included by per-app rules, then check whether it uses TCP, UDP, or its own DNS, and inspect the routing label for that connection. An app may fail to log in even when webpages work because it uses different domains or a different certificate-validation path. Start one app at a time and filter logs by target to narrow the issue to a specific connection. For node timeouts and connections that drop immediately, continue with the six-step v2rayNG node timeout checklist.

What FakeDNS solves

Some apps perform DNS resolution themselves and then pass only the destination address to the system. When the connection enters TUN, the core may see only that address, while the original domain is gone and domain-based routing cannot match. FakeDNS takes a different approach: the client returns a virtual address for a controlled query while recording the mapping between domain and virtual address. When the app connects to that virtual address, the core restores the original domain from the mapping and then selects the real DNS server and outbound by domain rules. Its primary purpose is preserving domain context, not replacing public DNS.

This mechanism depends on both the query and the later connection passing through the same client. If an app performs independent resolution outside the client, or its connection does not enter TUN, the mapping cannot be created or used. Browser encrypted DNS, built-in app resolvers, and some direct networking libraries can create bypasses. Before enabling FakeDNS, make sure the DNS interception path is clear and basic TUN operation is stable. Otherwise it is difficult to tell whether a problem comes from the mapping, a DNS bypass, or the virtual adapter itself.

The virtual address pool is not a group of reachable servers

FakeDNS returns addresses from a dedicated virtual pool. Each address represents a domain inside the client; it is not a real server reachable on the Internet. A diagnostic tool showing a virtual address does not mean resolution failed. The important question is whether the client captures the subsequent connection and restores the domain. If an app saves a virtual address to a file, caches it for a long time, or shares it with another device, the address has no meaning outside the client’s mapping. FakeDNS results therefore should not be used for persistent configuration, server allowlists, or sharing with local-network devices.

The address pool must not overlap with real networks, local networks, or other virtual interfaces. Client defaults usually cover common cases, so do not change them casually unless logs show a routing conflict. If a corporate network uses unusual ranges, or the device also runs containers, virtual machines, or other tunnels, inspect the routing table for overlap. Conflicts may cause real addresses to be mistaken for virtual mappings or virtual connections to be captured by another interface.

Example FakeDNS and DNS server combination

{
  "dns": {
    "servers": [
      "fakedns",
      {
        "address": "https://1.1.1.1/dns-query",
        "domains": ["geosite:geolocation-!cn"]
      },
      "localhost"
    ],
    "queryStrategy": "UseIP"
  },
  "fakedns": [
    {
      "ipPool": "198.18.0.0/15",
      "poolSize": 65535
    }
  ]
}

Working with sniffing and routing

FakeDNS and domain sniffing can both help the core obtain a domain, but they do so through different paths. FakeDNS creates an explicit mapping during the DNS query and suits TUN traffic whose queries are fully intercepted. Sniffing tries to identify a domain from later protocol content and may help connections that did not use FakeDNS. They can be combined, but sniffing should not be expected to solve every case. For highly encrypted traffic or protocols that carry no identifiable domain, sniffing may fail, while a FakeDNS mapping is more direct.

Routing rules still run in their defined order. Once a domain is restored, precise domain rules, domain-set rules, and the default rule are matched in sequence. If FakeDNS successfully restores the domain but traffic still uses the wrong outbound, inspect rule order and outbound labels instead of changing the address pool again. Logs usually show the original target, restored domain, and final outbound; reading all three together reveals where the problem occurred.

When to enable it cautiously

Local-network domains, device discovery, printing services, and apps that require real addresses need careful handling. Internal domains should usually use local DNS and direct access rather than FakeDNS. Software that relies on DNS-returned addresses for local-network scanning or access control may also fail to understand virtual addresses. Use domain rules to bypass FakeDNS for internal names and send them directly to the local resolver. If an app must receive a real address, give it a per-app bypass or a real-DNS path.

Server software, development tools, and network-analysis tasks that need to display real destination addresses may also be poor candidates for FakeDNS by default. They may record a virtual address in logs, leading analysts to think the target server is located there. During packet capture or reproduction, record clearly whether FakeDNS was enabled and retain the domain-mapping log. Only then can the virtual address be correctly mapped back to the real target.

Cache mismatch and application issues

An app retaining an old virtual address after FakeDNS is disabled is a common transition failure. The client no longer maintains the mapping, but the app continues connecting to the old address, so failure is expected. After changing FakeDNS state, rebuild the connection and close the relevant app’s background process; if necessary, wait for its DNS cache to expire. The reverse transition behaves similarly: immediately after enabling FakeDNS, an app may continue using a previously cached real address and show no effect for a short time.

If one app fails immediately after FakeDNS is enabled while others work, temporarily exclude that app to create a comparison. If it recovers, check whether it has its own DNS, caches addresses for a long time, depends on local discovery, or validates the actual address at the application layer. Do not delete all domain routing because one app is incompatible. A better approach is to give that app a real-resolution path while allowing other apps to benefit from domain mapping.

Define a role for every source

Multi-subscription management is not about importing every link into one list. Each source needs a clear role: the primary subscription handles daily use, the backup is enabled only when the primary has problems, and the testing subscription validates new protocols or transport parameters. The role determines update frequency, filtering, and whether the source participates in automatic selection. If all three sources are mixed, it becomes difficult to identify the source of a failure and easy to select the wrong server when names match.

Name sources by purpose rather than personal information, for example “Primary | Daily,” “Backup | Manual update,” and “Testing | Temporary.” In v2rayN, use subscription groups to preserve source boundaries. In v2rayNG, limit the number of groups and use clear aliases to reduce switching on mobile. When v2flyNG is used as an alternative Android client, apply the same source-naming principle, but do not assume that both clients preserve identical local group structures.

Automatic updates need failure protection

Automatic updates receive source changes promptly, but they can also damage the current list when a subscription temporarily returns empty or malformed content. A reliable process keeps the last usable result and stops overwriting when the new result is clearly abnormal. Confirm this behavior from the actual client interface and logs; when uncertain, update the primary subscription on a fixed schedule and update backup and testing subscriptions manually. This reduces unnecessary requests and prevents every source from changing at the same moment.

Stagger update schedules. For example, check the primary daily, check the backup manually before switching, and update the testing source only during experiments. After an update, inspect the entry count and selected item before running bulk latency or connection tests. Testing only shows reachability at that moment and does not replace checking protocol parameters. If many entries fail at once, inspect the subscription format, system time, and local network before deleting entries one by one.

Deduplicate by more than display name

Two subscriptions may use the same remark while differing in server address, port, user identifier, transport, or security settings. A true duplicate requires comparing the key connection parameters. Conversely, the same configuration may have different names in different sources. Deduplicate only after preserving source boundaries, then choose one stable source for entries confirmed to be identical. Do not merge entries from different subscriptions into untraceable local copies, or later parameter changes will not sync automatically.

To keep devices consistent, share subscription links and a small amount of standardized configuration rather than the full client state. Desktop window layout, latency results, the selected item, and Android per-app lists are device-local information and should not be forced into sync. The shareable layer includes subscription sources, standard protocol parameters, and general routing concepts; each device should maintain its own system proxy, TUN, app selection, and local DNS. See a comparison of subscription links, QR codes, and exported configurations for more options.

Limits of QR codes and exported files

QR codes are useful for quickly moving a single configuration between your own devices. After scanning, verify that the protocol, address, port, transport, and security fields are complete; do not rely only on the remark. QR codes are not suitable for a multi-subscription system that changes over time because they do not update automatically after creation. For long-term maintenance, use a subscription link; for one-time migration or offline storage of a few test configurations, a QR code is more direct.

Exported configuration files can preserve more fields, but they may also contain paths, ports, and local rules specific to the current device. Before importing to another platform, read the contents, remove settings that do not apply, and never place files containing access credentials in a public location. After migration, establish a single-connection baseline on the new device before restoring routing and DNS. Moving every advanced desktop setting to Android at once puts differences in permissions, network entry points, and app selection into the troubleshooting scope simultaneously.

Keep change records and rollback points

A multi-subscription setup benefits most from a simple change log. It does not need to be elaborate—record the date, modified object, previous state, new state, and verification result. For example: “Added an exclusion to the primary subscription,” “Switched the backup to manual updates,” or “Imported only the primary source on Android.” When the list behaves unexpectedly, you can quickly identify the latest change. If configuration includes connection credentials, record only the type of change and never copy complete sensitive fields.

Build rollback points around a state that is known to connect. Keep the old expression before changing filters, note the currently usable entry before bulk updates, and preserve the original group before importing new configuration. If a connection fails after updating, restore the selected item and filters before evaluating the new subscription content. Do not roll back a subscription while also changing DNS and TUN; reverting several layers at once may restore service by chance without revealing the cause.

Primary-to-backup switching procedure

A backup subscription only provides real backup value when it is tested regularly. Testing does not require a permanent connection: manually update it on a stable network, select one configuration, test the connection, and confirm that basic DNS and routing work. Switch back to the primary subscription afterward so the selected item does not accidentally remain on the testing source. If primary and backup use different protocols or transports, record the system requirements for each so you do not discover during an outage that the backup depends on a disabled feature.

When the primary source has problems, first determine whether the subscription update failed or an existing server connection failed. A temporary update failure does not immediately invalidate configurations already imported; keep the current list and continue testing. Switch to the backup only when the server connection also fails. Conversely, if the update succeeds but the list is empty, disable filters and inspect the raw content before treating a local filtering error as a source outage.

Outbounds are the execution targets of routing rules

Routing rules make decisions; outbounds establish the actual connections. A basic setup usually includes proxy, direct, and block outbounds. The proxy outbound carries the current server connection, the direct outbound uses the local network, and the block outbound rejects unwanted connections. Custom outbounds add another exit, such as a specified SOCKS upstream, a separate direct-access policy, or a particular protocol connection. Each outbound should have a unique, stable tag, and routing should reference it by that label.

Name labels by function, such as proxy, direct, block, and upstream-socks. Avoid names like “Line 1” or “Test 2” that lose their meaning outside the current interface. When changing a label, update every routing rule, DNS outbound reference, and chain relationship at the same time. Changing only one location may make the configuration fail to load or cause unmatched traffic to fall through to the default exit.

Build a reviewable base structure

Start custom configuration with the three basic outbound types, confirm that logs show each label, and only then add an upstream. Direct access uses the freedom protocol, blocking uses blackhole, and the proxy outbound is generated by the client or supplied by the subscription. When editing a complete core configuration directly, remember that the client may regenerate it at connection time. If the interface offers a custom-configuration entry point, use its supported override or merge mechanism instead of editing a temporary file that will disappear at the next connection.

Example of basic outbounds and a SOCKS upstream

{
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {
        "response": {
          "type": "none"
        }
      }
    },
    {
      "tag": "upstream-socks",
      "protocol": "socks",
      "settings": {
        "servers": [
          {
            "address": "127.0.0.1",
            "port": 1081,
            "users": [
              {
                "user": "example-user",
                "pass": "your-password"
              }
            ]
          }
        ]
      }
    }
  ]
}

The local SOCKS service in the example must actually be running at the specified address and port, or connections routed to that outbound will fail immediately. If the upstream needs no authentication, remove the user field according to the core’s supported format instead of keeping an empty string. When connecting to a remote upstream, ensure its address is not captured by the same outbound and sent into a loop. Keep access credentials only in your own controlled configuration, and remove them before sharing troubleshooting screenshots or logs.

Make the direction of chained proxies explicit

A chained proxy means that one outbound establishes its underlying connection through another outbound. This suits networks with a clear topology requirement, but adds latency, failure points, and log complexity. Draw the order before configuring it: application traffic enters the client, routing selects a business outbound, and that outbound connects to the target through an upstream exit. Every layer in the chain must be independently reachable, and the upstream connection must not return to the business outbound.

When verifying a chain, test the outermost upstream by itself before adding the inner connection. If the upstream is a local SOCKS service, use a tool with clear SOCKS support to confirm the port works. If the upstream is another client outbound, start with one precise route for a test domain. After the logs confirm both labels in the expected order, expand the matching scope. Switching all default traffic to an unverified chain can simultaneously remove the connections needed for queries, updates, and troubleshooting.

DNS traffic needs an outbound too

After adding a custom outbound, DNS requests may still use their previous path. If target access uses upstream-socks while remote DNS uses direct access, the resolution location and access exit may differ. Whether they need to match depends on the scenario, but it must be an intentional design rather than an accident. Add a precise route for the DNS endpoint so it uses a specified outbound, or keep internal DNS on direct access. After changing it, verify that the DNS endpoint connection and target connection hit the expected labels separately.

Prevent DNS loops: if an upstream outbound’s server address is a domain and the DNS used to resolve that domain is routed through the same upstream, the upstream may depend on itself before it is established. Solutions include reliable bootstrap resolution for the upstream address, using an explicitly reachable address, or giving its DNS queries a separate direct path. The choice depends on the network; the essential requirement is that the base connection needed to establish the upstream must not depend on the upstream itself.

Block outbounds and failure symptoms

A block outbound explicitly rejects unwanted connections. It may look similar to an ordinary connection failure, but the log should show that traffic matched the block label. When a target cannot be reached, first check whether a block rule captured it, especially when broad domain suffixes or port conditions are involved. Place block rules at an appropriate priority and keep their scope explainable. An overly broad rule can reject normal resources, login flows, or client update requests as well.

Blocking may silently drop traffic or actively return a rejection. Applications respond differently: silent drops often appear as timeouts, while active rejection usually fails faster. Choose the method that minimizes pointless waiting and preserves application compatibility. Do not replace clear per-app and routing design with blocks for large numbers of unknown targets; the harder rules are to explain, the higher the maintenance cost.

Boundary between generated and hand-written configuration

v2rayN, v2rayNG, and v2flyNG all generate the core’s runtime configuration from interface settings. Manual examples explain field relationships but do not mean every client accepts a complete JSON pasted directly. If a client supports custom configuration import, first confirm whether it expects a complete configuration, a partial override, or a single outbound fragment. Even valid JSON may fail to start when its structure does not match what the client requires.

Before upgrading or switching clients, record which settings come from the subscription, which come from the client interface, and which are manual overrides. Subscription server parameters can usually be retrieved again, while complex custom outbounds and routing need separate backups. After backing up, inspect label references in the text: every outboundTag should correspond to a real outbound, every chain reference should have a target, and every DNS route should be able to complete required resolution before the upstream is established.

Roll out from the smallest rule set

When launching a custom outbound, bind one dedicated test domain to the new label and leave all other traffic unchanged. Confirm in the logs that the connection reaches the new outbound, DNS follows the correct path, and no loop occurs before expanding the domain set or app scope. Record every expansion and keep the new rule easy to remove. If it fails, roll back only the most recent layer rather than resetting verified subscriptions, servers, or basic routing.

The final configuration should answer four questions: which rule matches each traffic class, which outbound that rule selects, how that outbound establishes its underlying connection, and where the DNS needed to establish it goes. If any step can only be guessed, the configuration is not ready for long-term use. For complex failures, restore the three basic structures—proxy, direct, and block—then add custom exits one at a time. To choose a client suited to your platform, see the selection guide and installation packages page.