V2Ray Advanced Configuration Guide

Create Subscription Groups You Can Update Independently

A subscription URL points to a configuration list; it is not a connection service provided by the client. Before importing one, make sure the source is trustworthy and still valid, and that you have not mistaken an account management page URL for a subscription URL. In v2rayN, open “Subscription Group,” go to “Subscription Group Settings,” create a group, enter a recognizable note and the subscription URL, then save. Menu layouts may change, but “Group Settings” and “Update Subscription” are separate actions: saving the URL records the source; updating fetches and parses the server configurations.

Name groups by source or purpose, such as “Primary Subscription,” “Backup Subscription,” or “Manual Configs.” Avoid using dates alone, and never put account passwords in a note. After creating a group, return to the main window, select the group to update, and choose the relevant update action from the “Subscription Group” menu. For the first import, update just one group and check that new server entries appear and their protocol, address, and transport settings are recognized. Add another source only after that. This makes it easier to identify which import caused a problem.

Keep Display Filters Separate from Configuration Changes

Group selection, the search box, and filters in the main window usually affect only the current list; they do not automatically add traffic-routing rules. When searching notes, start with a short, distinctive term and check whether a group filter is also active. If the list suddenly appears empty, the selected group and search term may simply be narrowing the results together; that does not mean the subscription was deleted. Clear the search and switch to all groups before deciding whether to import again. Avoid repeatedly adding the same subscription before checking the active filters, or you may create duplicate entries.

If the client offers a subscription-level filter expression, first check whether the field is for inclusion, exclusion, or rewriting notes. Do not mix these purposes. Use regular expression syntax only in fields explicitly marked as supporting regex. For example, ^(工作|备用)- matches notes that begin with the specified prefixes; it does not check whether a server is reachable or interpret region names. Verify the target set with ordinary search first, then move the condition into subscription settings. You will usually need to update the subscription again to see the effect of a saved expression.

Check the Fetch Path When Updates Fail

A subscription URL opening in your browser does not mean the client uses the same network path. First check that the URL is complete, especially for line breaks, spaces, or trailing punctuation introduced during copying. Then distinguish a normal update from an update through a proxy: the latter depends on a working proxy outbound. If no server is currently usable, this can create a loop: you need to update to connect, but need to connect to update. In that case, use a subscription endpoint you can reach directly or restore a previously verified configuration instead of repeatedly switching network settings.

Check the response too. A login page, error message, or blank response is not a valid subscription list. Share links and subscription URLs are also different types of input. Import a single share link with the client’s clipboard import feature; do not put it in the subscription URL field just because it can be copied. For the difference between import methods, see the subscription link import guide. When troubleshooting, record only the error type, group name, and steps taken. Do not include the full subscription URL in public screenshots; it may contain account credentials.

When you are done, each subscription source should have its own group, manual and subscription servers should be stored separately, and disabling filters should reveal the full list. Then test the connection using a known working server. Whether a server is displayed, selected, or actually used for outbound traffic are three different states. Confirm them before moving on to routing configuration.

Understand Rule Order and the Default Outbound First

Routing handles connections that have already entered the core. If an app does not use the system proxy and is not routed through TUN, changing routing rules will not change its path. In v2rayN, open “Routing” or the relevant routing settings, confirm which rule set is active, and check the rule order. With common Xray field-based routing, rules are evaluated from top to bottom, and the first match selects the outbound. Put exceptions for specific domains before broad domain groups, and broad catch-all rules at the end. Rule priority cannot be inferred from its note or label.

Within a field-based rule, different condition fields usually all have to match; multiple values in the same field usually mean any one of them can match. For example, specifying both a domain and a port means the target must match both conditions. If you mean “these domains or these ports,” create separate rules. In a native Xray configuration, traffic that matches no rule usually uses the first outbound as the default. A GUI client may also generate fallback rules, so inspect the actual generated configuration rather than just your custom rules.

Domain Sets, Address Sets, and Resolution Strategy

geosite:cn references a domain set, while geoip:private references a private address set. The former relies on domain rule data; the latter relies on address rule data. Neither is an online service, and neither automatically supplies missing data files. A domain rule can match only when the core knows the target domain. If the entry point provides only an IP address, and there is no reliable domain recovery or sniffing, do not assume domain rules will match. Conversely, whether an IP rule works for a domain target also depends on the routing domain resolution strategy.

The JSON below is an Xray top-level configuration merge snippet demonstrating direct connections for private addresses and specified domains, plus blocking ad domains. Direct is the first outbound, so unmatched connections also go direct; this is not a complete proxy configuration. If your existing configuration already has an outbound with the same tag, reuse it rather than defining a duplicate. GUI client users should create equivalent rules in the rule editor and verify the tags generated by the client. Do not paste the entire JSON into a text field that accepts only a rule array.

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["full:example.com", "geosite:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:category-ads-all"],
        "outboundTag": "block"
      }
    ]
  },
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ]
}

Test One Target at a Time, Not a Large Batch of Rules

To verify routing, choose a reproducible target, note the expected outbound, and then check the actual outbound tag in the logs. After saving a new rule, reload the configuration or restart the core as required by the client, then close the app’s existing connections and retry. Long-lived connections may keep using the old path, and browser cache can make a page look unchanged; a refresh alone may not prove the new rule is in effect. If the rule does not match, check the active rule set, rule position, target domain format, data file availability, and information provided by the entry point—in that order.

For LAN devices, shared printers, and internal services, start by checking the specific address ranges. Do not send all traffic direct just to fix one LAN access issue. Some internal domains are available only through an organization’s DNS, so both name resolution and routing may need to be configured. A direct-routing match does not guarantee DNS is working, and successful name resolution does not guarantee the connection uses the right outbound. Record the target, matched condition, and outbound tag from the logs to distinguish routing problems from resolution problems.

Keep a small, clearly defined rule set as a fallback baseline. After adding each type of rule, test ordinary websites, LAN resources, and targets that need special routing. If only one domain has a problem, add a local exception or fix the rule order; do not clear the entire rule set. The more rules you have, the more important it is to document their purpose. A broad rule with an unclear match scope can be harder to troubleshoot than a missing rule.

Map the Path of a DNS Query First

DNS resolves domain names to addresses, but a device may have several resolution paths. The system resolver serves ordinary apps; a browser may use its own Secure DNS; and the proxy core may resolve names for routing decisions, direct outbounds, or upstream connections. Setting “Remote DNS” in the client does not mean every app uses it. Before changing anything, determine whether the target app passes the domain to the proxy or resolves it locally to an IP address first. These entry paths provide different information to routing and require different troubleshooting steps.

In system proxy mode, apps that support proxies often pass the domain name to the local proxy, but behavior depends on the app and protocol. With TUN enabled, whether system DNS requests enter the client also depends on the virtual adapter, DNS interception, and exclusion settings. A browser’s built-in encrypted DNS may bypass the system DNS path. For a comparable test, temporarily set the browser to use the system resolver, verify the basic path, and then evaluate its Secure DNS settings separately. Avoid changing both resolution layers at once.

DNS Server, Query Type, and Routing Are Different Settings

When choosing a DNS server, consider whether the current network can reach it, whether it can resolve internal domains, and which path DNS queries should take. Entering 1.1.1.1 selects a public resolver address; it does not automatically send queries through a proxy. Encrypted DNS protects queries between the device and resolver, but it still needs a network connection. If the resolver is specified by domain name, bootstrap resolution may also be an issue. If resolution fails during startup, first verify that the resolver itself is reachable instead of adding more fallback addresses.

The Xray top-level DNS snippet below shows one server and an IPv4 query strategy. It does not create a traffic entry point or automatically change system DNS. Merge it only after confirming that the current core supports the relevant fields. When the client generates the configuration, use its DNS settings where possible. UseIPv4 can help isolate IPv6 path issues, but is not a recommended long-term setting for every network; services that depend on IPv6 may lose usable addresses.

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

The Limits of Split DNS and Caching

For internal domains, keep a resolver that can answer them, then direct queries according to the domain conditions supported by the core. Public DNS servers usually do not know internal hostnames. Split DNS should not send every domain to every server; it should route specific domains to the right resolver and make clear whether another resolver can be used if the preferred one fails. Cores differ in how they define server selection, fallback, and caching. Do not copy a field with the same name from another configuration format and assume it will work.

After changing resolvers, old addresses may remain in the system cache, browser cache, or app connection pool. Restart the target app first, clear the DNS cache using the appropriate system method, and reload the client core if needed. Do not assume the setting is ineffective just because a cached result has not expired, and do not judge resolution quality from a single address change. During testing, record whether resolution succeeded, the address type returned, and whether the connection ultimately worked. If the domain resolves but the target address cannot be reached, troubleshoot routing or the network path instead of continuing to replace DNS servers.

Also distinguish DNS failures from certificate errors. An incorrect system clock, a hostname that does not match the certificate, or an app connecting to an internal interception page can all make a site appear unavailable; changing resolvers may not help. If you override a fixed domain, document why and when to remove the override instead of leaving a temporary address in place. A complete DNS setup must return an address and remain consistent with routing, the entry point, and the network environment.

Verify a Working Outbound Before Enabling the Virtual Adapter

TUN receives packets through a virtual network interface when they meet the system’s routing conditions, making it useful for apps that ignore system proxy settings. It is a different entry method from local HTTP and SOCKS listeners, but routed traffic still needs routing rules to select an outbound. Before enabling it, verify in ordinary system proxy mode that the server can connect and DNS works. If you turn on TUN before the basic connection succeeds, problems may involve the virtual adapter, permissions, resolution, and routing all at once, making the original failure difficult to identify.

Before looking for an “Enable TUN” switch in v2rayN, make sure the client is installed in a stable location, the required core and supporting components are present, and you have granted the permissions required by your platform. Windows may require administrator privileges to create an interface or change routes; permissions on macOS and Linux depend on the client implementation. Do not apply permission commands from another platform. Find installation options for each platform on the client downloads page, and see the Getting Started guide for the initial setup.

Create a Test Setup with One Traffic Entry Point

For your first TUN test, you can turn off the system proxy so the target app uses TUN alone, reducing interference from multiple entry points. This does not mean the two modes can never be used together; it means keeping the path simple during troubleshooting. After enabling TUN, check the client logs for interface initialization failures, permission errors, or routing setup failures. Seeing a virtual adapter in the system does not prove that DNS interception or outbound traffic is working. Test domain access, ordinary connections, and LAN resources separately.

Other VPNs, virtual adapter tools, container networks, and enterprise security software may also modify system routes. If all network access stops, turn off TUN first and see whether it recovers, then check those other components one by one. Do not repeatedly switch the default gateway while multiple traffic interception tools are running. If you need to preserve access to a corporate network or specific subnets, use the client’s supported route exclusions or rules, and check whether they apply at the system interception layer or the core routing layer. The names may be similar, but the layers are different.

Check DNS, LAN Access, and UDP

A common TUN issue is that DNS requests do not follow the expected resolution path. If direct IP access works but domain access fails, check the DNS server used by the virtual adapter, the client’s DNS interception, and the app’s own resolution settings. Do not enable FakeDNS straight away; real address resolution is a simpler baseline to observe. For LAN access issues, check whether private addresses are correctly excluded or routed direct. Pay particular attention to unusual corporate subnet ranges and internal services reachable only through a specific interface.

Some apps use UDP, but an entry point that can receive UDP does not guarantee that the remote server, transport configuration, and full network path support the same traffic. If websites work but voice or other UDP features do not, check protocol support, outbound configuration, and firewall rules separately. The TUN switch alone does not prove that every app is covered. Avoid changing MTU without a reproducible symptom, such as large transfers stalling on a particular network or a connection opening but failing to transfer data. Record the original value and test one change at a time.

Keep Clear Steps for Disabling and Restoring TUN

After turning off TUN, check that ordinary network access works again, then confirm whether the system proxy still points to a local port. If the client exits while the system proxy still targets a port with no listener, apps may remain unable to connect. If the interface or routes are not restored, restart the client normally and disable traffic interception again. If needed, check for leftover state using your system’s network management tools. Do not bulk-delete unfamiliar routes or remove system virtual adapters; other software may rely on them.

After configuration, test in a fixed order: ordinary websites, a domain-dependent target, LAN resources, an app that uses UDP, then sleep and wake and network switching. In a mobile work setup, switching from wired to wireless changes interfaces and routes, so interception that worked before may need to be initialized again. Use TUN as a daily entry point only when these scenarios are understood and work as expected, not as a universal switch to flip whenever a connection fails.

Understand Where Synthetic Addresses Fit in a Connection

A normal DNS query returns the destination’s real address, and the app then connects to that address. FakeDNS assigns the domain a synthetic address from a pool and the core stores the mapping between the domain and that address. When the app connects to the synthetic address, the interception path must deliver the request back to the core that holds the mapping. The core can then recover the domain and continue routing or select an outbound. FakeDNS preserves domain information; it does not speed up the destination server or automatically send all DNS queries to a remote resolver.

This mechanism requires the resolution and connection paths to form a complete loop. If the system receives a synthetic address but the subsequent connection bypasses the client, it will try to reach a destination that does not exist on the public internet. If one instance assigns the address but the connection reaches another instance without the mapping, domain recovery may fail. Do not assume FakeDNS is working just because you copied an address pool setting. Check how DNS queries reach the core, how app packets are intercepted, and whether the relevant inbound can recover the domain.

Coordinate the Address Pool, Resolver, and Sniffing

The Xray top-level configuration snippets below show a FakeDNS address pool and a DNS server. The example uses addresses from 198.18.0.0/15 as a synthetic pool; these are not public addresses that can be connected to directly. The snippet still needs to work with the FakeDNS recovery settings on the actual inbound and cannot replace a TUN configuration generated by the client. If the client has an “Enable FakeDNS” setting, prefer its integrated setup to avoid declaring the address pool at multiple configuration layers.

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

For Xray inbounds that support the relevant fields, destOverride in the sniffing settings can include fakedns. This recovers the destination domain from a synthetic address; it is not ordinary HTTP or TLS sniffing. Ordinary sniffing attempts to identify the hostname from connection data, while FakeDNS recovery depends on a mapping created earlier. Keep the rest of the inbound settings intact; do not replace the protocol, listen address, or port just to add sniffing. Configuration varies by core and interception implementation, so check the generated configuration you actually use.

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

Handle Caches and Bypasses When Switching

After enabling FakeDNS, an app may still have a real address cached from before; after disabling it, the app may retain an old synthetic address. For testing, close the target app’s connections and restart it. Clear the system DNS cache and reload the core if necessary. Otherwise, repeated requests to the same domain may take different paths and make the rules appear to work inconsistently. In particular, do not let an app keep using a cached synthetic address after restarting the client has cleared the mapping table. That failure does not necessarily mean the subscription or server has changed.

Use care when excluding apps from interception. If an app receives a synthetic address but is excluded by process or system routing rules, it cannot reach that address through the ordinary network. You may also need to adjust your setup if an internal network uses addresses that conflict with the synthetic pool. Apps that inspect DNS results directly, require a real destination address, or perform their own connection validation may not work well with synthetic resolution. Keep a real DNS path for those targets rather than adding broader interception rules.

Start testing with an ordinary domain. Confirm that FakeDNS answered the query, that the connection reached the expected inbound, and that the logs show domain recovery and a matching routing rule. If real DNS works but FakeDNS does not, leave the server and routing rules unchanged and check only the mapping path. This narrows the issue to the resolution and entry layers without requiring you to reimport the subscription. If ordinary web access is all you need, you can also keep real DNS and reduce the number of settings to maintain.

Group by Source, Not by Temporary Display Results

The first step in managing multiple subscriptions is not importing more URLs at once; it is making every configuration traceable to its source. Use a separate group for each subscription URL, put manual servers in another group, and organize the daily display with notes or filters. Do not merge sources just because two subscriptions contain similarly named servers. Updates, filters, and upstream changes all apply to their respective sources. Once groups are mixed, it is hard to tell whether an entry disappeared because the provider removed it, a filter changed, or another subscription changed what is displayed.

A simple maintenance record is enough: note each group’s purpose, whether automatic updates are allowed, whether updates require a direct connection or a proxy, and which known working configuration to restore. You can keep the record in a local document, but protect subscription URLs as sensitive information. If the client offers configuration export or backup, check whether it includes subscription credentials, server authentication, and custom rules. When sharing troubleshooting material, include only field names and error types; do not send the entire user data directory.

Update Order and the Currently Selected Server

An update may add or remove entries and may regenerate local identifiers. If an upstream provider removes or replaces the selected server, what the client selects next depends on its implementation; do not assume it will keep using the same server. Before an important session, update one group, confirm that the selected server is still there, and establish a new connection. Matching server notes do not prove the configurations are identical. Check that the protocol, address, port, transport, and security settings still meet your expectations.

Automatic updates work well for sources you have already verified, but account for device sleep, network changes, and the update path. If every subscription is set to update through the current proxy at the same time, all updates may fail when that proxy is unavailable. During troubleshooting, switch to manual updates temporarily and handle one group at a time. Re-enable automatic updates afterward if needed. There is no need to refresh very frequently without a clear reason. A failed refresh does not immediately invalidate the local configuration; first check whether the existing outbound still works.

Deduplication, Filtering, and Manual Edits

The same server may appear in multiple sources, but matching names are not a reliable deduplication criterion. Different authentication, transport, or TLS settings may point to the same address but serve different purposes. Conversely, entries with different names may use the same configuration. Before using a client’s deduplication feature, check which fields it compares and keep a recovery copy. If you only want a shorter daily list, use groups and search rather than deleting configurations you do not yet understand.

Subscription contents are maintained upstream. Local changes to a server’s transport settings may be overwritten on the next update. For a derived configuration you need long term, copy it to a manual group and record its source and why you changed it. Do not repeatedly edit an upstream-generated file as your only working copy; the client may regenerate it when reloading. Keep routing and DNS in separate settings supported by the client where possible, so subscriptions manage only server parameters and updates are less likely to overwrite other settings.

A Backup Group Is Not Automatic Failover

Adding a backup subscription in the main window only adds another configuration source; it does not automatically set up health checks, load balancing, or failover. Unless you explicitly configure those features, you will usually need to select a different server manually when the current one fails. Even if the interface supports latency tests or automatic selection, check what target is tested, whether it verifies a real connection, and whether switching affects existing sessions. One successful test does not prove that every app will work, nor does it replace checking protocol and network path compatibility.

The most useful part of managing multiple sources is having a repeatable switching procedure: record the current group and server, select the backup configuration, reconnect, then test the same target. If the backup works, leave the original source unchanged and troubleshoot its updates and server settings separately. If all sources fail, check the local entry point, DNS, permissions, and system network first. Separating source issues from local environment issues prevents you from masking a configuration error by continually adding subscriptions.

Distinguish the GUI Client, Core, and Configuration Format

v2rayN is a GUI client that manages servers, generates configurations, and starts the core. The selected core and its supporting components actually handle protocols and routing. Similar fields in the interface do not guarantee identical underlying configuration formats. Before editing, check the core type in client settings or startup logs, then determine which component handles the feature you need. TUN interception and ordinary proxy connections, in particular, may be handled by different components; the server protocol name alone does not reveal how the entire path works.

On Android, v2rayNG primarily uses the Xray core, while v2flyNG is an alternative client in the V2Fly ecosystem. Choose based on the protocols and features your configuration requires, not just the client name. Core support for protocols, security extensions, and configuration fields varies; a complex custom Xray configuration may not run in another core. For ecosystem background and feature trade-offs, see Xray vs. V2Fly: Core Differences.

Outbound Tags Are Routing References, Not Display Notes

A custom outbound needs, at minimum, a clear tag, a supported protocol, and the corresponding parameters. The routing rule’s outboundTag must exactly match the outbound’s tag, including capitalization. A server note in the main window may not be the tag in the generated configuration. Before saving, check whether the client preserves the outbound, whether a tag with the same name already exists, and where the custom rule is merged. Duplicate tags and rules that point to nonexistent tags should be fixed before startup.

The Xray outbound object below demonstrates forwarding a connection to another local SOCKS service listening at 127.0.0.1:10810. Use it only when that service is already running and accepts local connections; it does not create a second proxy. Add the object to a supported outbound array, then reference local-socks in the relevant routing rule. If you use an ordinary subscription server, you usually do not need to add another layer just to connect.

{
  "tag": "local-socks",
  "protocol": "socks",
  "settings": {
    "servers": [
      {
        "address": "127.0.0.1",
        "port": 10810
      }
    ]
  }
}

Prevent Forwarding Loops and Configuration Overrides

With local forwarding, first check how the ports map to services. If the current core’s SOCKS inbound listens on the same port that the outbound targets, the connection may loop back to itself. A separate service that also uses the current client’s outbound can create a cross-process loop. Before configuring anything, write down each listener address, listener port, and next hop, and make sure the path ultimately reaches a real network exit. Do not just check that a process is listening on the port; check which process owns it.

For custom configurations managed by the client, use its custom server, configuration import, or rule editor where possible. Direct edits to runtime-generated files may be overwritten the next time you switch servers or restart the core. If you need to maintain a complete configuration, identify which settings remain controlled by the main window and which can only be changed in the configuration file. For example, the routing selection in the main interface may no longer affect a complete custom configuration. Avoid maintaining two apparently identical sources of settings that can overwrite each other.

Limit Compatibility Issues to the Smallest Possible Scope

If the core will not start, check the first clear error and distinguish JSON syntax, unknown fields, missing files, tag references, and occupied ports. Do not change DNS or servers while the core is still failing to start. If you need to switch cores, preserve the current working configuration, then use the simplest compatible connection to verify basic functionality. Restore routing, resolution, and custom outbounds one at a time. Successful import into the client only means the interface could read the content; it does not guarantee the current core can run every field.

Before using a custom outbound day to day, test whether the target rule matches, the next hop is reachable, apps reconnect, and you can restore the previous setup. If the path depends on another local service, test what happens when that service stops so a clear local dependency failure is not mistaken for a remote issue. Good outbound design is easy to explain and recover: every tag has a purpose, every port has an owner, and every change can be rolled back to a verified baseline.

Identify the Stage Where the Failure Occurs First

“Can’t connect” can mean the core did not start, the app is not using the proxy, DNS failed, a rule chose the wrong outbound, or the remote connection could not be established. Record the minimum steps needed to reproduce the problem: client, core type, entry mode, selected server, target app, and the action that triggered the error. Then try another target to see whether the issue affects one domain or all connections. If the underlying network is already unavailable, restore system connectivity before troubleshooting the proxy; otherwise, you may mistake an internet outage for a subscription problem.

If core startup fails, start with the error at the beginning of the log. An occupied port, invalid configuration syntax, or insufficient permissions usually leaves a clue at startup. Use the port numbers set on your system; do not assume your device uses the common SOCKS port 10808 or HTTP port 10809. If you change a port, update any apps where you configured the proxy manually. Automatic system proxy settings and manually configured app proxies may also be separate.

Verify the Entry Point Before Checking the Remote Connection

When the system proxy is enabled, only apps that read system settings will use it automatically. A successful webpage test does not prove that an app without system proxy support has reached the client. First test the local entry point with an app known to support proxies, then decide whether you need TUN. For TUN, check the interface, permissions, and traffic coverage. If the client logs show no connection for the target, troubleshoot the entry point before changing remote protocol settings. Without incoming traffic, routing rules have nothing to match.

After confirming that traffic reaches the client, distinguish resolution errors from connection errors. If a domain fails but a test using a known address works, check DNS. However, visiting an HTTPS site directly by address may trigger a certificate or hostname error, which does not prove DNS is at fault. The more reliable approach is to check the resolution result and actual connection target in the logs. If the domain resolves but the connection times out, check the outbound and network path. If you see an immediate rule or tag error, fix the configuration reference first.

Narrow the Scope by Symptoms, Not by Repeatedly Flipping Switches

If the problem appears only after enabling FakeDNS, leave the server and routing unchanged and switch back to real DNS first. If it happens only with TUN, use the ordinary proxy entry point as a comparison. If it started after a subscription update, check whether the selected server was replaced and whether upstream settings changed. If it started after switching cores, begin with field compatibility and the generated configuration. Each branch needs a clear comparison condition; do not change the server, DNS, and routing all at once and then guess which change helped.

In the logs, focus on error type and sequence. A connection refused error usually means the target port is not accepting connections or has explicitly rejected them; a timeout may involve the path, filtering, or an unresponsive remote server. Neither error alone proves that every server configuration field is correct. For TLS errors, also check the system clock, server name, and certificate validation settings. Do not weaken security checks just to silence an error. First make sure the domain, transport, and server configuration agree, then reconnect.

Create a Reusable Recovery Baseline

A recoverable baseline includes a core that starts, a verified server, a clearly defined local entry point, simple routing, and a reachable DNS resolver. Before each change, record the original value and expected result. If it fails, restore the original value instead of piling more changes onto a broken setup. For TUN and FakeDNS, recovery also involves app caches and system interception state. Re-establish the connection after restoring settings; a disabled switch alone does not prove the old path has been cleared.

After troubleshooting, keep only the changes that are necessary and remove temporary test rules. To restore a basic connection, return to the Getting Started guide and review the main setup steps. To switch platforms or clients, use the relevant option on the downloads page. For routine maintenance, follow the same verification order: check that the core is running, confirm traffic reaches it, then check resolution, routing, and outbound. This keeps future issues traceable through clear configuration layers instead of requiring you to rebuild everything from scratch.