v2rayN Advanced Configuration Guide

Subscription Groups & Server Filters

Subscription groups organize sources; filters narrow down the servers you import. A subscription usually contains multiple server entries. The group stores the subscription URL, notes, and update options, while each server entry stores its protocol, address, port, and connection parameters. These are separate layers: changing a group note won’t change remote servers, and deleting a local entry may not stop it from returning on the next update. To exclude entries over time, use group filters instead of repeatedly deleting them by hand.

Create groups you can identify at a glance

In v2rayN’s subscription group settings, add a group and enter a note that identifies its source or purpose, then paste the full URL. For illustration, use https://example.com/sub?token=xxxx; replace it with your own authorized URL. Keep the query parameters after the question mark, and don’t mistake a webpage URL for a subscription URL. Check for leading or trailing spaces, line breaks, and typographic punctuation after pasting. Treat any access parameters in the URL as sensitive.

Start with one group and update it manually. After import, check that the server notes, protocols, and entry count match what you expect from the source before adding more. Name groups by source or purpose, not by current speed or a one-time test result. Performance changes; source identity should remain clear. Redact subscription parameters from screenshots, logs, and config backups. A URL is still sensitive information and shouldn’t be shared publicly.

Before enabling automatic updates, make sure the group needs ongoing sync. Updates fetch remote content and may add or remove entries or change their connection parameters. Don’t assume manual edits to imported servers will survive an update. If an entry needs special parameters, save it as a separate config and note its source and why you changed it. Let the original subscription group handle syncing, rather than relying on both remote updates and local overrides for the same entry.

Filter Keywords & Regex Boundaries

Filters usually match server notes, but the fields searched and whether a filter includes or excludes entries depend on the client UI. Test a clear, ordinary keyword before enabling regex. Don’t put routing syntax such as geosite: in the server filter field; the two settings work on different data. A filtered list only shows which entries were imported or displayed. It doesn’t mean the servers passed a connection test or that their region labels were independently verified.

To match multiple note fragments, use the regex pipe for “or,” as in (Lab|Backup). To match literal parentheses, escape them: \(Backup\). Don’t paste code-style regexes with slash delimiters unless the UI explicitly expects them. Case sensitivity and regex engines can vary. Test with one entry that should match and one that shouldn’t; comparing both results is more reliable than guessing from the list size.

Handle update failures separately from empty lists

An update failure points to a problem fetching or parsing the response. If an update succeeds but the list is empty, check the filter and subscription content. For troubleshooting, temporarily clear the filter and update only that group. If entries return, add keywords back one at a time. If the list stays empty, check whether the source returns a valid subscription, the authorization has expired, or the response is actually a login page. Don’t mask errors by updating repeatedly; too many requests may trigger rate limits at the source.

If you can only reach the subscription source through an established proxy, use proxy-based updates if the client supports them. This depends on a working server and proxy entry point; a group that hasn’t imported successfully can’t establish its own update route. Keep a working config and compare the logs for direct and proxy-based updates separately. For more cases, see Troubleshooting subscription update failures. Never include the full URL in a public support request.

Routing Rules in Practice

Routing matches requests in order and sends them to an existing outbound. Rules don’t create servers or fix a broken connection. Verify that your proxy outbound works before adding traffic-splitting rules. For each rule, check the match target, conditions, and outbound tag: domain conditions match domains, address conditions match IPs, and port and network type can further narrow the match. Keeping these layers distinct makes it easier to see why a rule matched—or didn’t.

Set the rule order first

Standard field-based rules are evaluated from top to bottom; the first match determines the outbound. Put specific exceptions before broader rules. For example, if a domain should use the proxy even though it belongs to a direct-connection domain set, place its individual proxy rule before the set rule. Don’t sort all rules into broad “direct, proxy, block” groups; order them according to their exceptions. Conditions within one rule generally all need to match, while a list of the same condition type can include multiple alternatives.

This is a partial Xray routing example. It assumes existing block and direct outbounds, a default proxy outbound, and the required geo resources. It blocks the ad set first, sends private addresses direct next, then sends the China domain set direct. The snippet doesn’t define a default proxy. Check the full config’s outbound order or client-generated fallback rules to see what happens to unmatched requests.

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["geosite:category-ads-all"],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      }
    ]
  }
}

A private-address rule can help preserve access to your LAN, but it isn’t a universal exception. If an app submits a domain and routing uses AsIs, the core won’t look up an IP just to match this rule. Add explicit rules for internal domains, and make sure they use the right local resolver. Shared folders, printers, and admin pages may also depend on broadcast or other traffic; opening one webpage doesn’t prove every LAN feature is working.

Domains, IPs & Resolution Strategies

Use domain:example.com to match a domain and its subdomains; use full:example.com for an exact match. Regex is useful for domains with a clear, consistent pattern, but avoid broad expressions that send unrelated domains to the same outbound. Example domains only illustrate the syntax; use rules that fit your own access needs. Domain rules can’t see URL paths, so they can’t distinguish pages on the same domain.

AsIs matches using the information already in the request. IPIfNonMatch tries to resolve the domain if no domain rule matches, allowing IP rules to be checked next. IPOnDemand resolves when a rule needs IP information. The latter two add DNS dependencies and may add latency; results can also depend on where resolution happens. Don’t choose a more aggressive resolution strategy just to be “more complete.” First decide whether your rules actually need the destination IP.

If the incoming request contains only an IP, domain rules may not match. Sniffing can sometimes recover the domain from an app handshake, but this depends on the protocol, encryption, and client settings. Don’t assume sniffing can recover domains from all traffic. TUN and FakeDNS provide other ways to associate traffic with domains, but first confirm the traffic actually passes through the relevant entry point. Without that, even a correctly written rule has nothing to match.

Verify Matches & Check Resources

Test rules with a specific target and compare the destination, inbound tag, and outbound tag in the logs. Change one rule at a time and start a new connection so an existing connection doesn’t keep using its previous outbound. Browser connection pools and background app connections can affect results. If needed, fully close the app before testing instead of just refreshing the page. Check whether the client requires a core restart to apply rule changes.

If the core reports a missing geo file or category, check the resource path and category name first. Don’t replace every geosite rule with regex as a workaround. Resource contents vary by source, and a category being present doesn’t mean it fits every use case. For detailed log analysis, see Analyzing core startup failures and config errors. Restore a working connection before adjusting category rules further.

DNS Configuration

Start by answering three questions: who sends the query, which resolver receives it, and which outbound carries the query? System resolution, built-in core DNS, and resolution on the proxy server may all be involved. A “remote DNS” setting in the client UI doesn’t mean every app’s queries automatically use it. Map the request path before changing resolver addresses to avoid assuming that DNS follows a different path just because the webpage connection goes through the proxy.

Separate routing lookups from connection lookups

Routing lookups retrieve IPs to evaluate rules; connection lookups find the address to connect to. They may happen in different places. When a domain is sent to a remote proxy outbound, the client may not need to resolve it first. A direct outbound usually needs to resolve the address locally. Routing’s domainStrategy and a direct outbound’s own resolution strategy are separate settings. Changing one doesn’t imply the other changed too.

This example shows how Xray’s built-in DNS can route lookups: the China domain set uses the system resolver, while other queries can use encrypted DNS. skipFallback means this server won’t be used for ordinary fallback selection; it doesn’t disable every kind of fallback. The example depends on geo resources. To send encrypted DNS queries through a proxy, you also need suitable routing and a working outbound. An HTTPS resolver address alone doesn’t prove the query takes the right path.

{
  "dns": {
    "tag": "dns-query",
    "servers": [
      {
        "address": "localhost",
        "domains": ["geosite:cn"],
        "skipFallback": true
      },
      "https://1.1.1.1/dns-query"
    ],
    "queryStrategy": "UseIP"
  }
}

In this example, localhost means system resolution; it doesn’t point to a fixed listening port on the local machine. It’s useful when resolution needs to follow the current network or use internal DNS, but the result depends on system and network settings. If system DNS is redirected back into the core by TUN, check for a loop. Treating “local” and “direct” as synonyms can hide this dependency.

Route DNS traffic through an outbound

To send core DNS queries through a specific outbound, you can match the DNS tag, but check how your core handles these requests. This rule snippet accompanies the earlier example and should go before any broad rule that could match first. It assumes a proxy outbound exists. System resolver calls and resolver addresses with local semantics may not follow the same proxy path. Test each separately rather than inferring the route from the tag alone.

{
  "type": "field",
  "inboundTag": ["dns-query"],
  "outboundTag": "proxy"
}

If a resolver address is a domain, its initial lookup must also be resolved. Using a literal address can reduce bootstrap dependencies, but HTTPS certificate validation and server support still need to work correctly. Don’t disable certificate validation to fix a routing problem. A startup loop can occur if the proxy server’s address needs built-in DNS resolution and that resolution depends on the proxy connection. Give the server address an independently reachable resolution path, or let the system resolve it during startup.

Dual Stack, Caching & Troubleshooting

UseIP lets the config select an address family. Choose IPv4-only or IPv6-only only when you have a reason. An available IPv6 address doesn’t guarantee that IPv6 routing or the exit works. If some sites take a long time to load, temporarily compare behavior with one address family at a time rather than permanently disabling IPv6. Confirm that your core supports the field and value; don’t copy an extension option from a different core.

After changing resolvers, the OS, browser, or core may continue using cached results. For troubleshooting, check lookup results and connection destinations separately. Restart the core or app if needed; you don’t have to reset the device’s entire network every time. An app’s built-in encrypted DNS may also bypass system settings. Check whether it’s enabled in the app, then decide whether to keep it independent or use system resolution. Avoid letting two policies cancel each other out.

If a domain resolves but the site won’t open, check routing, the connection, and server capabilities next. If there’s no resolution at all, check resolver reachability, the DNS outbound, internal domains, and address-family restrictions. A failed lookup and its nearby connection logs are usually more useful than changing several resolver addresses at once. Good DNS configuration makes the path understandable and returns results appropriate to your network—not simply an address that looks fast.

TUN Mode

TUN uses a virtual network interface to capture traffic from apps that don’t follow system proxy settings. It changes the traffic entry point, not the server protocol, and it isn’t a connection service on its own. v2rayN’s system proxy mainly affects apps that read system proxy settings; TUN relies on the interface, routes, and network stack. You still need a working proxy outbound and a correct DNS path. The TUN toggle doesn’t replace the connection checks above.

Record your network baseline first

First, verify the server in regular proxy mode. Record the current default gateway, DNS settings, existing virtual interfaces, and frequently used internal addresses. If you’re on a work network, using remote desktop, or running virtual machines, note which traffic must stay outside the tunnel. VPNs, containers, and virtualization software may also install routes. Without a clear baseline, it’s hard to tell whether a problem after enabling TUN came from the new rules or an existing network path.

On Windows, creating an interface or changing system routes usually requires administrator privileges. macOS and Linux require the appropriate system authorization or permissions. v2rayN’s UI labels, helper components, and startup process can change, so follow the instructions for your current settings. On Android, v2rayNG and v2flyNG usually use the system’s VPN permission to capture traffic. That’s different from running a desktop app as administrator; don’t apply desktop permission steps to Android.

For your first test, disable the system proxy before enabling TUN to avoid having two entry points active at once. Here, “clear system proxy” means changing how apps enter the proxy; it doesn’t stop the core. Once the virtual interface is created, check that the default route and DNS change as expected. If you’re using the connection for remote device maintenance, prepare a local rollback method first so a routing change doesn’t cut off your access.

Stack, Routes & Exclusions

The stack determines how data arriving at the virtual interface is handled. Common options include the system stack and gvisor, but available choices depend on the implementation. Each has tradeoffs in protocol compatibility, resource use, and platform support. Don’t judge performance by the option name alone. Start with the client’s recommended default. If a specific app has compatibility issues, compare options using the same target and outbound so server fluctuations don’t look like stack differences.

The proxy server connection must avoid being routed back into TUN. Clients typically protect this outbound path with interface binding, route exclusions, or another mechanism, but custom configs can break those safeguards. You may lose both regular connectivity and the proxy after startup, or see repeated connections to the same address in the logs. Check the server address’s actual route instead of adding more default routes. If the server is identified by a domain, make sure its exclusion still works when the address changes.

Choose LAN exclusions based on the address ranges you actually use. Common home subnets may not cover work networks, virtual machines, or specialized networks. Excluding only one private range can miss other internal addresses; excluding too much can send traffic direct that should use the proxy. Identify the required subnets and internal domains first, then configure route exclusions or direct rules supported by the client. DNS must be handled as well, or internal routes may work while internal names fail to resolve.

Verify Traffic Capture & Restore on Exit

To test, choose an app that doesn’t read system proxy settings and confirm its requests enter TUN. Then test webpages, LAN access, and features that need UDP separately. UDP failures may come from outbound capabilities, firewalls, remote restrictions, or the stack implementation—not necessarily TUN. A webpage opening in a browser only proves one type of request worked; it doesn’t show that all system traffic is captured. The presence of a virtual interface isn’t a substitute for a connection test.

If the network goes down after enabling TUN, turn TUN off first and check whether regular connectivity returns. Then stop the core and check for leftover interfaces, routes, and DNS settings. Prefer the client’s normal shutdown process instead of immediately deleting every virtual adapter or resetting the whole network. Once the baseline is restored, test permissions, entry point, proxy outbound, and DNS one layer at a time. For terminology, see the glossary, then return to the settings for your platform.

FakeDNS & Domain Mapping

FakeDNS returns an address for internal mapping, not the destination server’s real address. The core stores the association between the domain and synthetic address, then restores the domain when a later request reaches an entry point that supports mapping recovery. Its purpose is to preserve domain information for routing—not to speed up ordinary DNS. Before enabling it, confirm that DNS queries, subsequent connections, and mapping recovery all use the same processing path. Otherwise, the synthetic address becomes an unreachable destination.

Understand the full request path

The complete flow is: the app queries a domain, the query reaches FakeDNS, FakeDNS returns a synthetic address, the app connects to that address, the entry point restores the domain, and the outbound connects to the real destination. Bypassing the core at any stage can break the flow. For example, an app using a different encrypted DNS service may never receive a synthetic address. If it does receive one but its connection bypasses TUN, the domain won’t be restored. Changing the DNS server to fakedns alone isn’t enough.

This example shows an Xray FakeDNS pool and built-in DNS snippet. The selected range is reserved for benchmark testing, but check that it doesn’t overlap with your local network. poolSize sets the size of the mapping pool; it isn’t the number of addresses reserved for public servers. This only illustrates the structure; the entry point also needs matching sniffing and routing. If v2rayN uses another network component for TUN, follow that component’s config format rather than mixing fields across implementations.

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

The entry point must also recognize FakeDNS addresses and restore their domains. Here’s a partial sniffing object for a corresponding Xray entry; it’s not a standalone inbound definition. metadataOnly limits sniffing to metadata and is suitable for illustrating mapping recovery. If you also need HTTP or TLS sniffing, review the target list and options again. Don’t combine sniffing snippets from different sources and assume they’ll work together automatically.

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

Address Pools, Exceptions & Compatibility

The address pool must be large enough for active mappings and must not overlap with your existing network. Address space and pool size are different concepts; increasing the pool size won’t fix an entry point that isn’t capturing traffic. Frequent restarts may clear mapping state while apps still have old addresses cached. Those apps may then connect to synthetic addresses the core can no longer resolve. This can look like everything works after startup, then some apps fail after a config change.

Internal domains usually need real DNS results because they may be excluded from TUN or rely on local network addresses. Give them an explicit real-DNS path and verify that subsequent connections also use the internal network. Don’t send an internal IP direct while still returning a synthetic address for its domain. Some apps inspect DNS results or use resolved addresses for purposes beyond connecting, so they may need exceptions too.

FakeDNS addresses are internal mappings, so the usual assumption of resolving a domain and then matching its real IP may no longer hold. First confirm that domain restoration happens before routing and check how your implementation processes synthetic addresses, domains, and IP rules. In particular, don’t assume direct connections, internal addresses, and rules that need real IPs will behave correctly with the same IP set. If you mainly need domain-based routing, test with explicit domain rules first and expand from there.

Enable and disable in stages

Keep a working baseline with regular DNS and TUN before enabling FakeDNS. Check whether a domain query returns an address from the pool, then confirm that the same app’s connection is restored to the domain. Proceed to traffic routing and LAN tests only if both steps work. If the query never reaches FakeDNS, check the DNS entry point first. If the app gets a synthetic address but the connection fails, check traffic capture and mapping recovery—not a succession of upstream resolvers.

When disabling FakeDNS, account for cached results too. Restore real DNS first, then restart apps holding synthetic addresses and clear the system DNS cache if needed. Turning off the capture entry point while leaving old DNS results in place can cause temporary connection failures. Don’t put synthetic addresses in static host mappings, server addresses, or long-lived rules; they’re only meaningful in their mapping context. Confirm that real resolution is restored before deciding rollback is complete.

Managing Multiple Subscriptions & Isolating Updates

Managing multiple subscriptions isn’t about merging every entry into one long list. It’s about keeping sources, updates, and usage traceable. Different sources may use similar notes or return the same server with different parameters. Treat groups as update boundaries, the active server as the connection boundary, and routing as the traffic boundary. Managing these separately lets you keep other groups and a working connection when one source fails, instead of rebuilding the entire config.

Separate update responsibilities by source

Create one group for each independent source rather than combining multiple URLs in one field. Use notes to describe the purpose, not to store access parameters or personal details. Update groups manually at first and check the import format, filters, and server changes before scheduling automatic updates. If two groups use the same source but different filters, remember that they still send duplicate requests to that service. Combine them if separate updates aren’t needed.

Set update frequency according to how often the source changes and how often you use it—not as frequently as possible. Frequent updates mean more requests and may change server entries during testing. To compare connection performance, consider pausing automatic updates for the relevant groups and testing with a stable config. After an update, make sure the expected server is still selected, especially if an entry was removed or recreated. Don’t rely on the client to preserve your selection without checking.

When one group has an update problem, troubleshoot that group alone. Check the URL and authorization first, compare direct and proxy-based fetches, then inspect the response format. Other groups updating successfully only proves their sources are reachable; it doesn’t rule out a problem with the failing URL. If every group fails, look for a shared change in the network, DNS, or proxy entry point. Narrowing down the scope avoids needlessly reimporting every source.

Duplicate Entries & Test Results

Don’t deduplicate entries by note alone. Servers with the same note may use different ports, protocols, transports, or encryption parameters; entries with different notes may point to the same connection. Compare key connection fields before deleting an entry, and keep track of its source. You can describe differences in a tutorial or support request, but don’t share full connection parameters. If you keep an entry for long-term use, record its source and purpose so you can identify it after the next update.

Latency checks, real connection tests, and bandwidth tests measure different things. A single ranking isn’t a definitive choice. Results also depend on your local network, test target, concurrency, and server load. When comparing groups, use the same test method and target within a similar time window, and keep a known-good entry as a reference. For details, see Tcping vs. real connection latency vs. download speed tests.

Don’t choose a server based on its region label alone. Labels usually come from the source’s notes and may not accurately describe the entry point, exit location, or actual route. Multipliers, protocol compatibility, and usage restrictions also matter. A low-latency result doesn’t necessarily mean an entry is suitable for sustained transfers or a particular app. A short list of candidates for everyday use, specific tasks, and backup is easier to maintain than a constantly changing ranking of every entry.

Backups & Removing a Source

Config backups may contain subscription URLs, server credentials, custom outbounds, and routing rules. Store them securely; don’t share them as ordinary screenshot attachments. When restoring, first confirm client and core compatibility, then import groups one at a time. Don’t automatically reuse expired URLs from an old backup as new update sources. A successful restore only means the config was read. You still need to verify connections, DNS, and routing on your current network.

When you no longer use a source, switch the active server, disable its updates, and check whether any routing rules or custom outbounds still reference its entries. Delete the group only after confirming there are no dependencies. Removing a local group doesn’t cancel authorization or service on the source’s side; handle that through the source’s own management tools. If you’re only taking a temporary break, keep the group and disable it clearly. That’s easier to restore than copying its URL into temporary entries, and it helps limit where sensitive data is stored.

Custom Outbounds & Core Compatibility

Custom outbounds define how requests leave the core. Common roles include connecting directly, blocking requests, or forwarding them through an existing proxy service. Routing refers to outbounds by tag; a tag is an internal identifier, not a server note or subscription group name. Define clear outbound roles before writing match rules to avoid mismatched tags, unexpected defaults, and local edits being overwritten by client-generated configs. For everyday use, prefer configuring these options in v2rayN’s UI.

Define tags and the default route

This Xray snippet defines direct and block outbounds but no proxy server. It illustrates the structure of freedom and blackhole; don’t replace your entire outbound list with it. If these are your only two outbounds, unmatched connections will usually use the first one, the direct outbound. To use a proxy by default, keep the proxy outbound generated by the client and check the outbound order and fallback rules. Renaming its tag to proxy isn’t enough.

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

Keep tags short and tied to stable roles. Use different tags for direct connections, blocking, and each fixed proxy entry point. Avoid duplicate tags and don’t assign different meanings to the same tag in different files. Routing references must exactly match outbound tags. When changing an outbound, search for all related rules and references, especially DNS queries and app-specific rules. An outbound that isn’t referenced won’t automatically handle any requests.

A block outbound is useful for requests you know shouldn’t be sent, but it isn’t a general fix for connection failures. Blocking every unknown domain may also break authentication, resources, and update requests that an app depends on. A direct outbound still relies on the device’s network and DNS; it doesn’t guarantee access to every destination. Define each outbound’s scope and test targets rather than giving it a vague name like “fast” or “secure.”

Local Forwarding & Proxy Chains

This snippet forwards traffic to a local SOCKS service. It assumes a separate service is already listening at 127.0.0.1:10808; the snippet doesn’t create one. If that port is actually an inbound on the same core and the inbound routes back to this outbound, you may create a loop. Confirm what’s listening, where the inbound sends traffic, and where it exits. Being able to connect to a local port doesn’t prove the forwarding path is correct.

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

A proxy chain links several processing stages, adding dependencies for connections, resolution, and failure handling. Map each hop’s inbound and outbound first. Then check where the destination domain is resolved, whether UDP can be forwarded, and what happens if any stage stops. Not all outbounds support the same chain configuration fields. Use the config structure for your current core; don’t paste fields from another implementation into an existing object.

The listening address defines another boundary. An entry intended only for local use should usually bind to a loopback address. Listening on every interface expands access and requires authentication and firewall rules. Don’t expose an unauthenticated proxy just to let another device connect. The service used with the local SOCKS snippet should also have a clear port, startup order, and shutdown behavior, so the downstream core doesn’t start at boot while its upstream service is unavailable.

Client-Generated Configs & Core Compatibility

v2rayN generates the runtime config from your UI settings. Direct edits to a temporary generated file may be overwritten when you switch servers, save settings, or restart. Prefer the client’s custom config or extension options, and check whether they merge a snippet or replace the full config. These have different requirements: full replacement usually means supplying your own inbounds, outbounds, routing, and DNS. Merging requires understanding tag conflicts and override order.

Xray and V2Fly share some basic concepts, but their protocol support and extension fields aren’t interchangeable. v2rayNG primarily uses Xray ecosystem configs; check V2Fly support for v2flyNG. A protocol appearing in the UI doesn’t mean every transport combination is supported. For core differences, see Client and core comparison and Xray vs. V2Fly: key differences.

Save a working baseline before switching cores, then check protocol, transport, security, routing, and DNS fields one by one. Test a single connection first, then restore custom outbounds and complex rules. Use the logs to fix startup errors rather than deleting every unfamiliar option. A successful startup only confirms that the syntax and some initialization steps passed; test real requests to verify each outbound and rule behaves as expected.

Configuration Verification & Rollback

After making advanced changes, follow a consistent verification process instead of assuming success because one webpage loads. Verify startup, proxy connections, DNS resolution, rule matches, special entry points, and recovery on exit separately. Use a specific target for each test and record the change and result. If something breaks, roll back the most recently changed component while keeping the rest of the working config. This avoids removing settings that are fine and gives you repeatable conditions for the next change.

Check each layer, from startup to connection

First, check whether the core starts. Look for the first clear error and the nearby field details. Distinguish JSON syntax errors, unknown fields, missing resources, and occupied ports. JSON doesn’t allow comments or trailing commas, and partial snippets can’t simply be concatenated as multiple top-level objects. Even if the client says “running,” confirm that the core doesn’t exit right away. If errors repeat, stop automatic restarts or repeated startup attempts before reviewing a complete error log.

Next, check whether the inbound accepts requests. Confirm that the app’s proxy address and port match the active listener and that the system proxy setting matches the entry point you’re using. Once the inbound accepts connections, check the server connection and protocol handshake. Timeouts, connection refusals, and authentication failures are different issues; don’t try to fix them all by changing DNS. Compare the complete fields in the authorized server config, not just the server address.

Then check DNS and routing. Test one destination expected to go direct and one expected to use the proxy. Compare destination details and outbound tags in the logs. Start a new connection when testing a rule to avoid reusing an old one. If the logs show only an IP, check whether the inbound preserved the domain, sniffing worked, or FakeDNS restored it. Missing domain information and incorrect rule order can both cause a miss, but they need different fixes.

Build a small, repeatable test set

The test set doesn’t need to be large, but it should cover your goals: a regular webpage, an internal service expected to go direct, a request that needs the proxy, and any special app you actually use. Record whether TUN or FakeDNS is enabled, which server you selected, and the network conditions. Don’t compare mobile and fixed-network results as if they came from the same setup. If a problem occurs on only one network, keep that distinction and check network-specific DNS, exit routes, and firewall conditions first.

Speed tests can provide extra information, but they don’t replace functional tests. A fast handshake doesn’t prove app authentication works, and high download speeds don’t prove DNS and routing are correct. If a test fails, first get a real request through the simplest config, then restore filters, routing, TUN, and other components. Don’t switch servers and cores at the same time; you won’t know which change fixed the problem. Changing one thing at a time makes lasting fixes easier to identify.

Raise the log level only as much as needed while troubleshooting, then restore your normal settings. Logs may contain destination domains, server addresses, and sensitive parameters; review them carefully before sharing. Usually it’s enough to include the error type, field name, relevant context, and steps to reproduce. Don’t post full subscriptions, complete configs, or continuous logs. A useful support request explains what changed, what you expected, and what happened—not just a screenshot of a failed connection.

Layered Rollback & Maintenance Notes

Roll back in reverse order of changes: remove the last-added rule or outbound first, then restore DNS, then undo entry-point changes such as TUN and FakeDNS. If the entry point was your last change, disable it first to restore control of the connection. Retest after each rollback so you don’t lose evidence by undoing several components at once. Once the baseline works again, copy it for your next round of changes instead of adding more rules to an unexplained mixed state.

Maintenance notes can include just the date, component, reason for the change, test results, and rollback location—never credentials. Automatic subscription updates, network changes, and core switches are all reasons to test again. After an update, check the active server. After changing networks, check internal DNS and routing. After switching cores, check field compatibility. Retesting what changed is easier than rebuilding the config from scratch and helps pinpoint the true boundary of a problem.

If you just need to restore a working everyday connection, return to the subscription import and connection guide. You don’t need to set up every advanced feature at once. For installers, use the platform downloads; for troubleshooting, visit the Help Center. Apply only the sections you need. A small set of clear, verifiable settings is easier to maintain than a growing stack of options.