V2Ray Advanced Configuration Guide

Subscription Groups and Server Filtering

Keep subscription sources, displayed lists and active servers separate

A subscription group is a container for server entries managed by the client. It is not a routing group, and it does not automatically assign a particular node to an app. The subscription URL supplies entries, the group organizes them, and the currently selected server determines the destination for ordinary proxy traffic. Keep these three layers distinct to avoid assuming that changing groups also changed your exit route. After switching lists, select a server and confirm the client has applied the new active configuration.

In v2rayN, open the subscription group settings and create a separate group for each source. Use names that indicate the purpose and a short source label, such as “Daily” or “Backup”; don’t paste the full subscription URL into the name. Add the URL and save, then update the relevant group. After the first update, check that server names, protocol types and transport settings were recognized. If the list is empty, review the update log rather than repeatedly adding the same URL and creating more empty groups.

Filtering narrows the list; it does not verify connection quality

Server filters narrow the entries that are visible or imported. Exactly where they apply depends on the client: some filter the current list, while others filter entries during subscription updates. Check what each option does before changing it, and keep an unfiltered group as a reference. Region, route type and traffic multipliers usually come from provider naming; they are not facts independently measured by the client. A region in a server name alone does not confirm the final exit location.

Start with ordinary keyword search and confirm that the expected entries appear before trying a regular expression. Use the expression below only in a field explicitly documented as supporting regex. It matches entries whose names contain “Hong Kong” or “Singapore”; change the terms if your provider uses different names. Don’t paste it into a plain-text search field: the pipe and parentheses may be treated as literal characters, leaving no results.

(Hong Kong|Singapore)

To check a filter, turn it off to view all entries, then apply it and compare the results with what you expect. An empty result may be caused by case, full-width characters, hidden spaces or naming changes—not a broken subscription. If you use both include and exclude terms, check that they don’t cancel each other out. For complex conditions, add them one at a time. A long expression written all at once is harder to troubleshoot and maintain.

Keep recovery information when updating subscriptions

A remote update may replace the server entries in a group, and locally edited notes or settings may not be preserved. Keep custom servers you need long-term in a separate manual group. Before updating, note the active server’s group and recognizable name, but don’t assume the entry order will stay the same. Providers may rename entries, remove routes or change sorting; choosing a server by its position can leave you on the wrong one after an update.

If a subscription update fails, first determine whether the URL could not be fetched or the response could not be parsed. For a fetch failure, check the URL, your current network and whether updates use a proxy. For a parsing failure, confirm the response is subscription data—not a login page, expiry notice or error page. If updates use a proxy, you need an active node that still connects. When every node is unavailable, this can create a dependency loop; try another update method allowed by your current network.

When importing into v2rayNG or v2flyNG, check the groups and active server again. Clients may handle notes, sorting and filters differently, so a desktop list does not prove the same state has synced to your phone. Subscription URLs often contain access credentials; don’t share them in public chats after copying. When asking for help, share only a sanitized error summary—never paste the full URL into comments or screenshots.

Routing Rules and Priority in Practice

Set the default route first, then add exceptions

Routing sends connections that have already reached the core to an outbound. It does not automatically capture app traffic or act as the system proxy toggle. Rules are generally evaluated in order; the first matching rule determines the path. If nothing matches, the configured default outbound applies. Before making changes, decide whether the default should use the proxy or go direct, then put a small number of exceptions first. Otherwise, a broad rule can prevent more specific rules later in the list from ever taking effect.

v2rayN’s preset routing modes are a useful starting point, but avoid stacking several presets together. Choose the one closest to your needs, then inspect the actual entries in the routing settings. Private network addresses, specific domains, regional lists and fallback rules should form clear layers. Bypassing the proxy server’s own connection is especially important; with TUN enabled, prevent that connection from being captured again. The client may handle some exceptions automatically, so check its current behavior before changing anything.

Domains, IP addresses and rule sets match differently

full: matches a single exact domain; domain: matches a domain and its subdomains; regexp: enables regular-expression matching; geosite: references a domain list. The ip field in address rules can use a single address, a subnet or a supported address set. Set names are not a fixed promise of built-in coverage; availability depends on the current data files. Check that the relevant file exists and the entry name is correct before using it.

This snippet routes the example domain and its subdomains through the direct outbound. It demonstrates routing structure only; before merging it into your configuration, check that an outbound with the same tag already exists. Replace the example domain with the actual destination that should go direct, but don’t enter a full webpage URL. Protocol prefixes, ports and paths do not belong in this domain-matching field. When adding the same kind of rule in the GUI, select the domain condition and target outbound separately.

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["domain:example.com"],
        "outboundTag": "direct"
      }
    ]
  }
}

How are multiple conditions combined?

Different condition fields in a rule usually all need to match, while alternatives within the same list usually match any one of the listed options. So putting a domain, port and network type in one rule narrows the match; it does not create separate rules for three kinds of traffic. Split distinct scenarios into separate rules to make them easier to validate. If a domain rule fails to match, check not only its position but also whether it includes a port or inbound condition that doesn’t fit the actual request.

A domain rule can match only if the core has the domain name. Explicit proxy requests may include it; transparent traffic may expose only the destination address, requiring sniffing or a FakeDNS mapping to recover the name. domainStrategy also controls when addresses are resolved for routing. It is separate from the DNS module’s query strategy. Resolving earlier does not guarantee more accurate routing; it can add delay and change which address rules match.

Validate rules against a specific destination: note the expected outbound, start a new connection, then check the destination and outbound tag in the logs. Browsers may reuse an existing connection, so refreshing a page after a rule change may not trigger a new route. Close and reopen the relevant app if needed. If the result is wrong, temporarily move the target rule earlier to test it. Once confirmed, put it in a sensible position rather than leaving it at the top to mask overly broad rules elsewhere.

DNS Configuration and Resolution Paths

Map out what resolves each name and where the query goes

A connection may involve resolution by the app, the operating system, the client’s built-in DNS or the proxy server. Entering a remote DNS server in the client does not mean every app query will use it. Browser Secure DNS, app-specific resolvers and system caches can all bypass the expected path. Before troubleshooting, note the test app, how its traffic is captured and the target domain. Don’t interpret queries from different layers as if they were the same. A website’s exit IP alone cannot prove that DNS is working as intended.

Direct and remote DNS describe different uses, not simply different locations. Direct destinations need answers suitable for local access; proxy destinations need answers compatible with the proxy route. Where answers vary by region, a mismatched resolution path may lead a content delivery network to select a route that doesn’t fit the actual exit. Establish a working baseline with the client’s default settings, then split resolution by destination. Don’t start by enabling several resolvers, complex fallbacks and special query strategies at once.

Check query strategy and routing strategy separately

This core DNS snippet uses public resolver addresses and prefers IPv4 results. It shows where servers and queryStrategy go; it is not a recommendation for every network. Test whether the public resolvers are reachable in your environment. This snippet does not capture system DNS, guarantee that queries go through a proxy or replace the client’s configuration of the DNS outbound path.

{
  "dns": {
    "servers": ["1.1.1.1"],
    "queryStrategy": "UseIPv4"
  }
}

UseIPv4 affects the results selected by this DNS module. It does not disable IPv6 in the operating system or stop apps from getting IPv6 addresses through other resolvers. If your network has full dual-stack support, choose the appropriate strategy once you understand its behavior. If only certain IPv6 connections fail, first check whether the cause is system routing, the proxy outbound or the server path. Disabling an entire address family may hide the real configuration issue rather than fix it.

The routing domain strategy and DNS query strategy operate at different layers. The former determines when the target is resolved for routing; the latter determines how the DNS module queries. When routing by domain lists, try to evaluate domain rules before resolving addresses, then resolve only connections that need address-based conditions. Resolving every request early may cause IP rules to affect destinations you intended to handle by domain. After changes, check both the matching domain and the final connection address—not just whether the webpage opens.

Encrypted DNS still needs a reachable network path

Encrypted DNS protects queries in transit, but the resolver itself still needs a connection. If the resolver is specified by hostname, its address must be resolved first. If its connection goes through a proxy, the proxy server’s hostname may itself depend on DNS that is not yet working. This circular dependency can leave the client running while every new domain request times out. Establish a clear bootstrap resolution path, and confirm the proxy server address can be resolved independently or handled correctly.

Interpret client options such as “query through proxy” and “remote DNS” in the context of the current core and generated configuration. Don’t assume from the label alone that all queries use a particular outbound. If resolvers are selected by domain, also check which server handles unmatched queries, whether failures trigger a fallback and whether that fallback changes the intended path. Adding more resolvers does not necessarily improve reliability; it can also produce inconsistent answers for the same domain.

To validate, choose a common domain and note the system’s query result, then start a new connection in the target app. A terminal lookup reflects the resolver path used by that terminal tool; a browser may use Secure DNS instead. After changing settings, wait for caches to expire or clear the relevant cache if you understand the scope. Don’t switch server nodes between every test: changing the exit and DNS at the same time makes it impossible to tell which change affected the result.

Check local device names, company domains and LAN services too. They may be resolvable only by a LAN DNS server; sending every query to a public resolver can make printers, internal sites and development environments unreachable. Preserve the appropriate resolution path for names that belong to your internal network, without treating every unknown domain as local. If your environment uses search suffixes, test short names and fully qualified domain names separately to confirm the client preserves existing resolution behavior.

TUN Mode and System Traffic Capture

System proxy and virtual adapters solve different problems

The system proxy provides an entry point for apps that honor system proxy settings; whether an app uses it depends on its implementation. TUN captures traffic through a virtual network interface and system routes, bringing more apps that ignore system proxy settings into the processing chain. It is not simply a “normal” or “accelerated” mode. If websites already work, consider TUN’s permissions and compatibility only when you need to capture traffic from other apps or protocols.

v2rayN’s TUN feature may depend on a supporting network-stack component; follow the client’s interface and the generated configuration for the actual implementation. Using Xray for the proxy outbound does not mean you can add arbitrary TUN inbound fields to the Xray configuration. The core, capture component and GUI client each have separate responsibilities. Before enabling TUN, read the current client’s option notes, confirm the required components are ready, then check permissions, virtual adapter creation and system route installation.

Enable TUN by itself first; troubleshoot conflicts afterward

First confirm that the ordinary proxy works. Then close other tools that may capture system traffic, save your work and enable TUN. For the first test, don’t change DNS, routing and the server at the same time. If the client requests elevated permissions, grant the required access through the system prompt rather than repeatedly clicking the toggle. Check the logs and distinguish interface creation failures, route installation failures and proxy connection failures; they occur at different layers and require different fixes.

Android clients capture traffic through the system VPN service, so desktop virtual-adapter troubleshooting steps do not apply directly. Other apps using the VPN service may conflict in the same user environment. If you use per-app proxying, confirm that the target app is included. System background restrictions may interrupt connections when the screen turns off; first note when disconnections happen, then adjust the necessary background settings. Don’t attribute every intermittent drop to server quality.

Routing loops and LAN access

After TUN captures traffic, the proxy server’s own connection needs a correct bypass route. If that connection is sent back into the virtual interface, it can create a loop, causing repeated reconnections, high resource use or a complete loss of connectivity. Clients generally handle the necessary bypass, but custom routes, other network tools and manual system routes can interfere. If this happens, disable TUN to restore the baseline, then check the proxy destination and system routes. Don’t keep adding exceptions at random.

Test LAN destinations separately. Start with the router’s management address, then check file sharing, printers and internal domains. Excluding private IP ranges only changes the connection path; it may not resolve internal names. Conversely, a correct DNS answer does not mean system routing will send traffic directly. If devices use multiple subnets or an enterprise VPN, check that your exclusions don’t overlap with the other network. Broadly excluding an entire range may affect unrelated traffic.

UDP availability depends on the capture component, core configuration, node protocol, server support and the complete route to the destination. The TUN toggle alone cannot guarantee it. A successful webpage request also says nothing about real-time communication or other UDP services. Test with the actual target app and check whether failures occur only on certain networks. If TCP works but UDP doesn’t, start with protocol support and relevant logs instead of repeatedly changing system proxy settings.

Retest after switching networks. Moving from Wi-Fi to Ethernet, resuming from sleep or joining a corporate network can change the default gateway, interface priority and DNS. If the client doesn’t rebuild routes correctly, the old state may keep affecting connections. Stop capture, enable it again and check whether interface status recovers. Don’t delete every virtual adapter on the system without checking first; this may break other legitimate network tools and make recovery harder.

FakeDNS Mapping and Domain Recovery

A virtual IP is a mapping key, not the destination server

FakeDNS returns a managed virtual IP for a queried domain and stores the association between them. When an app connects to that address, the capture chain uses the mapping to recover the domain, allowing later routing or proxy connections to use the hostname. This is not the website’s real IP or an actual public-network exit. If an app receives an address from a special range, don’t immediately assume DNS is broken. Check that the mapping is recovered correctly and that the real connection uses the expected outbound.

FakeDNS is suited to setups where both DNS resolution and the subsequent connection can be controlled. If the query reaches FakeDNS but the connection bypasses the client, the app gets a virtual IP it cannot use as intended. If the connection reaches the client but another resolver handled the query, there is no corresponding mapping. Before enabling FakeDNS, validate TUN or another transparent capture method. Explicit proxies that already pass domain names may not need this extra layer; each additional component adds state to maintain.

Coordinate the address pool, DNS service and sniffing

This example shows how a core that supports the relevant fields can define an address pool and use FakeDNS as its DNS service. It is only a partial configuration; it is useful only with an inbound that supports mapping recovery, correct routing and DNS capture. Don’t add it to a network-stack configuration that doesn’t support these fields. If the client already generates FakeDNS settings, use its interface options to avoid activating both manual and automatic configuration.

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

The example address pool uses a range reserved for benchmarking; that does not mean it is unused in every environment. Some corporate networks, test environments and other capture tools may use it too. Check local routes and existing configuration before enabling it to avoid overlap. Pool capacity manages mapping resources; bigger is not necessarily better, and it does not represent the number of connectable nodes. Capacity relates to resource use and the number of active domains, so don’t treat the example value as a performance recommendation.

For an inbound that supports FakeDNS sniffing and recovery, merge the following sniffing field into the existing inbound object. This shows the field structure only; it does not add a listening address or port. If your capture component uses a different configuration format, follow its own implementation. Enabling sniffing alone does not capture DNS or recreate a mapping that has already been lost. During validation, observe the query, virtual IP and subsequent connection as one continuous process.

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

Limits of caching, restarts and mixed resolution

FakeDNS mappings are usually runtime state. After the core restarts, an app may still have a cached virtual IP even though the new process no longer has its mapping. This can make some apps fail until reopened. To troubleshoot, close affected apps and their existing connections, clear the relevant DNS cache if needed, then query and connect again. Don’t immediately change the entire address pool: old cached addresses and new mappings could coexist, making the cause harder to identify.

Browser or app-specific encrypted DNS may bypass FakeDNS, so different apps can receive different types of address. That doesn’t necessarily mean the whole configuration has failed, but it does mean one app’s result cannot represent the entire system. If you want consistent domain-based routing, check each app’s DNS settings and capture coverage. If an app must use its own resolver, determine whether there is another way to identify its domain, and account for the possibility that it can only be routed by IP.

Don’t blindly return virtual IPs for LAN services either. Internal names may depend on a LAN DNS server’s search suffixes and special records, and some apps compare resolved addresses directly. First establish a working resolution path for internal domains, then send suitable external destinations to FakeDNS. Diagnostic tools that need real IPs, IP-based access controls and some device discovery features all need separate testing; browsing a webpage alone does not cover every use case.

When disabling FakeDNS, also remove the DNS service selection, mapping recovery settings and related routes, then let apps obtain real DNS results again. Disabling the address pool while keeping a resolver that returns virtual IPs leaves a partial configuration behind. After rollback, confirm ordinary domains resolve to the expected real addresses and existing routing still works. If the issue occurs only with FakeDNS enabled, keep the ordinary DNS baseline and check each layer instead of blaming an unavailable node.

Managing Multiple Subscriptions and Update Policies

Separate sources first, then organize by purpose

Don’t simply merge multiple subscriptions into one enormous server list. Different sources may have different update schedules, naming conventions and availability. Create a separate group for each source, then use search or filters for everyday selection. If one source has an update problem, you can disable or reimport it without affecting the others. Use group notes for purpose labels, but don’t treat a provider’s marketing claims as verified capabilities.

A subscription URL and a server share link are different types of information. A subscription URL retrieves a list of entries over time; a server link usually describes one server. Pasting a single-server link into a subscription update field may cause a parsing error, while importing subscription data as a single server can lose its management relationship. Check the content type before choosing an import option. Once tested, record the source’s purpose and last check result; don’t store a full URL with access credentials in a public note.

Automatic updates need a working retrieval path

Automatic updates require the client to be running, the scheduled task to execute, the subscription service to be reachable and the request to use the right network path. They won’t continue while the system is asleep or the client is closed. Choose an update interval that fits the provider’s request limits and your needs; don’t refresh too often. If you hit a temporary rate limit, repeated manual attempts only add more requests. Check the error type, try again later and keep your currently working entries.

If updates use a proxy, make sure the active node does not depend on that update to recover. You can keep a tested backup source, but test it separately; its presence in the list alone does not prove it works. If the update service is reachable over a direct connection, test that route first. Avoid circular dependencies: retrieving the node list, resolving the proxy server and establishing the proxy connection should not all wait on a step that is not yet available.

After an update, check what actually changed rather than relying on the success message. Confirm the active server still exists, its name has not changed unexpectedly, its protocol settings remain intact and filters have not drastically reduced the list. If a provider removes an entry, the client may not choose a suitable replacement automatically. Select a new server manually and establish a fresh connection. Long-running apps may keep using the old route until their connections are rebuilt.

Servers that look alike are not necessarily safe to delete as duplicates

Different subscriptions may show the same server name, or different names for the same service. Check the protocol, server address, port and transport settings instead of comparing notes alone. Even when the technical settings match, entries may belong to different management sources; whether a deleted entry returns on the next update depends on how subscriptions are managed. Use groups and filters to reduce clutter rather than bulk-deleting entries you have not confirmed.

Keep manually adjusted servers separate from remote subscription entries. If you need to change a transport setting, first confirm it is allowed, then copy the entry to a manual group and label its purpose. The copy won’t follow later changes to the remote source, so review it yourself. Keeping a copy is not a substitute for proper updates; it gives you control over test variables. Remove unused copies after testing so you don’t accidentally select an outdated configuration later.

Desktop and mobile clients can import the same source, but that does not make filters, active servers and routing settings identical. v2rayN, v2rayNG and v2flyNG may differ in subscription formats and parameter support. An entry working on one client does not prove full compatibility on another. When troubleshooting across devices, align the protocol and transport settings first, then test each client separately. Don’t send a full configuration containing credentials just to compare screens; share sanitized field names if needed.

Before exporting a backup, decide what it contains. Server settings, subscription URLs and credentials may all be sensitive; store backup files somewhere access is restricted. After restoring to another device, check local listening ports, network adapter permissions and system proxy state again—copying a subscription cannot reproduce those environment settings. When retiring an old device, remove configurations you no longer need so account information does not remain in an unused client directory.

Custom Outbounds and Configuration Boundaries

Outbound tags are the connection points for routing

An outbound defines how traffic leaves the core, and routing selects it by tag. A tag is only a local reference name; it cannot identify a protocol or region automatically. Naming an outbound “direct” does not make it connect directly—the object’s protocol and settings determine its behavior. Before adding an outbound, list the existing tags, check for duplicates and confirm that routing points to the intended object. A misspelled tag may fail configuration checks or prevent the expected route from working.

A standard client configuration usually already defines proxy, direct and block outbounds. If you only want a domain to go direct, add a routing rule instead of creating another outbound that does the same thing. Custom outbounds are useful when traffic genuinely needs a different connection method, such as forwarding selected requests to a controlled local proxy. Even then, confirm that the client can merge custom fields and that switching servers will not overwrite your changes.

Understand the structure with clear, basic objects first

This snippet shows basic direct and block outbound objects for cores that support these protocols. It does not include a proxy server and cannot replace a complete client configuration. If an outbound with the same tag already exists, don’t add another. Also note that traffic unmatched by routing may use the first outbound. Replacing the existing array with this example could change the default route from proxy to direct.

{
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ]
}

A block outbound is for explicitly rejecting certain connections, not for fixing network problems. During testing, routing a broad set of domains or addresses to it can make pages appear to fail at random because some resources are missing. Start with one target and expand the scope only after testing. A direct outbound does not bypass every system setting either; it is still subject to operating-system routes, firewalls and underlying network conditions. Selecting an outbound only means the core has decided on a path.

Avoid self-references when connecting to another local proxy

If traffic needs to pass through another local proxy, first verify that service is listening and check its protocol, address, port and authentication requirements. Whether it listens on the loopback address or a LAN address determines who can connect. Don’t expose it on every network interface just for convenience. If LAN access is necessary, also configure the system firewall and access controls so you don’t expose a local-only service to unrelated devices.

The most common mistake is configuring a custom outbound to connect back to the current client’s own proxy listener. If the connection re-enters the client and selects the same outbound, it creates a loop. Matching port numbers do not prove that the services are the same, so check the listening process and the full traffic path. For a proxy chain, map every hop and identify which layer resolves domains, handles UDP and establishes the final connection. The longer the chain, the more important it is to validate each hop.

Proxy protocols handle domains, UDP and authentication differently. An upstream that supports ordinary web proxying does not necessarily support every kind of app traffic. If a local upstream accepts only certain requests, limit routing to uses you have tested. Don’t paste an outbound object from another component directly into the current core; similar field names do not guarantee compatible formats. Confirm the core name and documentation first, then use configuration checks and startup logs to see whether the object was accepted.

The client may regenerate its runtime configuration after changing servers, updating subscriptions or editing routes. Hand-added outbounds in temporary files may disappear. Use a custom configuration entry point explicitly supported by the client, and note whether it appends objects or replaces an entire field. A complete custom configuration may also prevent GUI features such as active server selection from working normally. Check this boundary before changing settings; the interface may appear to switch servers while the client keeps running a fixed configuration.

To validate a custom outbound, first route just one test domain through it. Check the log for the outbound tag and upstream connection, then expand the scope gradually. If it fails, check in order whether the rule matched, the upstream listener is reachable, authentication is correct and the domain resolves. Don’t change every layer at once. To roll back, remove the test route, delete outbounds that are no longer referenced, then confirm the default proxy and direct rules still have their original order and behavior.

Configuration Validation, Troubleshooting and Rollback

Validate “starts successfully” separately from “works as intended”

Passing a configuration check only confirms that the structure and some fields meet core requirements. It does not prove that the subscription service is reachable, the proxy node works or routing is correct. A full validation should cover client startup, core operation, traffic capture, routing matches, DNS resolution and real-world use in sequence. Each layer needs its own evidence; one successful webpage cannot stand in for all of them. TUN and FakeDNS involve system state and runtime mappings, so they require especially careful checks at each layer.

Before making changes, record a baseline: client and core in use, active server, system proxy state, TUN state, routing mode and one known-accessible test destination. Note setting names and behavior; don’t publish server addresses or credentials. Write one clear goal for the change, such as “send a specific domain direct.” The more specific the goal, the easier it is to validate. “Optimize the network” is too broad to tell whether a change actually helped.

Choose the shortest troubleshooting path for the symptom

If the client won’t start, first check the runtime environment, directory permissions and configuration loading; don’t keep changing DNS. If the client starts but the core exits, inspect recently changed fields and tags, as well as port conflicts. If the core is running but apps do not use the proxy at all, check system proxy settings, app configuration or traffic capture coverage. Routing and outbound analysis matters only after traffic reaches the core. Investigating the right layer is usually more effective than reinstalling everything.

Interpret latency tests and real connection tests separately. A test may probe only one destination using a specific request type; it cannot represent every protocol or service. After a successful test, visit the actual destination and confirm the exit and route are as expected. If one site fails, check its associated domains and connection types before deciding the entire proxy chain is down. If the main page loads but images or sign-in fail, check how those resources are routed.

Start reading logs with a timestamp and a single request. Note when you run the test, then find the corresponding destination, inbound and outbound tags. DNS failures, connection refusals, timeouts and authentication failures point to different causes. A refusal usually means the peer explicitly rejected the connection or nothing is listening on the port; a timeout may involve routing, a firewall or a slow remote response. If the logs lack detail, temporarily increase verbosity and restore it when done to avoid accumulating sensitive destination information.

Roll back in dependency order

If the change affected several layers, stop creating new connections first. Remove the outermost capture or new routing rules, then restore the DNS and outbound baseline. When disabling FakeDNS, also remove mapping-related settings and clear affected app caches as described above. If TUN is causing problems, restore ordinary system networking before testing the client proxy. Don’t leave broken capture enabled while repeatedly switching servers; that won’t restore connectivity and only adds variables.

Test again after rollback; don’t stop just because a toggle is off. Confirm that the client stopped the relevant core or reloaded the correct configuration, the system proxy points to an active listener, and both ordinary web access and LAN access work again. If proxy settings remain after the client exits, check the system network settings instead of starting another client to mask the old listener. Only reintroduce the failed setting once the baseline works again, and keep the change as small as possible.

When asking for help, include the client name, platform, core, minimal reproduction steps and a sanitized error summary. Don’t send subscription URLs, credentials, full server configurations or logs containing private domains. Check the address bar, QR codes and clipboard prompts before sharing a screenshot. For clients that exit on startup, see how to fix v2rayN startup failures and crashes; don’t conflate startup issues with connection problems.

A stable configuration should be explainable, testable and recoverable. A few necessary subscription groups, a clear routing order and a DNS path suited to your network are easier to maintain than an ever-growing set of toggles. On a new device, establish a connection using the Getting Started Guide, then migrate rules you understand. For terminology, see the concept reference. Add one capability at a time and keep it only after confirming its benefits and limits; the guide can then serve as a repeatable reference.