Advanced V2Ray Configuration Guide

Subscription Groups and Server Filtering

Subscription groups organize configuration sources; they do not determine where traffic goes. A group typically stores a subscription URL, display name, update options and filtering rules. The server list is generated when the subscription is updated. Moving a server to another display group does not create a proxy rule for a particular app. Before making changes, distinguish source management, the currently selected server and traffic routing so you look for each setting in the right place.

Create Traceable Groups for Each Source

In v2rayN's subscription group settings, create a separate entry for each source. Name groups by purpose and source, such as “Daily – Main” and “Testing – Backup.” Paste the full subscription URL, checking for spaces or line breaks at either end. Save it, then update that group rather than updating every source at once. For the first update, check only that group's results. Once servers appear as expected, add other subscriptions.

A server name is just a note provided by the remote source, not reliable proof of its capabilities. Labels mentioning a region, route or multiplier do not replace checking protocol settings, and they cannot guarantee the actual exit location. When choosing a server, check that its protocol, transport, encryption and security settings are supported by the core. For help choosing a core, read Xray vs. V2Fly: Core Differences before deciding which configurations to keep.

Keep Temporary Searches Separate from Persistent Filters

List search usually changes only what's displayed; clear the search term and the servers are still there. Subscription filters, by contrast, can change which entries are imported during the next update. The simplest way to tell them apart is to clear the search and see whether the original servers reappear. Before enabling a persistent filter, note what the unfiltered list contains and keep at least one verified working server. Otherwise, a bad filter expression can make an empty list look like a failed subscription.

Some clients use plain keywords in filter boxes; elsewhere, the same-looking field may accept regular expressions. Don't infer how it works from the field name alone. If the interface explicitly says it uses regex, 测试|备用 matches either term. Whether matches are kept or excluded depends on the option's meaning. Test with a server name you know is present before widening the filter. Avoid complex lookarounds at first, since regex support varies between implementations.

After an update, check for duplicates, missing entries and selection changes

An update may rebuild entries or merge them with existing records, depending on the client. Don't assume the currently selected server will remain selected. After updating, check the selection indicator, protocol settings and availability. Keep manual entries you want to retain in a separate local group, or export a backup before updating. Don't rely on editing a remote server's note to preserve personal settings; the next update may overwrite your changes.

If an update succeeds but no servers appear, clear the list search, check the current group, temporarily disable subscription filters, then confirm that the client can parse the response. If an update fails, don't delete the existing group right away; its servers may still work. On Android, distinguish subscription groups from the current view as well. v2rayNG and v2flyNG have different interfaces, but in both, update one group, check the results, then select a server. Once you know which source each entry belongs to, you can trace later changes to a specific update.

Routing Rules in Practice

Routing selects an outbound for a connection after it enters the core. Rules can match the destination domain, address, port, network type or inbound tag. A client's “rule mode” generally selects a preset routing configuration; it doesn't mean the core can automatically infer what every app is for. Before adding your own rules, check which configuration is active and back up the existing rules. Saving a rule in an editor doesn't necessarily mean the running core has loaded it.

Understand Match Order and Rule Conditions

Routing rules are generally checked from top to bottom, and the first match determines the outbound. Put specific rules before broad ones. For example, add full-domain rules for traffic that needs a proxy, then direct rules for local network addresses, and only then consider the fallback behavior. Different conditions in one rule usually all need to match, while multiple values in the same condition field generally mean any one can match. Filling in a domain, port and network type on the same row narrows the match; it doesn't create three independent ways to match.

Domain matching also varies in scope. An exact domain match suits a single host; a domain-and-subdomains match can cover a whole service; keyword matching may catch unrelated sites with similar names. Start with the narrowest scope and expand gradually. Don't route all traffic through a proxy just to fix access to one download domain. That might restore access temporarily, but it can hide an overly broad rule, a missing dependency domain or a DNS routing problem.

Start by Verifying One Clear Rule

This partial example shows common Xray JSON routing fields and how a full domain, a private address and an outbound tag fit together. It is not a complete client configuration: merge it into the running configuration, and make sure the proxy and direct outbounds are already defined. The example domains illustrate matching syntax only. For a real test, replace them with the destinations you need to handle.

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

AsIs does not resolve domains specifically for IP rules, but an IP rule can still match when the connection already includes a destination IP. If a domain connection doesn't match a domain rule, a private-address rule alone won't necessarily cause the domain to be resolved and identified as local. For internal domains, add explicit domain rules or choose a different domain strategy after considering its effects. Using geoip:private also requires the relevant data files to be available; fix any loading errors first.

Fallbacks, Sniffing and Existing Connections

When no rule matches, the core usually uses the first outbound in the list, though the client may generate an additional final rule. Check the generated configuration rather than relying on the last line in the interface. To send unmatched traffic through a specific outbound, use the client's final outbound setting if available. In a manual configuration, specify which inbounds or network types it covers; avoid empty conditions with unclear meaning. Changing the default outbound order can also redirect previously unmatched connections.

Sniffing can recover an HTTP host name or TLS server name from some connections, but it cannot identify every encrypted protocol. It may not reveal domain names when encrypted handshake information is enabled, either. Treat sniffing as an additional source of information, not a replacement for DNS. After changing a rule, test with a new connection: existing long-lived connections usually won't switch outbounds automatically. If needed, close and reopen the test app rather than repeatedly refreshing the same page.

If a rule doesn't take effect, first confirm that traffic enters the client. Then check whether the rule is enabled, whether the destination actually matches, whether a broader rule comes first, and whether the outbound tag is spelled correctly. In system proxy mode, apps that ignore the system proxy never enter this routing chain. If the cause is still unclear, see the proxy mode guidance in the Help Center. Fix the traffic entry point before changing the routing rules.

DNS Configuration

DNS configuration involves two separate questions: who resolves a domain, and which network path carries the DNS request. The browser, operating system, client core and remote server may all play a part. Successfully opening a website doesn't mean every app uses the same DNS path. If an app is unaffected by a system DNS change, that doesn't necessarily mean the change failed; the app may use its own encrypted DNS service or separate cache.

Map the DNS Resolution Path First

In system proxy mode, an app may send the domain to a local proxy for resolution by the outbound or remote server; it may instead resolve the domain locally and send the resulting IP to the proxy. In TUN mode, whether the client handles DNS depends on the virtual interface, DNS interception and how the app sends its requests. Before tuning DNS, note the system resolver, client DNS options and browser secure DNS settings. Change one layer at a time to see which one affects the result.

The domain used to connect to the proxy server is especially important: the client must find the server before it can send traffic through it. Forcing DNS requests for that server through a proxy that isn't up yet can create a startup dependency loop. A safer approach is to keep an accessible bootstrap DNS path for the server address and make its direct connection conditions explicit. If the proxy disconnects, the client still needs to resolve the server to reconnect; otherwise, reconnection will keep failing.

Separate Domain Strategy from Address-Family Strategy

Routing's domainStrategy controls whether domains are resolved for IP rule matching. DNS's queryStrategy controls which address families are used for queries. The domain strategy on a direct outbound affects how domains are handled before dialing. These fields appear in different places; similar names don't make them interchangeable. This minimal partial example uses the system resolver as a baseline for built-in DNS, so you can first check whether complex split-DNS settings are the source of the problem.

{
  "dns": {
    "servers": ["localhost"],
    "queryStrategy": "UseIP"
  }
}

This snippet won't automatically take over every DNS request on the system, nor does it guarantee that every outbound will use the built-in resolver. Actual use depends on routing policy, outbound settings and client integration. If the existing configuration has resolver entries filtered by domain, replacing the entire DNS object will remove those rules. Export the original configuration first, then test. If the problem disappears with the baseline restored, add the original servers and filters back one at a time.

Handle IPv6, Caches and Internal Domains

On a dual-stack network, first confirm that IPv6 is actually reachable across the local network, proxy server and destination service. Receiving an IPv6 address alone doesn't prove the connection will work. If logs repeatedly show address-family connection errors, temporarily restricting tests to IPv4 can provide a useful comparison. Don't treat permanently disabling IPv6 as a universal DNS fix. After testing, decide whether to keep the restriction and check whether it affects internal services that were working before.

Corporate intranets, router admin names and device discovery often rely on local DNS. Sending every domain to a public resolver can break them. Keep internal domains on the system resolver or a designated LAN resolver, and make sure their destinations use a direct route. After changing DNS, account for the different lifetimes of system and app caches. Restarting the test app is usually more useful than switching resolvers repeatedly; existing connections may not look up the domain again.

When troubleshooting, distinguish “query timed out,” “returned an unsuitable address” and “address is correct, but the connection failed.” For timeouts, check resolver reachability and request routing. For unsuitable addresses, check filters and caches. For connection failures, continue with the outbound, destination port and network. Encrypted DNS changes how queries are transported; it doesn't automatically fix incorrect routing or make an unreachable server address connect.

TUN Mode and System Traffic Capture

TUN sends IP-layer traffic to user-space through a virtual network interface. It is useful for apps that don't follow the system proxy but still need consistent routing. It isn't a “more powerful global proxy” switch: once traffic enters TUN, routing rules still determine whether it goes direct or through a proxy, and the result still depends on outbound protocols, UDP support and DNS handling. System proxy and TUN use different entry points. Test each separately before deciding whether to use both.

Check the Capture Component, Permissions and Baseline

v2rayN may rely on a companion component for TUN; don't assume the TUN switch in the interface adds a field with the same name to Xray. First confirm that ordinary proxy mode works and the current server is usable. Then check the required permissions, component status and logs. Android VPN permission allows traffic capture; it doesn't mean Android uses exactly the same virtual interface implementation or configuration format as desktop clients.

Before enabling TUN for the first time, keep a local way to restore your settings. Close other tools that are capturing network traffic, save your current Wi-Fi or Ethernet DNS and proxy settings, then enable TUN. Check whether the virtual interface appears, whether the default route changes and whether test traffic shows up in the logs. If the interface says TUN is active but there are no corresponding connection records, check the interface and routes before switching servers.

Avoid Loops and Preserve LAN Access

Connections from the proxy client to its server must not be captured again as traffic to proxy; otherwise, the result can be a loop or repeated retries. Well-designed capture components typically provide automatic routing or interface binding, but manual route changes can still break those protections. If the proxy disconnects as soon as TUN is enabled, first check whether the server address is being captured by mistake, then check for multiple virtual interfaces competing for the default route.

LAN devices, printers and router admin pages usually need direct access, but private-address rules may not cover device discovery. Broadcast, multicast and name-based discovery are separate issues; whether they work through a virtual network depends on the implementation and system environment. If a device's IP is reachable but its name isn't, investigate DNS or the discovery protocol instead of continually widening the proxy scope. Private addresses on a corporate network can overlap with your local subnet, so use more specific route boundaries.

Test TCP, UDP and App Scope in Stages

First verify the entry point and outbound with a clear TCP request, then test the UDP apps you actually need. If web pages work but voice or real-time communication doesn't, the issue may be UDP forwarding, server capability or network policy; it doesn't necessarily mean TUN is completely broken. If an app has QUIC issues, record its UDP path separately. Temporarily disabling the app's related feature is useful for comparison, but doesn't replace checking the underlying forwarding support.

Running system proxy and TUN at the same time may be intentional in some clients, or it may cause an app to connect to the local proxy and then have that connection captured by TUN. During troubleshooting, keep just one known entry point active. Once it's working, restore the combined setup if needed. On Android, an excluded app may bypass client routing completely, so its results can't verify core rules. Battery restrictions can also interrupt a capture session in the background; distinguish a stopped process from a disconnected server.

If the network doesn't recover after TUN is disabled, check whether the virtual interface, default route and system DNS have returned to their previous state. Also check whether the system proxy still points to a local listening port that is no longer running. Don't delete every network adapter or reset all network settings; that expands the scope of the problem. Revert only the capture settings added in this session, then reconnect to the current network. This is more likely to preserve existing corporate network and local device settings.

How FakeDNS Works and When to Use It

FakeDNS returns a synthetic address that maps to a domain locally. When the connection enters the proxy processing chain, the original domain is recovered from that mapping. This preserves domain information when an app has already resolved a domain to an IP but routing still needs to match by domain. It does not assign a real address to the destination site. Synthetic addresses work only within the corresponding capture and mapping chain; ordinary network devices have no way to know which domain one represents.

Keep Queries, Mappings and Connection Recovery in Sync

A complete chain has at least three steps: an app queries a domain and receives a synthetic address; the app connects to that address; and the capture component looks up the domain from the address and passes it to routing. Enabling only the first step can give the app an address it cannot connect to directly. Enabling domain sniffing alone doesn't guarantee recovery of the FakeDNS mapping. Use an integrated option provided by the client, and confirm that compatible components handle DNS and traffic capture together.

In v2rayN, first check whether the current TUN component supports FakeDNS rather than pasting an online core snippet into every settings field. v2rayNG, v2flyNG and desktop clients may integrate it differently; support depends on both the core and client implementation. If the menu doesn't offer the feature, don't assume a new field can provide the entire chain of interface capture, DNS interception and address recovery.

Understand the Address Pool and Mapping Capacity

This example shows a common Xray FakeDNS object using a dedicated test address range as its synthetic pool. It's a partial syntax example, not a standalone traffic capture configuration. Built-in DNS must call FakeDNS, and a compatible inbound must restore the mapping. If your client uses another capture component, use that component's own syntax; don't mix fields from different implementations.

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

ipPool sets the range of synthetic addresses available for mapping, while poolSize sets the mapping pool capacity. Neither value represents concurrent connections, and a larger pool isn't automatically faster. Before configuring the pool, check that the synthetic subnet isn't used by your test network or special routes. Don't casually use a common home LAN subnet; real device addresses can conflict with synthetic ones, suddenly making some devices unreachable.

Mapping lifetimes matter too. After a core restart, old mappings may disappear even while the system or app still caches the previous synthetic addresses. A new connection can then reach the client without the original domain being recoverable, causing some apps to fail after a restart even though they worked before. Have the app make a fresh DNS query, and if needed, quit it and clear its relevant cache. Don't enlarge the pool to mask a mismatch in mapping lifetimes.

Decide Which Apps Need Real Addresses

Some apps check DNS response addresses, compare an address with certificate information, or pass the resolved result to another process that bypasses the proxy. Synthetic addresses may not suit these cases. Test LAN management, device discovery, some real-time communications apps and programs that rely on real address checks separately. If the client supports real DNS resolution for selected domains, create exceptions for these destinations and verify their routing and DNS request paths as well.

A browser's own encrypted DNS may bypass the expected FakeDNS entry point. As a result, some apps on the same device may get real addresses while others get synthetic ones. If this happens, note how each app resolves domains rather than assuming the whole chain works because a webpage opens. Test at least a regular website, a destination that needs domain-based routing, a LAN address and an app that should not use the proxy.

Remove Dependencies When Disabling the Feature

Disabling FakeDNS means more than turning off the mapping pool. Restore the normal DNS path, confirm the client no longer returns synthetic addresses to apps, and invalidate existing caches. If you disable capture first but keep synthetic DNS responses, apps will try to send traffic to synthetic addresses over the regular network, and the problem will persist. Follow the client's integration-specific rollback order, but make sure DNS results and traffic capture are consistent again at the end.

Introduce FakeDNS only after regular DNS, routing and TUN are stable. If you need to fix domain-based routing for one destination, first check whether an explicit domain rule will do the job. Add this mapping layer only when domain information is genuinely lost and the capture chain can restore it. Logs should show the benefit; don't judge it solely by a subjective impression of speed after one visit.

Managing Multiple Subscriptions and Update Policies

Managing multiple subscriptions is about keeping sources, purposes and changes traceable, not merging every server into one longer list. Define clear roles for your main, backup and test subscriptions. Use the main subscription day to day, keep the backup for manual switching, and use the test subscription for new protocols or configurations. Putting servers in different groups doesn't provide automatic failover or route traffic based on group names.

Keep Each Source Separate

Give each new source its own group. Update that group alone, then check protocol types, entry names and filter results. Even if two sources use the same note, keep their source information; matching names don't mean they are the same server. Compare addresses, ports and transport parameters locally, and redact credentials from anything you share for troubleshooting. Don't merge sources just to tidy the list, or it will be harder to tell which update introduced an entry.

Whether two entries are duplicates depends on how they're used. The same server address and port may still represent different configurations because credentials, transport paths or security settings differ. Different notes may also point to the same service. A client's deduplication feature usually checks only a limited set of fields; it can't replace manual review. Before bulk deduplication, export a local backup and make sure at least one entry can connect so a mistake doesn't leave you waiting for the remote source to send the server again.

Make Updates Easy to Observe

Subscription updates change the set of available servers, so avoid running them during long downloads, remote management or important sessions. Update a backup or test group first and check for problems before updating the main group. If automatic updates let you choose an interval, base it on how often the source actually changes, not on the idea that more frequent is better. Excessive requests may trigger rate limits and keep changing your local list, making troubleshooting harder.

Check separately whether subscription updates use a proxy. Some sources are reachable directly through the current network; others need an existing proxy connection. If an update depends on the current server and that server has failed, you can end up in a loop: you need an update to recover, but the update relies on the failed connection. If the client offers different update methods, switch the request path only after verifying that the source is trustworthy. Don't paste a subscription URL into an unknown online conversion service to try to fix it.

Keep Personal Settings Separate from Remote Content

Maintain subscription-provided server information separately from personal routing. Store personal LAN direct rules, app scope and DNS exceptions in dedicated client settings where possible, rather than editing a temporary configuration generated from the subscription. Generated files may be rebuilt when you switch servers, update subscriptions or restart. Changes made only in a temporary file will disappear the next time it is rebuilt, which can make it seem as though the client didn't save them.

Remote subscriptions can also contain complex configuration data. First find out whether the client imports a server list or a complete configuration. These have different levels of control: a server list usually adds connection parameters, while a complete configuration can change routing, DNS and listening behavior. Check the format description before importing, then review the actual runtime settings, especially LAN listening and the default outbound. Don't judge the contents by the file extension alone.

Preserve and Recover After a Failed Update

A single failed update is no reason to delete the old list. First determine whether it was a connection timeout, an unexpected response status, an empty response or a parse error; each calls for a different fix. If the existing servers still connect, keep them for now and stop refreshing repeatedly. If the subscription URL has changed, get the new URL from a trusted source and replace it in the existing group instead of creating several records with the same purpose but different states.

A backup subscription is useful because you can verify it independently. Check occasionally that it still updates, has usable servers and is supported by your core instead of waiting for the main subscription to fail. See Three V2Ray Clients Compared: Platforms and Features for the clients' capabilities and limitations. Once the sources are separate, you can consider automatic selection or load balancing without confusing subscription management issues with outbound scheduling.

Custom Outbounds and Configuration Composition

Outbounds define how connections leave the core; routing rules refer to outbound tags to choose the method. Common outbounds include proxy protocols, direct connections and blocking. Adding an outbound object doesn't make traffic use it automatically: a routing rule must match it, or it must be the default outbound. Conversely, a route that refers to a nonexistent tag won't create a connection method. Check that tags match before anything else when customizing a configuration.

First Identify What Generates the Configuration

In v2rayN's standard server mode, the runtime configuration is usually generated from the current selection and interface settings. Direct edits to the generated result may disappear the next time you switch servers. To add a custom outbound, prefer an advanced configuration option explicitly provided by the client. If you choose a fully custom configuration, confirm which interface toggles still apply and which fields are now controlled by your file. Mixing both approaches is a common cause of changes in the interface having no effect at runtime.

Android clients also distinguish between editing a regular profile and importing a complete configuration. v2rayNG primarily uses Xray, while v2flyNG uses V2Fly. Support for the same server list doesn't mean every outbound field is compatible. For protocol-specific or security settings, check the target core's support first. See The Project V Open-Source Ecosystem for an overview of the community, rather than guessing what a client can do from its name.

Verify the Tag Chain with Direct and Block Outbounds

This minimal local SOCKS configuration for Xray lets you verify how inbound, routing and outbound tags work together. It provides direct access and blocks an example domain; it doesn't include a proxy server. The listener is restricted to the local loopback address and UDP is disabled, making this suitable for an isolated test. Don't overwrite your active configuration, and check that the local port is free before testing.

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": false
      }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ],
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["full:example.com"],
        "outboundTag": "block"
      }
    ]
  }
}

Configure the test app to pass the domain to the SOCKS proxy instead of resolving it locally first; otherwise, the example's full-domain rule may not match. This configuration doesn't enable sniffing to recover domain information, so the test conditions stay clear. Unmatched connections use the first outbound, direct. Changing the outbound order also changes the default behavior, so don't focus on tags while overlooking their order.

Add a Proxy Outbound and Understand Chaining

To add a proxy outbound, start with a verified working server configuration. Keep its protocol, server address, port, user parameters, transport and security settings, then assign it a unique tag. Don't copy only the address and port; handshake failures often come from a mismatch in the transport path, server name or security parameters. Give each tag a clear purpose, such as main or backup proxy, so the logs show which outbound is in use.

A chained connection uses one outbound to establish the underlying connection for another; it doesn't mean two routing rules run in sequence. After the first routing rule matches, the same connection usually isn't passed to the next rule. Outbound chaining fields and transport support vary between cores, so use the syntax for your target core. Avoid circular dependencies, such as outbound A relying on B while B relies on A, or a domain lookup that depends on the very chain it needs to establish.

Load balancing selects among candidate outbounds and also requires availability monitoring, a selection policy and session persistence. Putting multiple outbounds in an array doesn't automatically rotate between them or detect failures. If you only need to switch to a backup server occasionally, manual selection is easier to verify. Use a more complex setup only when you need automatic scheduling and can explain the health status of each candidate.

Configuration Validation, Log Analysis and Rollback

A configuration that saves successfully may still fail to start, and a running core doesn't guarantee that traffic uses the expected outbound. Validate advanced configurations in stages: check syntax and resource loading, then the local entry point, followed by routing, DNS resolution and the remote connection. Before each change, write down the expected result, such as “only this exact domain uses the proxy; LAN traffic stays direct.” This makes it easier to identify which layer failed when a test doesn't work.

Keep Reproducible Change Records

Back up subscription groups, manual servers, routing rules, DNS and traffic capture settings—not just the server list. Exported files may contain credentials, so store them securely. Record the exact fields changed, with their old and new values, and distinguish between client-generated and fully custom configurations. If several interface toggles work together, save screenshots of each setting before changing anything so you can restore them later.

Change one topic at a time: verify subscription updates first, then adjust routing, handle DNS next, and introduce TUN and FakeDNS last. After a change, restart the core or use the client's explicit reload option, then confirm it starts before testing your apps. Don't update subscriptions, switch cores and change DNS all in one session; even if the connection recovers, you won't know which change fixed it.

Read Logs Along the Traffic Path

First check whether the local entry point received the connection. If there's no entry record, check the app's proxy settings, port, TUN scope and per-app exclusions instead of investigating the remote handshake. Once the entry is confirmed, check the routing target and outbound tag. If the tag is wrong, inspect rule order and destination details. Only after the tag is correct should you check DNS, dialing, the handshake and the server response. This order avoids repeatedly changing settings at the wrong layer.

If you temporarily increase log verbosity, limit the test window and restore the normal level afterward. Logs may contain visited domains, server addresses and connection details, so redact them before sharing. Diagnose connection timeouts by stage: a resolution timeout points to DNS, a dialing timeout to the network or port, and a handshake error to protocol settings, security parameters or system time. The final log line alone is rarely enough to identify the cause.

Use Comparison Tests, Not a Single Speed Test

Your test set should include destinations that need the proxy, destinations that should go direct, a LAN address and the apps you actually use. Start a new connection for each test so an existing session doesn't hide a routing change. Availability, connection latency and transfer speed measure different things. One successful latency test doesn't prove DNS, UDP or large transfers work. Don't automatically blame the proxy configuration for an error returned by the destination service itself.

If only one app fails, compare it with another app on the same device and check its independent DNS, proxy behavior and cache. If all apps fail, narrow the problem down to the system network and client entry point. If ordinary proxy mode works but TUN doesn't, keep the same server and compare only the entry method. If the problem persists after switching servers, check the shared local configuration before changing more servers.

Undo Changes in Reverse Order

When rolling back, remove the last complex layer first, then restore the original routing and DNS. After disabling FakeDNS, deal with cached synthetic addresses. After disabling TUN, confirm the system routes and resolver are back to normal. Before stopping the client, make sure the system proxy no longer points to its port. If a subscription update caused the problem, restore that group's backup; there's no need to delete unrelated local rules. The more precisely you roll back, the easier it is to keep changes you've already verified.

If the issue remains, gather the client name, operating system, entry mode, core type, reproduction steps and redacted log excerpts, then work through How to Diagnose Runtime Errors in Logs. If the connection still fails after restoring the original baseline, revisit the Quick Start Guide to verify the basics. The goal of configuration maintenance isn't to enable more options; it's to ensure every option has a clear purpose, observable results and a reliable way to undo it.