Advanced V2Ray Setup Guide

CHAPTER 01 / BASELINE

Configuration baseline: separate the client, core, and system network layers

The most common advanced-configuration problems are not typos in individual parameters, but settings from different layers being mixed together. v2rayN, v2rayNG, and v2flyNG are graphical clients that import subscriptions, select servers, generate configurations, and control connection status. Cores such as Xray and V2Fly execute protocol, routing, DNS, and outbound logic. System proxies, virtual network adapters, and application-level network settings determine whether traffic actually reaches the core. During troubleshooting, first identify the affected layer; repeatedly changing servers can otherwise hide the real problem.

Create a recoverable starting point

Before making adjustments, export the current working configuration from the client or record the subscription source, active server, proxy mode, routing plan, and DNS settings. v2rayN stores subscription data, server lists, and routing plans as client-managed data, while the runtime configuration generated by the core may change with interface options. Do not treat a copied fragment of temporary JSON as a complete backup. On mobile, also record whether the VPN service, per-app proxying, and LAN bypass are enabled, since these options change the actual traffic scope.

A configuration baseline should meet three conditions: a regular browser can access the network as expected; client logs contain no recurring startup errors; and the selected server entry includes a complete address, port, user identifier, transport method, and security parameters. Only with a working baseline do routing and DNS comparisons become meaningful. If the basic connection is not ready, return to the Getting Started workflow and proceed through subscription import, server selection, connection startup, and traffic verification.

When reading logs, find the first error

Core logs often print several messages in succession after the same failure. The most useful clue is usually the first configuration, resolution, or connection error after startup. For example, a routing rule that references a nonexistent outbound tag can make every later connection fail; an unreachable DNS server may later appear as domain timeouts; and an inactive system proxy may leave no corresponding request in the client log at all. Do not focus only on the last line, and do not mistake routine connection-closed entries for the root cause.

Review issues in this order: did the client start the core; did the request enter a local inbound; did the domain resolve; did routing match the expected rule; and did the target outbound establish a connection? If the core did not start, check configuration generation and port conflicts. If the request never reached the local inbound, check the system proxy, the browser's independent proxy, or TUN status. If domains fail while direct IP access works, focus on DNS. If only some sites take the wrong path, review rule order and domain sets.

Parameter sources and precedence

Subscriptions provide server connection parameters, the client stores local overrides, routing and DNS plans determine runtime behavior, and the system network determines the traffic entry point. A subscription update may rebuild server entries, so long-term rules should not live only in a server remark. Persistent groups, filters, and routing policies belong in the client's subscription settings, routing plan, or a separate configuration. If you must edit the raw configuration, first confirm that the client will not overwrite it at the next startup.

By the end of this chapter, you should be able to tell whether a problem belongs to data management, core execution, or system interception. That decision determines the next tool: handle subscriptions when server entries are disorganized; handle routing when traffic takes the wrong path; handle DNS when domains behave abnormally; and consider TUN only when applications that ignore the system proxy need to be brought into the client. Separating the layers is the foundation for configurations that remain reproducible throughout the rest of the guide.

CHAPTER 02 / GROUPS

Subscription groups and server filtering

Even a single subscription can contain a large number of entries. Flattening every server into one list makes selection, updates, and troubleshooting increasingly difficult. The goal of grouping is not a complicated hierarchy, but a clear separation between where data comes from, what each entry is for, and what should be temporarily hidden. v2rayN is well suited to organizing multiple subscriptions on the desktop; on mobile, v2rayNG and v2flyNG users should keep fewer, clearly named groups to reduce switching overhead.

Group by source first, then filter by purpose

The subscription source is the most stable top-level boundary. Give each source a clear name, such as “Daily Lines,” “Test Lines,” or “Backup Lines,” rather than cramming region, protocol, multiplier, and purpose into one group name. Source-based grouping makes it easier to see which data set an update failure affects and to disable a failed source independently. Use remarks and filters for purpose—for example, keep entries containing “Office” or “Low Multiplier,” and hide notification-style entries containing “Expired,” “Remaining,” or “Official Site.”

Filtering generally works in two directions: include and exclude. Include rules suit a clearly defined small set, such as showing only servers whose remarks contain “Japan” or “Singapore.” Exclude rules are useful for removing notices and protocols you do not currently use. When combining both, understand the client's processing order: it generally retrieves the full subscription first and then applies the filters. Filtering changes the client list or import result, not the remote subscription itself.

Safe patterns for regex filtering

When ordinary keywords are not enough, use regular expressions. A vertical bar can represent “any one of” several regions, and notification terms can be combined into one exclusion pattern. Keep expressions short and test them on a small number of entries first. Complex lookaheads and backtracking conditions are harder to maintain and may behave differently across clients because regex support varies.

Include example:
Japan|Tokyo|Singapore|United States

Exclude example:
Expired|Remaining|Announcement|Website|Traffic

Exact match for common region prefixes:
^(Japan|Singapore|United States)[-_ ]

Chinese names, English abbreviations, and flag symbols may all appear in remarks. If subscription naming is inconsistent, inspect the complete list before choosing keywords instead of copying a long expression from the internet. When filtering suddenly produces zero entries, clear the conditions first to confirm that the original subscription is healthy, then restore the expression section by section. If only some names fail to match, check full-width spaces, hyphens, and capitalization differences.

Speed-test results do not prove usability

Server filtering is often paired with speed tests, but a latency test only shows whether one probe reached its target. It does not fully represent the actual protocol connection, access to the destination site, or sustained transfer performance. A reachable TCP probe does not prove that authentication parameters are correct, and a low one-time latency does not guarantee stability during peak hours. First remove clearly unreachable entries, then verify candidates through real-world access; do not sort permanently by a single number.

A more reliable workflow is: update one subscription and confirm its entry count and remark structure; apply exclusion rules to remove notices; select a small number of candidate servers for connectivity tests; start one and visit a commonly used destination; then save an order suited to the current network. Test again when network conditions change instead of treating old results as permanent properties. For more on misleading node speed tests and how to interpret them, continue with the troubleshooting articles in the site index.

Check what changed after an update

After a subscription update, check at least three things: whether the source name still maps to the original group; whether server remarks changed and invalidated the filter; and whether the active server was replaced or removed. If the provider changes its naming format, old keywords may exclude every new entry. Disable the filter first to view the raw result, then update the expression. If one source fails to update, do not immediately overwrite every subscription. Check that source separately, try updating through an existing working connection if necessary, and confirm that the response is subscription data rather than an ordinary webpage and remains in a format the client can recognize.

A successful grouping is not one that merely looks tidy. It should answer three questions: which subscription the current server came from, why it appears in the filtered result, and which source to operate when an update fails. Once these are clear, multi-subscription management and routing bindings have a stable foundation.

CHAPTER 03 / MULTI-SUBSCRIPTION

Multi-subscription management and update strategy

When multiple subscriptions coexist, the main risks are not entry counts but overlap, duplicate names, and conflicting update schedules. A sound structure lets each source update, be disabled, and be troubleshot independently without copying subscription URLs into unnecessary places. On the desktop, v2rayN is typically the central management point. On Android, import only the sources needed on the go to avoid processing large numbers of duplicate servers on every update.

Give every source its own identity

When adding a subscription, use a name that describes its purpose without exposing the full URL, such as “Primary Desktop,” “Mobile Backup,” or “Protocol Test.” If two sources may contain identically named servers, add a short prefix to the subscription name and retain the source identifier provided by the client. Server remarks may change; the subscription identity should not. Avoid names such as “Subscription 1” and “Subscription 2,” which provide no memorable source, and do not use the current date as a long-term name.

Do not add the same URL to multiple groups. Duplicate sources create similar entries after updates, making ownership unclear. When duplicates are found, compare the subscription URL and update time, then keep one management record. If the client supports removing servers by subscription, use the source-level operation rather than deleting entries one by one from the master list, since the next update may import them again.

Set update order and isolate failures

A reliable approach is to update the primary source currently in use first, confirm that it connects, and then update backup sources one at a time. Parallel updates reduce clicks, but make failures harder to locate when one source returns malformed content. Do not set automatic updates too frequently. Subscription content is generally not a real-time status feed, and repeated requests will not make the lines themselves more stable. Choose a schedule that covers normal changes and keep a manual update option for recovery.

An update failure usually falls into one of four categories: the URL is invalid; the current network cannot access it directly; the server rejects the request based on its characteristics; or the response format is incompatible with the client. First update that source alone in the client and read the prompt. Next, try updating through an existing working connection. Then check for extra spaces, line breaks, or truncation in the copied URL. Finally, verify that the response is subscription data rather than a normal webpage. For a fuller decision tree, see Subscription Update Failures: Troubleshooting and Automatic Update Setup.

The boundary between merging, conversion, and local rules

Subscription conversion is useful for handling client format differences, filter fields, and merged output, but the longer the conversion chain, the harder problems are to locate. If v2rayN, v2rayNG, or v2flyNG can recognize the original source directly, import it without conversion. When conversion is necessary, determine whether it only changes the wrapper format or also rewrites protocol parameters, server names, and routing rules. Any step that changes connection parameters can make an otherwise working source fail after conversion.

Do not make long-term local routing rules depend on temporary remarks in a remote subscription. Remarks can filter servers, but they are not suitable as domain-routing conditions. Write routing rules around target domains, IPs, ports, processes, or inbound tags, separately from the server list source. This keeps access policy consistent when subscriptions change. Associate a routing rule with a stable outbound tag only when a class of targets must always use a particular server.

Choosing what to sync between mobile and desktop

There is no need to make server lists identical across devices. A desktop may need multiple outbounds, complex routing, and TUN interception, while a mobile device is better served by a smaller set of sources and simple per-app rules. Sync subscription source names and core filtering principles if useful, but save system-specific settings separately. In particular, do not copy a complete desktop configuration containing local listening ports, process rules, and desktop DNS addresses directly to a mobile device.

Order for removing old sources

When disabling a source, first turn off automatic updates, then switch to another verified server, remove the servers from that source, and finally delete the subscription record. Deleting the active source immediately may leave the client showing an old connection state while preventing recovery at the next startup. After cleanup, check the active server, default outbound, and routing tags to ensure no rule still references a deleted object.

Once multi-subscription management is stable, every source should have a clear purpose and update method; failure of one source should not block the others; routing and DNS should not depend on temporary server remarks; and desktop and mobile should share only necessary data. This structure is easier to maintain than simply merging everything into one extremely long subscription, and it provides a better foundation for adding custom outbounds.

CHAPTER 04 / ROUTING

Practical routing rules: match conditions, order, and outbounds

Routing sends connections that have already entered the core to a designated outbound based on the destination domain, destination IP, port, network type, process, or inbound tag. It does not automatically bring application traffic into the client and cannot repair server connection parameters. The system proxy or TUN provides the entry point; routing only chooses the direction afterward. Understanding this boundary prevents mistaking “the application never reached the client” for “the routing rule did not match.”

Start with three outbound types

A common basic structure includes a proxy outbound, a direct outbound, and a block outbound. The proxy outbound points to the selected server or a custom proxy chain; the direct outbound reaches the target through the local network; and the block outbound rejects connections that are explicitly unwanted. Give each outbound a stable, meaningful tag such as proxy, direct, or block. Routing rules reference outbounds by tag, so renaming a tag requires updating every reference.

Rule order generally works best from specific to general. Put explicit block rules, private-network direct rules, specified domains, or specified processes first; broader domain and IP sets next; and the default outbound last to catch unmatched traffic. If a broad rule comes first, later precise rules never run. For example, matching all TCP traffic to the proxy before adding a direct rule for one domain may make that direct rule ineffective.

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["domain:example.cn", "geosite:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["domain:example.net"],
        "outboundTag": "proxy"
      }
    ]
  }
}

The example first sends private addresses directly, then handles specified domains and domain sets. domain: matches the domain and its subdomains, full: is better for matching only the complete hostname, and keyword: matches domains containing a specified fragment, giving it the broadest scope and highest risk of false matches. Rule semantics vary with the core configuration format. Client-generated plans are generally easier to maintain day to day; when editing JSON directly, confirm that each field belongs to a configuration structure supported by the current core.

How domain and IP matching work together

When routing receives a domain, domain rules can match it directly. When a rule requires an IP set, the core may need to resolve the domain first. domainStrategy determines when that step occurs. If routing uses domain rules only, extra resolution may be avoided. If you need to check the IP after domain rules fail, use the corresponding on-demand resolution strategy. Resolving every domain unconditionally increases DNS requests and may cause routing to use a result different from what the application expects.

GeoSite is a domain collection, while GeoIP is an IP address collection. Both depend on local data files, so correct rule syntax cannot compensate for outdated data: new domains may be missing and address classifications may change. Restart the core after an update so the runtime configuration reloads the data. For update instructions and misrouting diagnosis, see How to Update the GeoIP and GeoSite Databases.

Intranet, LAN, and private addresses

Home routers, printers, file shares, and local development services typically use private addresses and should go direct. Otherwise, local-device traffic may be sent to a remote outbound and fail. In addition to private IP sets, watch for localhost, .local names, and internal corporate domains. Internal domains often resolve only through LAN DNS, so assign them a local resolver in DNS routing and send their traffic direct.

Under TUN, the client intercepts a broader range of traffic, making direct rules for private networks especially important. If the router admin page becomes unreachable after enabling TUN, first check that private addresses bypass the proxy and that the virtual-adapter route has not overridden the LAN subnet, then check the system firewall. Do not disable all routing rules to restore one local address; adding a precise direct target is easier to verify.

Step-by-step checks for ineffective rules

First confirm that the request really entered the core, then check the logs to see whether the target is a domain or an IP. If only an IP appears, a pure domain rule may not match. If the target domain already matched an earlier broad rule, adjust the order. If GeoSite or GeoIP is referenced, check that the data file loaded. If the rule points to a custom outbound, verify that the tag matches exactly. If the client offers modes such as “Bypass LAN,” “Global,” or “Rule,” make sure the current mode is not overriding the custom plan.

For verification, choose one target and test three observable outcomes separately: direct, proxy, and block. Do not judge from several sites at once, because a page may load its main resource, images, and APIs from different domains, making one request look like several paths. Browser caches and persistent connections also affect results. After changing rules, restart the core and establish a new connection. Stable routing means that the rule intent, match order, and outbound tag can be explained one by one—not that one refresh happened to work.

CHAPTER 05 / DNS

DNS optimization: query paths, split resolution, and leak checks

DNS converts domain names into addresses and can also determine whether routing matches domains or IPs correctly. The most common advanced-configuration confusion is having system DNS, an application's built-in DNS, client DNS, and remote outbound resolution all active without a clear assignment for each domain. The goal is not to stack more servers, but to establish an explainable query path: where the request enters, which server resolves it, which outbound carries the query, and which routing rule receives the result.

Separate system queries from core queries

In ordinary system-proxy mode, some applications resolve domains on the system first and pass only the IP to the proxy; applications that support proxy protocols may pass the domain to the client. TUN can intercept more DNS traffic, but applications may still use encrypted DNS or their own resolver. If logs show only the destination IP, the domain information may have been lost before entering the core, limiting domain-based routing.

The core's DNS servers can use traditional IP addresses or service addresses with encrypted transport, depending on the core and how the client generates its configuration. Consider reachability and outbound path together. If a resolver itself must be reached through the proxy while routing depends on its result, a circular dependency can form. The basic resolver should be clearly reachable on the current network before assigning other servers to specific domains.

{
  "dns": {
    "queryStrategy": "UseIP",
    "servers": [
      {
        "address": "223.5.5.5",
        "domains": ["geosite:cn"],
        "expectIPs": ["geoip:cn"]
      },
      {
        "address": "https://1.1.1.1/dns-query",
        "domains": ["geosite:geolocation-!cn"]
      },
      "localhost"
    ]
  }
}

This example illustrates choosing resolvers by domain; it is not a template for every network. domains limits the domain set handled by that server, expectIPs can check whether returned addresses fall within the expected range, and queryStrategy controls the preferred address type. If the current network cannot reach a resolver, replace it with an accessible service instead of adding more timeout retries.

Keep DNS routing aligned with traffic routing

When a domain is intended to go direct, it should usually use a resolution path suited to the local network. When it is intended for a proxied outbound, the query can use the same outbound to avoid a large mismatch between where the name is resolved and where it is accessed. The two rule sets need not duplicate every entry, but their overall direction should agree. If routing sends a domain direct while DNS forces the query through a remote outbound, the connection may still work, but latency and troubleshooting complexity increase.

Internal domains require especially explicit split resolution. Corporate or home-LAN names are usually answered only by local DNS, so assign the relevant suffixes to a local resolver and route the corresponding addresses directly. If public DNS returns NXDOMAIN, the client will not automatically retry an internal server. Conversely, do not send every public domain to a resolver that works only on the LAN, or everything will fail when you leave that network.

Cache, TTL, and old connections after switching

DNS results may be cached separately by the application, system, client, and core. Refreshing a page immediately after changing DNS settings may not trigger a new query, and established connections do not migrate automatically when DNS changes. For verification, close old connections, restart the core, and clear the system DNS cache when necessary. Do not set an extremely short cache time in pursuit of “real-time” results; it increases query volume and cannot fix incorrect responses from the server itself.

For services whose server addresses change frequently, respect a reasonable TTL and implement failure retries. Fixed internal services can use moderate caching. If the same domain returns different addresses on different networks, pay close attention to stale cache after switching networks. When a mobile device moves from Wi-Fi to cellular data, restarting the connection is usually more controllable than waiting for every cache to expire naturally.

How to identify and fix DNS leaks

A DNS leak occurs when a query that should follow a designated path is sent by the system or another application to an unplanned resolver. Diagnosis should not rely only on the DNS addresses displayed by a webpage; consider the current network, proxy mode, and expected path together. System-proxy mode cannot inherently intercept DNS for every application. TUN covers more traffic but still requires correct DNS interception. A browser's independent encrypted DNS can also bypass system and client settings.

Fix leaks by defining the expected path first, then removing bypasses: disable or adjust the application's own resolver; route system DNS requests into the client; assign an explicit outbound to the core's DNS; check that routing does not send queries the wrong way; and test again. If the issue appears in only one application, inspect that application's settings before changing the entire system. For complete instructions, read Hands-on DNS Leak Detection and Repair.

A completed DNS setup should explain who resolves each class of domain, which outbound carries each query, and how the result participates in routing, with the corresponding process visible in logs. More servers do not necessarily improve results; a short, clear query chain is usually more stable than a collection of random fallback addresses.

CHAPTER 06 / TUN

TUN mode: system traffic interception and boundary control

TUN mode receives system traffic through a virtual network interface. It is useful for applications that ignore the system proxy, cannot configure a proxy independently, or generate UDP requests. TUN solves coverage at the traffic entry point; it does not select the right server automatically and does not replace routing or DNS. After enabling it, the client must configure a virtual adapter, system routes, and DNS interception, so failures can expand from one application to the entire system network. Enable it only after ordinary proxy mode is stable.

Pre-enable checks

First confirm that v2rayN or the Android client works with the current server in ordinary mode, and save the existing configuration. Desktop systems need the permissions required to create a virtual adapter and modify routes; security software or enterprise policies may restrict these operations. Record the local LAN subnet, any VPN software, virtual-machine networks, and container networks, because multiple virtual interfaces may compete for the default route.

Before starting TUN, disable other connection tools that modify system routes to avoid simultaneous interception. If they must coexist, define each interface's route priority and target subnets instead of relying on startup order. If the client exits unexpectedly and the network stops working, terminate related processes and restore system networking first, then inspect leftover virtual interfaces and DNS rather than repeatedly restarting the browser.

Stack mode and MTU

Different clients and cores may offer network stack options such as system, gVisor, or mixed. The system stack follows operating-system networking more closely, with compatibility and performance depending on the platform. A user-space stack handles packets inside the client and may be more stable in some environments, but can differ with certain protocols or applications. When there is no specific fault, use the client-recommended value; switch for comparison only when UDP, LAN, or a particular application behaves abnormally.

MTU sets the maximum size of an individual packet. An overly large value may cause fragmentation or packet loss on complex paths, appearing as pages that open while uploads, video, or certain APIs stall. An overly small value adds overhead. Do not lower MTU at the first sign of a slow connection. Confirm that the issue occurs only under TUN, then compare gradual adjustments, rebuilding the connection after each change. Use the default value as a control.

Bypass for LAN and reserved addresses

After TUN begins intercepting traffic, explicitly bypass private addresses, loopback addresses, and the subnets that must connect directly on the current LAN. Printers, network storage, router admin pages, and local development services all depend on this. If a simple “bypass LAN” switch is not enough, inspect the actual address ranges and add precise IP or subnet rules. Enterprise networks may also use nonstandard internal ranges, which should be handled according to the real routing table.

If local devices are accessed by hostname, configure internal DNS as well. Sending the target IP direct while passing the hostname to a public resolver can still produce a nonexistent or incorrect address. Test LAN issues in two stages: can the name resolve, and can the address connect directly? Test the IP first, then the hostname, to determine whether the problem is DNS or routing.

Per-app control and UDP

Mobile clients commonly use per-app proxying to control which applications enter the connection. Include mode suits letting a small number of apps in; exclude mode suits letting most apps in while keeping local services direct. App updates or package-name changes can invalidate old selections, so review the list periodically. Desktop process routing depends on the core and permissions; the same process name may refer to different paths, so verify rules against actual logs.

UDP traffic includes some DNS, real-time communications, and newer transport protocols. If the server and protocol chain do not support the required UDP behavior, TUN can receive packets without making the destination reachable. First determine whether all UDP fails or only one application or destination, then check outbound capability, routing, and MTU. Do not attribute every UDP failure to the virtual adapter.

Restoring the network after shutdown

When the client exits normally, automatic routing and DNS settings should be restored. If the network remains unavailable after an abnormal exit, first check whether the TUN interface still exists, then inspect the default route and system DNS for temporary values. Reopening the client and performing one normal start followed by a normal stop may trigger cleanup. If recovery still fails, use the system network reset function and reconnect to the current network.

A stable TUN setup does not mean “intercept all traffic.” It means the interception scope is intentional, LAN boundaries are clear, DNS does not bypass the client, and the system recovers after shutdown. For browsers and applications that support the system proxy, ordinary proxy mode is simpler. Use TUN only when broader entry-point coverage is genuinely required.

CHAPTER 07 / FAKEDNS

FakeDNS: virtual IP mapping, use cases, and compatibility

FakeDNS does not return a domain's real address directly to the application. Instead, it assigns a virtual IP from a reserved pool and stores an internal “virtual IP–original domain” mapping. When the application connects to that virtual address, the core restores the domain from the mapping and then applies domain routing and real resolution. Its main value in TUN scenarios is preserving domain information when an application would otherwise receive a real IP first and leave the core able to route only by address.

How the mapping works

After an application sends a DNS query, TUN or DNS interception rules forward it to the core. FakeDNS assigns and returns a virtual address. The application uses that address to establish a connection; the core recognizes that it belongs to the FakeDNS pool, retrieves the domain from the mapping table, selects an outbound using domain rules, and resolves the real address through the target outbound when necessary. This requires both the DNS query and the subsequent connection to pass through the same core instance that can recognize the mapping.

If the DNS query enters FakeDNS but the application connection bypasses TUN, the system will try to reach a virtual address that does not exist on the public internet. Conversely, if the connection enters TUN while the application's own resolver handles DNS directly, the core may see only the real IP and FakeDNS will not participate. Before enabling it, ensure that DNS interception and traffic interception form a complete loop.

{
  "dns": {
    "servers": [
      {
        "address": "fakedns",
        "domains": ["geosite:geolocation-!cn"]
      },
      "223.5.5.5"
    ],
    "fakedns": [
      {
        "ipPool": "198.18.0.0/15",
        "poolSize": 65535
      }
    ]
  }
}

The example uses a reserved address range intended for benchmark testing as the virtual pool and enables FakeDNS only for selected domain sets. Exact fields and placement depend on the core configuration format and how the client generates it, so prefer the client's built-in switch and template. The pool must not overlap with the local LAN, enterprise networks, other virtual interfaces, or existing routes. A larger pool is not automatically better; it only needs to cover active mappings during normal use.

When FakeDNS is a good fit

When TUN is stable, domain rules are extensive, and applications commonly resolve domains locally first, FakeDNS helps the core preserve domain semantics. It also suits cases where real resolution should happen later: routing first selects an outbound by domain, and the chosen path performs the actual resolution. This prevents a local resolution result from determining the destination address too early.

If most use involves a system proxy that supports remote resolution and logs already show complete domains, FakeDNS usually offers limited benefit. Simple networks do not need it merely to add more parameters. FakeDNS solves lost domain information; it is not a general speed switch and cannot improve the server's underlying connection quality.

When not to enable it directly

Applications that require real IP display, address allowlists, LAN discovery, or direct DNS-result comparison may not accept virtual addresses. Some security software treats connections to reserved ranges as abnormal, while certain games, device-control tools, and enterprise clients may bypass system DNS and break the mapping chain. Internal domains should generally continue using LAN DNS and connect to real addresses instead of entering FakeDNS.

Be cautious with targets that require precise IP-rule control. If routing treats the virtual IP as an ordinary address before the domain is restored, it may match the wrong rule. Ensure that FakeDNS addresses are recognized at the correct stage, and avoid ordinary direct rules for the virtual pool. For the mechanism, use cases, boundaries, and application compatibility, read How FakeDNS Works.

Cache and mapping loss

An application may cache a virtual IP while the core clears its mapping table on restart. The application then continues connecting to the old virtual address, which the core can no longer map back to a domain. This can make some sites fail briefly after the client restarts. Closing old connections, clearing the application's DNS cache, or restarting the application usually restores access. Frequent core restarts make this more likely, so start a complete new query after every change during debugging.

If the address pool is exhausted or the mapping count grows abnormally, check whether a program is continuously generating random-subdomain queries. Expanding the pool blindly only delays the problem. Identify the source first; if necessary, bypass FakeDNS for that domain type or narrow the application's interception scope. After enabling it, verify ordinary domains, internal domains, IP-only destinations, and cache recovery after a restart separately. FakeDNS is stable only when all four behaviors are explainable.

CHAPTER 08 / OUTBOUNDS

Custom outbounds, proxy chains, and a complete troubleshooting workflow

Custom outbounds send different targets through different connection paths, adding DNS-specific, upstream-proxy, or dedicated-server outbounds alongside direct, proxy, and block paths. They bring the subscription, routing, and DNS layers together: server parameters determine whether an outbound can connect, routing tags determine which requests enter it, and the DNS path determines how targets resolve. The more custom outbounds you add, the more important it is to document tags and dependencies clearly.

Tags are the interface between configurations

Every outbound should have a unique, stable tag that expresses its purpose only. Do not put the server address, region, and date into a tag, because those details can change after a subscription update. Names such as proxy-main, proxy-backup, direct, block, and dns-out work well. Routing rules, DNS servers, and proxy chains reference tags; display names can be more descriptive.

Before deleting or renaming an outbound, search every location that references it. A configuration can parse successfully without every reference being valid; some errors appear only when the relevant rule is first matched. The safest method is to add and test the new outbound separately, switch one precise domain rule to it, expand the scope after verification, and delete the old outbound last.

{
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    },
    {
      "tag": "dns-out",
      "protocol": "dns",
      "settings": {
        "address": "1.1.1.1",
        "port": 53,
        "network": "tcp"
      }
    }
  ]
}

The example shows the basic tag relationships for direct, block, and DNS outbounds. Proxy-server outbounds are usually generated by the subscription and client, so avoid pasting authentication parameters into multiple local configurations. If the client supports using the current server as the default proxy outbound, keep that dynamic reference so switching servers does not require rewriting routes. Create a dedicated outbound only when a specific line must remain fixed.

Proxy-chain direction and dependencies

A proxy chain means that one outbound establishes its connection through another outbound. For example, target traffic enters a service outbound, which then uses an upstream outbound as its transport path. Configuration must make clear who connects through whom; reversing the direction causes failures. Every layer adds connection setup steps and expands the troubleshooting scope, so use a chain only when an upstream path is genuinely needed.

The most common proxy-chain failure is a circular dependency: outbound A uses B while B uses A, or resolving the server address for A requires A itself. The chain should ultimately terminate at an exit that can establish a connection directly, using a directly resolvable or otherwise fixed reachable server address whenever possible. Test the basic outer outbound first, then add each upper layer in sequence instead of enabling the entire chain at once.

Choose outbounds by inbound, port, and process

In addition to domains and IPs, routing can use inbound tags, destination ports, network types, or processes. Inbound tags are useful for binding different local listening ports to different outbounds—for example, one port for the primary line and another for backup testing. Port rules suit clearly defined protocol services, but modern applications often carry multiple types of traffic on one port, so port alone is not enough. Process rules suit per-application desktop control; actual support and permissions depend on the core and operating system.

Avoid overlapping scopes when combining rules. If a process rule and a domain rule both match, their order determines the result. Put the most explicit inbound or process rules first, target-domain rules next, and general sets last. Record each rule's purpose beside it; this is easier to maintain than relying on elaborate names. If the client supports remarks, state the match condition and target outbound.

A repeatable troubleshooting workflow

First restore the minimum configuration: one verified server, one proxy outbound, and one direct outbound, with complex routing, TUN, and FakeDNS disabled. After confirming the basic connection, load DNS settings and verify domain resolution. Then add one precise routing rule and observe its match. Next enable TUN and verify system traffic and LAN access. Add FakeDNS or a proxy chain only at the end. Keep the logs and results from every step.

If the problem starts only after a subscription update, compare the active server and protocol parameters before changing routing. If only certain domain types fail, inspect DNS split routing and GeoSite data. If only applications that ignore the system proxy fail, inspect the TUN entry point. If enabling FakeDNS causes widespread failures, restore real DNS and inspect the mapping loop. If a custom outbound fails, test it with one precise rule first rather than switching all traffic to it.

Log the operation time, changed items, current mode, and first error. There is no need to retain large volumes of repeated connection-closed messages. When comparing two configurations, compare only what actually changed; changing DNS, routing, and outbounds simultaneously makes the differences meaningless. When terminology or interface behavior is unclear, start with the configuration and troubleshooting articles. If you need to reinstall the client, visit the download page and choose the appropriate Windows, macOS, Android, or Linux version.

Minimal long-term maintenance checklist

Regular maintenance does not require rebuilding the configuration every day. At the subscription layer, check that sources remain valid and filters are not excluding real entries. At the routing layer, check GeoIP and GeoSite data and tag references. At the DNS layer, check resolver reachability and application bypasses. At the TUN layer, check the virtual interface, LAN bypass, and shutdown recovery. At the FakeDNS layer, check address-pool conflicts and application compatibility. At the outbound layer, check whether the chain is still necessary. When switching cores, also confirm that configuration fields and protocol features remain compatible. For differences between Xray and V2Fly, read Xray Core vs. V2Fly Core: Key Differences.

A maintainable advanced configuration should explain each component's role in a few words: subscriptions provide servers, groups organize sources, filters reduce noise, DNS supplies addresses, routing chooses direction, TUN broadens the entry point, FakeDNS preserves domains, and custom outbounds establish target paths. Any rule whose purpose cannot be explained, verified independently, or removed without consequence deserves another review. The closer the configuration stays to this clear structure, the less likely it is to become unmanageable when updating the client, switching servers, or moving to another device.