V2Ray Advanced Configuration
Subscriptions, Routing & DNS

Configuration Layers & a Known-Good Baseline

Separate the client, core, and operating system

A successful connection depends on more than server settings. The graphical client stores subscriptions, the active server, and interface options, then generates a configuration the core can read. The core handles inbound listeners, routing, name resolution, and outbound connections. The operating system determines whether application traffic reaches the client in the first place. When troubleshooting, identify which layer is failing. For example, a browser that ignores the system proxy points to a traffic-entry issue; a core error saying an outbound tag is missing points to a configuration reference. These call for different fixes.

In v2rayN, “Parameter Settings,” “Routing Settings,” and the system proxy option in the main window affect different parts of the connection. “Automatically configure system proxy” usually sets the proxy entry applications get from the operating system; it does not enable a virtual network adapter. “Enable Tun” adds a separate way to capture traffic. On Android, v2rayNG uses the system VPN interface to carry traffic, while “Routing Settings” controls how traffic is split after it reaches the core. “Bypass mainland China” may refer to different rule templates, so the same label does not guarantee identical generated rules.

Establish a repeatable baseline

Before making changes, preserve the working configuration. Note the client and core, active server, routing mode, system proxy status, and DNS-related options. If you back up or export settings, keep the file in a secure location: it may contain subscription URLs, connection identifiers, or credentials. Redact those details before sharing screenshots. Never post a full configuration containing credentials in a public forum, and include the steps leading up to an error rather than sharing only its final log line.

Choose three representative checks for your baseline: open a regular webpage in an application explicitly configured to use the proxy, reach a service you control on your local network, and test an application you use every day. Record whether each check succeeds, the error type, and the conditions—not just a single latency figure. A page loading in your browser does not prove other applications are being captured. Local network access working does not prove DNS queries are taking the intended path. Comparisons are meaningful only when you repeat the same checks before and after each change.

Change one variable at a time

A sensible order is to organize subscriptions first, then adjust routing and DNS, and only then enable TUN and FakeDNS. After each change, reconnect and repeat your baseline checks. If the client asks you to restart the core, confirm the logs show a fresh startup—not just that the settings window closed. Before switching cores, check protocol and security-setting compatibility, especially for options such as REALITY. See Xray vs. V2Fly core differences; similar names do not guarantee compatibility.

When something breaks, undo changes in reverse order: first disable newly added traffic capture or DNS features, then restore the routing template, and finally restore the original server. If the problem persists, check for leftover system proxy settings, network changes, and other VPNs. To update the client, choose the right platform on the download page, but do not change the client, core, and subscription all at once while troubleshooting. That obscures cause and effect and can turn a reproducible problem into an intermittent one.

Subscription Groups & Server Filtering

Group subscriptions by source, then by purpose

The main purpose of subscription groups is to keep sources separate. In v2rayN, open “Subscription Groups” and create a separate entry for each subscription URL, with a note that helps you identify it. Use the note for its source or purpose, never for passwords or the full URL. If you need different filters for subscriptions from the same source, use separate groups—but check that updates will not create confusing duplicates. Keep manually imported connections in their own group so they do not get mixed up with servers regenerated from subscriptions.

In v2rayNG, subscription URLs are usually managed under “Subscription Group Settings”; return to the main screen to update them. The available options and fields in v2flyNG depend on the version, so check the actual interface. Saving a subscription URL does not mean its servers have been downloaded, and a successful update does not mean a usable server is selected. After updating, check the active group, its list, and the selected server. If the list is empty, find out whether the source returned no content, the response could not be parsed, or a client-side filter excluded every entry.

Filters shape the list; they are not access controls

Server filters usually keep or exclude entries based on remark text, protocol, or other client-specific criteria. They affect what gets imported or displayed; they do not restrict which destinations applications can reach or create routing rules. A region name in a server remark does not prove the actual exit location or capabilities. Use filters to reduce clutter, not as a security boundary. When setting up a filter, leave it off until the full subscription parses correctly, then add one easy-to-check condition and review the result.

Depending on the client, filters may use plain keywords, regular expressions, or separate include and exclude rules. Read the field’s hint first; do not enter a regular expression in a field that accepts only literal text. If regex is supported, a vertical bar means “or,” parentheses group alternatives, and a dot matches any character by default. Escape a dot to match it literally. Check how the current client handles case sensitivity and whether inclusion or exclusion runs first—do not assume another client behaves the same way.

(?i)(test|backup)

This example is for fields that support the corresponding regular-expression syntax. It matches “test” or “backup” without regard to case. It does not inherently mean keep or remove; that depends on whether the field is an include or exclude condition. Test it on a separate group before applying it to your only working subscription. Server remarks come from the provider and may change, so filters based on remarks can change too. If an important entry disappears, clear the filter and update again before considering a new source or plan.

Keep subscription updates separate from traffic routing

Updating a subscription is a network request too. If the client offers both “update through proxy” and a regular update, choose based on whether the subscription URL is reachable. If the current proxy is broken, using it to fetch a list that might fix the problem can create a dependency loop. Conversely, if the subscription URL is reachable only through the current connection, a direct update may fail. Test subscription updates and regular traffic separately; a webpage loading does not prove the subscription API is reachable.

After an update, check that the active server still belongs to the intended subscription. Some update processes recreate entries, so the previously selected item may no longer correspond to the new list. Confirm the protocol, transport, and security options are still present before selecting a server. If the client says it does not support a connection format, do not force an import by changing the file extension or stripping fields. Check whether the client and core support that format, then ask the subscription provider which output format it supplies.

If the list is empty, an import reports a format error, or an update fails with a network error, work through the subscription parsing troubleshooting checklist. Start by disabling filters, verifying the source and update path, then check the encoding and response content. Groups make configuration sources traceable; connection quality and protocol compatibility still need to be tested separately after selecting a server.

Routing Rules in Practice

Rule order matters more than rule count

Routing takes connection details received by the core and selects an outbound. In v2rayN, open “Routing Settings,” confirm the selected scheme in the main window, and then edit its rules. Xray and V2Fly commonly evaluate rules in order and use the first match. Within a rule, different fields usually act as constraints that must all match; entries within a domain or IP list can usually match any item. Putting a domain and a port in the same rule means both must match, not either one.

A practical order is usually: direct rules for local network traffic that needs them, service-specific rules, general category rules, and a default outbound for anything unmatched. Do not put an overly broad rule first or narrower rules below it may never be reached. Presets such as “Bypass mainland China” can be a starting point, but check which domain lists, IP ranges, and resolution policies the active scheme actually includes. A scheme’s name is not a complete description of its rules.

What domain rules and IP rules each cover

full: matches an exact domain, domain: matches a domain and its subdomains, geosite: references a domain category resource, and geoip: references an IP category resource. The snippet below shows direct routing for explicit domains and private addresses. It assumes the full configuration contains an outbound named direct. In a client’s rule editor, enter conditions in the appropriate fields rather than pasting the entire routing object into a domain field.

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "domain": ["full:example.com", "domain:example.org"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

The example domains here illustrate matching syntax only; replace them with the actual domains you need to manage. IP rules do not automatically cover domain rules: a domain may resolve to several addresses, or return different results on different networks. Conversely, domain-only rules may not identify applications that connect directly to an IP. For local network services, consider the connection method, DNS response, and virtual adapter routing together. Some service names also depend on local discovery protocols, which a domain rule alone cannot fix.

Routing resolution strategy is not DNS outbound policy

AsIs uses the available destination information as-is. IPIfNonMatch attempts DNS resolution when no domain rule matches, then continues matching IP conditions. IPOnDemand may resolve a domain when an IP-based rule needs an address. These strategies determine when routing needs address information; they do not specify which outbound carries DNS requests. Changing the resolution strategy and DNS servers at the same time makes failures harder to isolate. Keep the resolver fixed first, then compare how the strategy changes rule matches.

Sniffing can help identify domain information in supported traffic, but it cannot reliably recognize every protocol. Encryption, applications connecting directly to IP addresses, connection reuse, or missing metadata can all affect detection. After enabling sniffing, check whether the destination address is rewritten. If you only need more information for routing, see whether the active core offers a routing-only option. Sniffing does not guarantee that domain rules will match, and it cannot compensate for every missing DNS setting.

Use logs to confirm the rule that matched

After saving rules, reload the core, start a new connection, and check the outbound tag in the logs. Existing long-lived connections may keep using their old path, while browser caches and background connections can muddy the results; close and reopen the test app if needed. If a rule does not apply, first check the active scheme, then the rules above it, then whether the core sees a domain or an IP, and finally whether the category resource exists. A missing resource file usually causes an error at startup; repeated reconnects will not fix it.

Make the default behavior explicit too. In these cores, unmatched connections usually go to the first outbound in the full configuration; a graphical client may use that to set the default to proxy or direct. Do not infer the fallback from the rule list alone. If you need predictable behavior, use the client’s default-rule settings or define a final catch-all in a custom configuration. Also account for any special requirements for management traffic. See the glossary for terminology and troubleshooting for common connection issues.

DNS Configuration

Map the connection path and DNS query path separately

Start with three questions: which component sends the query, which one returns the answer, and which network path takes the query to the resolver? An application may use the system resolver or its own encrypted DNS. The core may also send queries for routing, connection targets, or resolver hostnames. Entering a remote DNS address in the client does not mean all system queries use it. First confirm whether application traffic reaches the client, then determine whether the core handles its DNS requests.

In v2rayN, look for DNS options under “Parameter Settings.” In v2rayNG, check “Enable Local DNS,” remote DNS, domain strategy, and related options under “Settings.” “Local” in the interface often means the client-side DNS module; it does not necessarily mean queries go only to your local network. Clients also generate configurations differently. After enabling an option, check the logs or generated configuration to confirm which servers and policies are in use rather than assuming the switch alone proves everything is working.

Three policies that are easy to confuse

This partial example shows a core DNS object that requests IPv4 addresses only and specifies a resolver. It does not define how DNS traffic is routed or mean the request automatically goes through a proxy. For encrypted DNS, also check the active core’s supported address syntax, certificate validation, and resolver entry point. If the resolver address is a hostname, find out which working resolver handles its initial lookup. Otherwise, you may create a loop where connecting requires a lookup that itself depends on that connection.

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

Choose a resolver path for each type of traffic

Internal domains usually rely on a router, enterprise DNS, or a search domain, so preserve the corresponding local resolution path. Sending every query to a public resolver may make internal services unreachable. For external services, aim for a sensible match between DNS results and the chosen outbound. If a destination uses region-based delivery, a resolver on a different network from the actual exit may return an unsuitable address. The goal is not to add more servers; it is to give each domain category a clear resolution and connection path.

Do not assume multiple DNS servers are queried one by one in list order. Depending on the core, queries may run in parallel or their results may be combined based on domain conditions; fallback support also varies. First verify a single stable resolver path, then add domain-specific servers and check that the default fallback covers everything else. If internal domains must not be sent to external resolvers, explicitly exclude them from public fallback rather than simply putting an internal address first in the list.

Troubleshoot cache, dual stack, and logs in order

After a DNS change, the application, operating system, or core may still have old results cached. Close and reopen the test app, flush the system DNS cache using the supported method, and restart the client core if needed. Do not switch resolvers after every failure; cached results make before-and-after comparisons unreliable. If the logs show a timeout, first check whether the query path is reachable. If an address is returned but the connection still fails, check the address family, routing, and remote connection instead of continuing to toggle DNS settings.

For IPv6 problems, distinguish between “got an address” and “completed a connection.” A network may return an IPv6 address without a reliable IPv6 exit or a correct virtual adapter route. Temporarily limiting the address family can help isolate the issue, but it is not a universal optimization. Conversely, IPv4-only queries may break connectivity on networks that depend on IPv6. Once you have diagnosed the problem, restore a policy that fits the network and verify with a new connection. Do not judge the entire DNS setup by the load time of a single page.

TUN Mode

Changing traffic capture does not invalidate routing rules

TUN uses a virtual network adapter and system routes to send matching IP traffic to the client. It is useful for applications that ignore the system proxy. TUN changes how traffic enters the client; it does not automatically send every destination through a remote proxy. Once traffic reaches the client, routing rules still choose whether it goes direct, through a proxy, or is blocked. “Enable Tun” and “Global proxy” are not the same thing. Even with broader traffic capture, preserve direct access to the local network, internal DNS, and any business-specific exceptions your setup needs.

When using v2rayN on desktop, first close other VPNs or virtual adapter tools that may control system routes. Then grant the permissions required by your platform to create an interface and change routes. The interface may show the mode as enabled even if permissions prevented the adapter or routes from being set up. Do not solve startup problems by leaving the firewall disabled. Check the client and system logs to identify whether permission was denied, interface creation failed, or route installation failed, then make the smallest necessary system change.

Move from system proxy to TUN step by step

Before enabling TUN, verify the current server through a regular proxy and note the existing routing mode. Then select “Enable Tun” in the v2rayN main window and check the core startup logs and virtual adapter status. For the first test, keep the system proxy in a clear, reversible state. This avoids confusion from stacking an application’s manual proxy, the system proxy, and TUN. If you need to use them together, understand each entry point’s listening address and traffic path rather than assuming more entry points are always better.

Test three things: whether an application that does not use the system proxy can reach its intended destinations, whether local network devices remain reachable, and whether DNS resolves as designed. A browser that follows the system proxy may still work even when TUN capture has failed, so it is not enough on its own. For internal services, test both the hostname and a known internal address. If the hostname fails but the address works, check DNS and search domains rather than changing the remote server.

Routing loops and virtual adapter conflicts

TUN must not send the client’s own connection to a remote server back through itself, which would create a loop. Clients usually prevent this with interface binding, route exclusions, or process handling, but custom rules, multiple active VPNs, and network changes can break those safeguards. If all connections time out after enabling TUN or the logs repeatedly show connections to the same destination, first disable the newly enabled traffic capture and check the active default adapter and the server’s route. Do not respond by adding a broader proxy rule.

Switching from wired to wireless, resuming from sleep, or connecting to a corporate VPN can change interface order and route priority. If TUN fails only after a network change, reconnect the client so it can rebuild its state for the new network. If it fails every time, check whether it is bound to an interface that is no longer active. Linux and macOS handle system permissions, adapter names, and routes differently; do not copy Windows troubleshooting steps. Follow the active client’s permission prompts and your operating system’s network management tools.

UDP, MTU, and recovery

TUN accepting a type of traffic does not mean the remote protocol, transport, and server all support forwarding it. If an application using UDP fails, first confirm that the entire connection path supports UDP, then check that routing sends the traffic to the right outbound. Consider MTU, path discovery, or fragmentation only if large responses, file transfers, or a particular app stall while short requests work. Do not lower the MTU without a reason. Keep the original value and test the same application after each change.

Before closing the client, turn off TUN in the interface and exit normally so the program can remove its routes and adapter state. If the client terminates unexpectedly and networking does not recover, first check whether the system proxy still points to a stopped local port, then check other VPNs and leftover adapters. If needed, restore connectivity through system network settings, but do not delete a corporate network configuration without understanding its purpose. Once regular networking is back, repeat the minimal tests from this section instead of immediately enabling every feature again.

FakeDNS

Synthetic addresses preserve domain mappings

FakeDNS is not a regular resolver that returns a destination’s real address. It assigns a synthetic address from a dedicated pool and stores the domain-to-address mapping in the core. When an application connects to that address, the core uses the mapping to recover the domain and continue with routing and outbound processing. In some traffic-capture setups, this preserves domain information and reduces the need to resolve a real address before deciding how to route a connection. But FakeDNS depends on a complete chain of DNS handling, traffic capture, and domain recovery; enabling one switch alone is not a complete setup.

In v2rayNG, check the “Fake DNS” options under “Settings,” along with “Enable Local DNS” and the current routing settings. How much configuration is generated automatically varies by client and core, so verify the generated result and startup logs. Do not assume v2flyNG uses the same settings just because its interface looks similar. Establish a working DNS and routing baseline before testing FakeDNS. If ordinary connectivity is not working yet, synthetic addresses only add another layer to troubleshoot.

Address pools, query entry points, and recovery

This partial example uses common core syntax for a synthetic address pool, DNS entry points, and inbound sniffing fields. Merge each part into its corresponding location; do not paste the whole object into an arbitrary field beside a client toggle. The sniffing object belongs in the inbound configuration. The full configuration also needs an inbound, routing, and outbound capable of handling the traffic. The address pool must not overlap with networks in use and should not be an arbitrary public address range.

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

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

The address range above is for test networks and is shown as an example of a synthetic address pool, not as a real server address. Pool size determines how many mappings can be stored; increasing it is not a general performance optimization. More importantly, the synthetic address returned to an application must reach the same core that holds the mapping. If one client answers the query but another VPN captures the connection, or an application keeps the address after the core restarts, the mapping may no longer be available.

Decide whether FakeDNS fits the application

FakeDNS is worth testing when an application mainly uses domains, the same client captures both DNS queries and subsequent connections, and routing needs reliable access to domain information. It may not suit applications that make decisions based on real IP addresses, services that need to pass resolved addresses to other devices, or networks where internal services overlap with the test range. Some applications inspect address properties, cache results, or bypass system DNS, so their behavior may differ from a regular browser.

If an application uses its own encrypted DNS, queries may never reach the FakeDNS handler. The feature can be enabled while the application still gets a real address; that does not necessarily indicate a core failure. Conversely, if an application receives a synthetic address but bypasses the client when connecting, the connection will fail. Check separately whether the query got a synthetic answer, whether the connection was captured, and whether the core recovered the domain. Seeing an unusual address alone does not prove the full chain is working.

Handle caches when enabling or disabling FakeDNS

After enabling FakeDNS, restart the test application so it makes a fresh DNS query. Then test a regular webpage, a local network service, and an everyday application. If an internal domain gets a synthetic address when it should not, preserve real resolution for internal domains if the client supports it, and confirm the corresponding connections go direct. DNS exclusions, direct routing rules, and system route bypasses apply at different stages; setting only one may not be enough.

After disabling FakeDNS, an application or the operating system may still have a synthetic address cached even though the core no longer holds its mapping. This can make a connection fail temporarily after the feature is turned off. Stop the test application, clear the relevant cache, and establish a new connection before judging whether the rollback worked. Restarting the client can also change mapping state, so include long-running applications in your tests. For more on how it works and when to use it, see FakeDNS explained: how it works and when to use it.

Managing Multiple Subscriptions

Keep sources, purposes, and updates linked

When managing several subscriptions, give each source its own group first, then decide which entries are for everyday connections and which are only for compatibility testing. Do not merge everything into one large list and try to guess where each entry came from based on its remark. Group names can describe a purpose such as “daily,” “testing,” or “manual,” but keep a local record linking each group to its source. A subscription URL may change when an account is reset; an unchanged name does not mean it still points to the same set of configurations.

In v2rayN, check each group’s URL, filter conditions, and update method under “Subscription Groups,” then set an update interval using the available client options. On Android, manage sources in “Subscription Group Settings” and update them individually. Verify each group on its own first, then use a bulk action such as “Update All Subscriptions.” If some updates fail, this makes it easier to identify the source instead of blaming every network problem on the client.

Manage update frequency and active servers separately

More frequent updates do not make a connection more stable. Update requests use network resources, require the provider to respond, and may trigger access limits. Follow the provider’s instructions and update at a frequency that reflects how often the source changes; there is no need to refresh repeatedly at very short intervals. On mobile devices, background restrictions may delay tasks, so an interval shown in the interface does not guarantee an update will run on time. Before you need a connection, update the relevant group manually and check the result instead of relying only on background status.

After updating, review the active server. A subscription may remove entries, change remarks, or adjust security settings, and the client may regenerate internal IDs. Check the current interface to see whether favorites, sorting, and routing bindings still point to the right entries. A matching server name does not prove its settings are unchanged. If you use custom outbounds or tag-based references, confirm that they still point to the intended object. Clear local notes about each entry’s purpose make post-update checks easier.

Duplicate entries and moving between devices

Duplicates can appear when multiple subscriptions contain the same connection or when manual imports coexist with subscription updates. Do not decide based on remarks alone; compare the address, port, protocol, security settings, and transport. Deleting an entry just because its display name matches another could remove a configuration with a different purpose. If the client offers deduplication, check how it compares entries and test it on a backed-up group first. Entries from different sources may have different update and revocation boundaries even when their connection settings match.

When moving between devices, keep subscription sources separate from device-specific settings. If authorized, you can enter a subscription URL again on another device as needed. Local listener ports, TUN permissions, system proxy settings, per-app proxy rules, and internal DNS usually cannot be copied as-is. A full v2rayN configuration is not a backup you can restore directly in v2rayNG or v2flyNG. Import the basics on the destination device, then recreate routing and DNS intent one setting at a time. This avoids copying paths and interface names that exist only on the original device.

Expired subscriptions and revoking credentials

If a source fails to update, keep other working groups instead of clearing all servers to retry. Confirm the failure is limited to that subscription, then check whether the URL expired, requires signing in again, or is being updated through a broken connection. If the URL was exposed, revoke it using the provider’s reset process, then update the local group; changing its remark does not invalidate the old URL. Check other devices too so they do not keep requesting the old link in the background.

Remove sources you no longer use and check for related favorites, shortcuts, and custom outbound references. Exported backups may retain revoked URLs, so inspect them again before restoring. The goal of managing multiple subscriptions is to keep every configuration traceable to its source, explain its purpose, and allow it to be rolled back independently—not to keep expanding the list. If maintenance starts getting in the way of everyday use, remove duplicate sources and entries with no clear purpose before adding more complex automatic selection rules.

Custom Outbounds

A tag is a reference, not a connection name

Outbounds define how the core connects to destinations; routing selects them by tag. outboundTag must reference a tag that exists in the full configuration, with spelling and case matching exactly. A server remark in the client list is not necessarily its core tag, and a subscription group name does not automatically become a selectable outbound. Before writing a rule, inspect the generated configuration’s tag structure. Do not assume the core will look up a readable interface label just because you entered it as the routing target.

This partial example defines direct and block outbounds for Xray or V2Fly configurations that support these protocol objects. It includes no proxy server, inbound, or complete routing setup. Replacing your existing outbound list with it would remove your current proxy connection. A graphical client may already have generated outbounds with the same tags; check for conflicts before merging. Duplicate tags make references ambiguous, and changing display order will not fix that.

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

Define block rules and the default outbound explicitly

Use blocking for destinations you have confirmed should not be reachable; it is not a shortcut for handling every unknown connection. First test the rule against a domain that cannot affect everyday use, then consider expanding it. Business applications may rely on several domains for authentication, content, and updates. Blocking just one can cause only part of an application to fail. Check logs to identify the actual destination instead of repeatedly testing broader domain categories.

{
  "type": "field",
  "domain": ["full:example.invalid"],
  "outboundTag": "block"
}

The example is a rule object for the routing.rules array and uses a reserved invalid domain to illustrate syntax. It only works if the block outbound described earlier exists. For real services, verify the destination first, then choose an exact-domain or subdomain match as needed. Also check where unmatched traffic goes. If a custom configuration puts direct first and has no fallback rule, the default may differ from the client’s original scheme. Do not stop after testing explicit rules alone.

Chaining and selecting outbounds are different

Several outbounds side by side let routing choose between paths; they do not automatically form a chain. Chaining requires a core-supported outbound handoff mechanism, correct references, and a reachable network design. The exact fields and limitations vary between cores. If you need chaining, first confirm the client provides a supported upstream proxy or chain entry point, then follow the active core’s documentation. Listing several servers in an array does not make a connection pass through them one after another.

Load balancing, failover, and manual switching are also distinct. A selector chooses among candidate outbounds under certain conditions; it does not move existing connections automatically. A reachable probe target does not prove every service works. Before adding automation, verify that each outbound works on its own and that its protocol, security settings, and DNS path are correct. Then design the selection criteria. If a subscription update regenerates outbound tags, update the selector references too, or the configuration may fail to start or have no candidates.

Use supported configuration options and keep a rollback copy

When using custom configuration in v2rayN, first confirm whether the current setup is generated by the interface or supplied by an external file. The two modes have different boundaries: interface-managed settings may overwrite manual edits on restart, while a custom file may prevent some automatic settings from being used. On Android, import through the client’s supported configuration entry point as well; do not edit internal directories without understanding their lifecycle. After saving, check startup logs for unrecognized fields, missing tags, or invalid resource paths.

To verify the complete configuration, check inbound listeners, DNS queries, rule matches, and outbound connections in that order. If the core will not start, fix syntax and references first. If it starts but cannot connect, check traffic entry and network paths. You can temporarily increase log verbosity to investigate, then restore the usual level and handle logs that may contain destination addresses carefully. Do not write logs to an uncontrolled shared directory or keep sensitive connection details in verbose logs longer than necessary.

If the new outbound does not solve a specific need, return to the client’s built-in routing scheme and reduce the configuration you have to maintain. For protocol and core compatibility, see the core differences guide. To restore a basic connection, follow the getting started guide. Advanced configuration is complete when every traffic path is understandable and each change can be undone on its own—not when as many switches as possible are enabled.