Advanced V2Ray Configuration
Reference Guide

Configuration layers and change order

The most common advanced-configuration problem is not a mistyped parameter, but mixing responsibilities from different layers. Server filtering only determines which entries are easier to select in the client; it does not decide whether browser traffic uses the proxy. Routing rules assign connections that have already entered the core to different outbounds, but cannot capture applications that ignore the system proxy. TUN expands the capture scope, but does not automatically fix an incorrect DNS server or an unusable node. Splitting the configuration into six layers—input, selection, capture, resolution, decision, and outbound—can greatly shorten the troubleshooting path.

The complete path from input to outbound

The input layer includes subscription URLs, individual share links, and manual configuration. After updating a subscription, the client converts the remote content into local server entries. The selection layer handles the active server, server groups, and filter results. The capture layer determines which application traffic enters the core: the system proxy generally covers programs that honor system proxy settings, while TUN receives a broader range of IP traffic through a virtual network interface. The resolution layer turns domain names into addresses; the routing layer matches conditions such as domains, addresses, ports, and protocols. Finally, the connection is completed through a proxy, direct, blocked, or custom outbound.

This path has a clear order. If the browser has not entered the system proxy, changing routing rules will not change the result. If DNS was resolved earlier by the operating system, domain-only rules may not match as expected. If routing selects a proxy outbound but the active server is unavailable, the connection still fails. Every change should answer two questions: which layer changed, and what observation will prove that it took effect? Matching each validation point to its layer prevents the real cause from being obscured by changing several options at once.

Establish a recoverable configuration baseline

Before making advanced changes, keep a baseline that connects reliably. It does not need to be complex: retain one verified server, default routing, explicit DNS settings, and the current system proxy or TUN state. Then change one topic at a time—for example, finish subscription grouping and confirm server selection before moving on to routing. If the client supports backups or exports, save snapshots at key stages. You can also record interface options, rule order, and test results instead of relying on memory to restore the setup.

When validating the baseline, do not test just one webpage. Include at least one domain expected to connect directly, one expected to use the proxy, one pure IP connection, and one DNS query. The results should distinguish traffic that never entered the client, incorrect routing after entry, abnormal DNS responses, and an unavailable selected server. On Windows, use Task Manager, system proxy settings, and client logs together; on macOS and Linux, check the current routes, proxy settings, and resolution state. On Android, v2rayNG and v2flyNG rely mainly on connection logs, virtual-network authorization, and the target application's behavior.

Client labels may vary slightly by version and platform, but the core relationships remain the same. v2rayN is the preferred desktop management client for maintaining subscriptions, routing, and outbounds in one place. On Android, v2rayNG uses the Xray core ecosystem, while v2flyNG primarily uses the V2Fly core. When moving between platforms, migrate the configuration intent rather than assuming menus and every field are identical. Confirm that the target platform supports the required capability, then rebuild the configuration layer by layer; this is usually easier than copying a large configuration and discovering compatibility limits later.

Subscription groups and server filtering

Once a subscription list grows, efficiency depends less on its length than on reliably finding servers suited to the current task. Groups provide long-term ownership for servers; filters narrow the candidates for a particular selection. Design them separately: groups express source, purpose, or maintenance boundaries, while filters express name-matching conditions. Treating filter results as permanent categories can break when a subscription renames entries; putting everything in one group makes updates, latency tests, and fault isolation interfere with one another.

Group by source or by purpose?

Source-based groups are easiest to maintain: assign each subscription URL its own group, so an update failure can be traced directly and one subscription can be withdrawn without affecting the others. Purpose-based groups work better when naming is already consistent—for example, separating everyday browsing, development testing, and temporary backups. In practice, a two-level approach works well: preserve source boundaries underneath, then create purpose views through filters or favorites. This keeps origins traceable while reducing noise during everyday selection.

Group names should be stable, short, and recognizable. Do not put update dates or temporary states into names meant to last. Dates belong in logs, while line quality should be judged through actual connection tests. If several subscriptions contain identically named servers, add a source prefix during import or let the group distinguish the source instead of piling on labels in the server name. The more complex the name, the easier it is for regex filters to match incorrectly, and the harder it becomes to accommodate naming changes later.

Build maintainable filter expressions

Server filters usually perform text or regex matching against remark names. Start with the smallest condition—for example, one stable keyword—then add alternative spellings gradually. Positive filters are useful for selecting a region, purpose, or route marker from a large list; negative filters are useful for excluding test entries, expired markers, or unsupported architectures. Filter expressions should not depend on fragile positions such as “the third character”; use relatively stable complete terms and separators instead.

Common filtering patterns:

Contains any keyword:
(Office|Development|Backup)

Match source markers at the beginning of a name:
^(Source A|Source B)[-_ ]

Exclude entries marked temporary or expired:
^(?!.*(Temporary|Expired)).*$

Require both conditions:
^(?=.*Development)(?=.*TCP).*$

Parentheses in a regex create groups, a vertical bar separates alternatives, a dot-and-star combination matches text of any length, and lookaheads can require or exclude a condition. Before entering an expression, confirm that the client's input field has regex mode enabled; in a plain-text search, special characters are treated literally. After filtering, manually inspect the beginning, end, and boundary names in the list to ensure homophones, abbreviations, or nested terms were not included by mistake.

Do not use filter results as a substitute for judging connection quality. Names only reflect labels supplied by the subscription publisher; they do not prove current availability or represent the current network path. After filtering, run real connection tests against the candidate set instead of checking basic reachability alone. The test should access an actual target and observe the handshake. If every test fails, remove the filter first and confirm that the original list works, distinguishing an expression with no matches from matched entries that cannot connect.

Keep the selection stable after updates

A subscription update may add, remove, or rename entries. If the selected server is deleted, the client may fall back to another entry or retain an old reference that no longer works. After updating, check that the current selection still belongs to the intended group and run another real connection test. For fixed-purpose configurations, do not rely on list positions: sorting changes can turn the former first item into a different server. A unique, stable naming scheme is safer, with manual confirmation of the active entry after updates.

If a filter suddenly returns an empty list, inspect the unfiltered source group first. If the source group is empty, the problem is the subscription update or parsing. If it contains entries but the filter is empty, the issue is a name change or expression. If the filter returns entries that cannot connect, the problem may be the node, network, DNS, or transport configuration. Separating these branches prevents an empty list from leading to unnecessary changes to routing or TUN. For the order of initial selection and real connection testing, also see the v2rayN first-connection steps.

Once the grouping rules are mature, write them down as a short maintenance convention: which prefix each source uses, which keywords are allowed for purpose filters, which temporary labels are excluded, and which checks must follow an update. This convention matters more than the expression itself because it lets new subscriptions fit the same structure. If only the creator understands the rules, the groups will quickly deteriorate into an unstructured list as names change.

Managing multiple subscriptions and update boundaries

The goal of managing multiple subscriptions is not to collect more URLs in one place, but to keep sources identifiable, disableable, and recoverable. Each subscription may have its own update schedule, naming style, and server fields. If every source is merged into one unmarked list, duplicate entries, mass failures, or naming conflicts make it difficult to tell which input should be fixed. A sound multi-subscription structure isolates sources first, then adds shared filtering and everyday convenience.

Give each source its own lifecycle

When adding a subscription, record its purpose, source identifier, and expected update method before running the first update. A successful update only means the client retrieved and parsed the content; also inspect the change in server count, key fields, and at least one real connection. If a source is temporarily unhealthy, disable it or pause automatic updates rather than deleting it immediately. Disabling preserves existing configuration and troubleshooting clues; remove it only after confirming it is no longer needed.

Do not optimize automatic updates solely for frequency. Overly frequent updates create unnecessary requests and may change the active list while work is in progress. For stable sources, schedule updates during a predictable, observable window; for temporary sources, manual updates may be better. If the client supports updating at startup, consider startup frequency and network conditions: updating after every wake-up can repeatedly change state, while never restarting can miss changes. The important point is knowing when updates occur and whether they are verified afterward, not applying one interval everywhere.

Handle duplicate entries and name conflicts

Different subscriptions may contain the same server, or merely use the same name for different parameters. Do not declare duplicates based on the remark alone. Compare key fields such as address, port, protocol, transport, security settings, and server identifiers. Two entries with the same name but different transport parameters may provide different access paths; two differently named entries with identical connection fields may simply be duplicate publications from different sources. Keeping duplicates adds selection noise, but merging them carelessly can lose source ownership.

The safer approach is to retain source groups and filter or favorite one primary entry in the everyday view. If the primary source fails to update, you can still inspect the same type of configuration from another source. If renaming is necessary, use the client's local remark feature rather than changing important fields inside the subscription. Whether a local name survives the next update depends on the client's merge strategy, so confirm that behavior first and avoid building essential categorization entirely on names that may be overwritten.

Layered diagnosis of update failures

When a subscription update fails, first distinguish retrieval failure from parsing failure. Retrieval failure usually appears as an inability to connect, an abnormal response status, or a timeout. Check that the URL is complete, the current network can reach it, and the system proxy is not creating a loop. Parsing failure means content was retrieved but does not match the client's expected format; the response may be an HTML notice, its encoding may have changed, or the selected subscription type may be wrong. Do not keep refreshing without checking the response type—repeated requests will not fix a format problem.

If a subscription URL is reachable only when the proxy is enabled, determine which outbound handles the update request. Some configurations send the client's own subscription updates through the current proxy. If the active server has failed, this creates a loop: a new update is needed to obtain working entries, but the update depends on the old entry. Temporarily select an available source, adjust the update proxy policy, or update from a network where direct access works. Restore the original policy afterward and record the reason so the same problem does not recur.

Differences between subscription formats also affect multi-source merging. Base64 lists, individual share links, and native JSON configurations carry different amounts of information, and conversion may lose global settings such as routing, DNS, or custom outbounds. Server subscriptions should primarily distribute server entries; global routing and DNS should be maintained in the local client configuration. Do not expect an individual share link to express an entire client policy. For format boundaries and field conversion, read V2Ray subscription format guide.

A mature multi-subscription setup should answer three questions: where a server came from, which use cases are affected when a source fails, and how to verify recovery. Periodically remove sources that have been disabled for a long time, but first export the required configuration and confirm that no routing rule or favorite depends on its name. When moving between devices, migrate sources and groups first, then purpose filters; restore routing and custom outbounds last, after the base entries are stable. This order clearly separates input problems from advanced policy problems.

Routing rules in practice and match order

Routing rules select an outbound for connections that have already entered the core. Common conditions include domains, destination IPs, ports, network types, protocols, and process information; common results are proxy, direct, blocked, or custom outbounds. Rule systems usually match in a defined order, and stop after a connection hits an executable rule. The key to routing is therefore not the number of rules, but whether conditions are distinct, the order is clear, and the default traffic has a defined destination.

Define the outcome before writing conditions

Before writing rules, list the intended outcomes. For example: local networks and local addresses go direct; defined work domains use a specific proxy; a particular update service goes direct; everything else uses the default proxy. Once the outcomes are clear, choose the most stable condition for each traffic class. Domain rules are readable but require the core to obtain domain information; IP rules suit targets with stable address ranges; port rules are broad and usually auxiliary; process rules vary by platform and should not be copied unchanged across devices.

Place broad conditions after specific ones. If the first rule sends all TCP and UDP traffic to the proxy, a later LAN-direct rule can never take effect. Conversely, an overly broad direct domain suffix may send a subdomain direct before a rule intended to proxy it can match. To investigate order, temporarily put the target domain first and assign it an easy-to-recognize outbound. Once the match is confirmed, restore the other rules gradually and watch which one overrides it.

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "full:docs.example.com",
          "domain:example.net"
        ],
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

In the example, full: means an exact domain match, domain: generally includes the domain and its subdomains, and geoip:private identifies private address ranges. The final network rule provides the default exit and must come after the specific rules. The example domains only illustrate the structure; replace them with the targets you need to control. If the client uses a graphical routing editor, enter the same conditions in the corresponding fields instead of pasting the entire JSON into a field that does not accept a full configuration.

Understand domain strategy and resolution timing

domainStrategy determines whether the core resolves an IP when domain rules do not match, then tries IP rules. AsIs tends to preserve the original domain for matching rather than resolving it specifically for routing; IPIfNonMatch resolves the name after a domain-rule miss and continues with IP matching. Some cores also provide more aggressive strategies. More aggressive resolution can improve IP-rule coverage, but it increases DNS queries and gives the resolution path a more direct effect on routing.

If an application resolves a domain itself and gives only the destination IP to the core, domain rules may never see the original name. TUN sniffing, FakeDNS, and application proxy methods all affect domain visibility. When a seemingly correct domain rule does not match, first check whether the log shows a domain or an IP as the target. Then decide whether to adjust the resolution strategy, enable suitable sniffing, or add an IP condition. Adding more domain suffixes blindly will not help if the core never received the domain.

Start with a minimal rule set and expand gradually

Start with three rule groups: direct private addresses, a small set of explicit targets routed as needed, and everything else sent to the default outbound. Once stable, add update services, development environments, or specific process rules. Every new group needs positive and negative tests: one target that should match and a similar target that should not. For example, after configuring domain:example.net, test the root domain, a subdomain, and another domain whose name merely contains a similar string.

For routing troubleshooting, first inspect the target, matched rule, and outbound label in the connection log. If the log shows only a connection failure with no rule information, temporarily raise the client log level and restore it after testing to avoid excessive long-term output. If the target matched the correct outbound but still fails, the problem is outside the routing layer—check the server, DNS, or transport. If the target never appears in the log, check the system proxy, TUN, or the application's own proxy settings.

The system proxy, global mode, and rule-based splitting control different dimensions. The system proxy determines whether certain applications hand requests to the client; routing mode determines which exit the core chooses after receiving a connection. For a refresher on their relationship, see How to choose a V2Ray system proxy mode. When rules behave differently across networks, also check whether DNS returned different addresses, since IP-range rules may select different outbounds as a result.

DNS configuration and optimization and resolution paths

The key to DNS configuration is not simply replacing a server address, but identifying who sends the query, which outbound it uses, and which layer consumes the result. The operating system, browser, client core, and remote server may all participate in resolution. If the same domain is resolved repeatedly at different layers, the addresses may differ and routing decisions may change. Before optimizing DNS, map the query path and define the boundary between local, core, and remote resolution.

Distinguish system DNS from core DNS

System DNS serves ordinary programs that the client does not capture and may also resolve names before an application enters the proxy. Core DNS serves routing, TUN, or connections made by the core itself. In system-proxy mode, an application that supports proxying by hostname may pass the name directly to the proxy core or resolve it locally first; behavior depends on the application and proxy type. In TUN mode, the client usually has more opportunity to intercept DNS traffic, but DNS hijacking, routing, and exclusions still need to be configured correctly.

During diagnosis, do not change only the operating system DNS and then watch a webpage. Check system queries and client logs separately. On Windows, use ipconfig /flushdns to clear the system cache, then run nslookup or a PowerShell query. On macOS, use scutil --dns to inspect resolver order; on Linux, use resolvectl status according to the system environment to check the current upstream. Clearing caches helps rule out stale results; it is not a long-term fix.

Windows:
ipconfig /flushdns
nslookup docs.example.com

macOS:
scutil --dns
dscacheutil -q host -a name docs.example.com

Linux:
resolvectl status
resolvectl query docs.example.com

Choose DNS servers by domain

Complex environments can use different DNS servers for different domains. Internal LAN names should go to the local resolver, public domains to a regular upstream, and selected targets through a proxy outbound. DNS splitting preserves internal name resolution while keeping external query paths aligned with routing intent. Put specific domain rules before the default server so the default does not match too early. A LAN resolver should also have an explicit address range, preventing it from being reached through the proxy by mistake.

{
  "dns": {
    "hosts": {
      "router.internal": "192.168.1.1"
    },
    "servers": [
      {
        "address": "192.168.1.1",
        "domains": [
          "domain:internal"
        ],
        "skipFallback": true
      },
      "1.1.1.1",
      "8.8.8.8"
    ],
    "queryStrategy": "UseIP"
  }
}

hosts is suitable for a small number of fixed mappings, not for maintaining a large, frequently changing domain set. A server with domains handles only its matching scope, while skipFallback controls whether failures can move to other candidates. queryStrategy sets the preferred address family and should reflect whether the current network has stable IPv4 or IPv6 connectivity. If the network cannot use the selected family but queries are forced to that type, the domain may resolve successfully while every connection times out.

Caching, fallback, and query loops

DNS caching reduces repeated queries but lets old results survive configuration changes. After changing DNS servers, domain rules, or FakeDNS, consider the operating system, browser, and core caches together. Restarting the proxy does not necessarily clear every layer. For testing, use a previously unseen subdomain or clear the relevant cache for the platform. If things work briefly after clearing and then fail again, check whether multiple resolvers are taking turns returning different results.

Fallback needs clear boundaries. Switching to a backup server after the default fails can improve availability, but if different servers serve different routing purposes, arbitrary fallback may send an internal domain to an unsuitable upstream or return an address inconsistent with routing. Internal domains should generally not fall back to public upstreams; ordinary public domains can use ordered candidates. To determine whether fallback occurred, inspect the actual query server in the log rather than looking only at the final address.

Query loops commonly occur when DNS requests are routed through the proxy while the proxy server's own domain requires the same proxy DNS to resolve. Create a bootstrap path for the server address: use a known IP, assign the server domain a directly reachable resolver, or send its DNS request through an outbound that does not depend on the current proxy. Keep a minimal direct-resolution path during changes, or the client may be unable to obtain the proxy server address at startup.

When connections slow down or some domains fail intermittently, DNS is only one possible cause. Check server status, network paths, proxy mode, and local resource usage as well; do not attribute every fluctuation to resolution. Follow the order in V2Ray slow-speed layered troubleshooting: identify the failing layer first, then decide whether DNS needs adjustment. A good configuration has an explainable, reproducible path, not the largest possible collection of upstream servers.

TUN mode: capture scope and exclusions

TUN mode receives system traffic through a virtual network interface. It suits applications that ignore the system proxy, use an independent network stack, or require broader UDP handling. It changes how traffic enters the client; it does not replace subscription selection, DNS, or routing configuration. After TUN is enabled, applications that previously never appeared in the logs may be processed by the core, making routing and DNS errors more visible. First ensure that ordinary proxy mode connects reliably, then expand the capture scope.

Choosing between the system proxy and TUN

For everyday browsing and desktop applications that honor system proxy settings, start with the system proxy; it is simpler and its scope is easier to control. Consider TUN when an application ignores the system proxy, specific UDP connections must be captured, or application differences need to be handled uniformly. Do not switch to TUN merely because one website fails. If the cause is an unavailable server or incorrect routing, changing the capture method only adds another variable. First check whether the target request already appears in the client log; if it does, the problem is usually not in the capture layer.

TUN creates a virtual interface and changes system routes, which may involve different permissions and networking components on Windows, macOS, and Linux. v2rayN provides platform-specific entry points, and permission prompts should be completed according to the operating system. On Android, v2rayNG and v2flyNG capture traffic through the system's virtual-network authorization, so their runtime logic and desktop configuration entry points differ. When comparing platforms, compare capture targets, DNS flow, and exclusions rather than copying device names or interface numbers.

Routing table, MTU, and network loops

After TUN is enabled, the client adds or adjusts system routes so target traffic enters the virtual interface. If the default route, physical adapter route, and virtual-interface priority conflict, connections may loop back, the LAN may become unreachable, or the client's own server traffic may enter TUN again. During troubleshooting, inspect the system routing table first and verify the paths for the proxy server address, LAN addresses, and DNS upstream. The proxy server connection must leave through the physical network interface and must not be captured again by the same TUN.

MTU is the maximum size of an individual network packet on an interface. A value that is too high can cause fragmentation or packet loss on some paths, appearing as small requests that work while large pages or file transfers stall. A value that is too low increases packet count and overhead. If handshakes succeed but sustained transfers fail, consider MTU as one diagnostic item, but do not change it without evidence. Compare different networks, targets, and protocols first, then make small adjustments and record the results.

Network loops can also come from an application's proxy and TUN being active at the same time. For example, a program may be manually configured with a local proxy port; its connection enters the local proxy, whose outbound is then captured by TUN, and incomplete exclusions cause it to enter again. Choose one entry path: either let the application use the local proxy and exclude the client process, or remove the application's manual proxy and let TUN capture it directly. The client core, update requests, and required local listening addresses often need explicit exclusions.

Exclude the LAN and critical processes

LAN printing, file sharing, router administration, and local development services should normally remain direct. The routing layer can send private addresses direct, while the TUN layer may provide bypass addresses or an application list. Keep the two layers consistent: if TUN excludes an address range before capture, the core will never see those connections; if the core sends captured traffic direct, the match can be observed in its logs. Choose based on whether this traffic needs to be logged and controlled.

Process exclusions can solve loops involving the client itself or applications that should clearly remain outside capture, but process names may vary with launchers, child processes, and platforms. Excluding only the main program may not cover network services it creates. A more stable approach is to define address and routing boundaries first, then use process exclusions as a supplement. After an application update changes capture behavior, inspect the process actually making the network connection instead of assuming the old name remains valid.

Troubleshoot TUN in this order: whether the interface was created, whether routes were added, whether DNS follows the expected path, whether the target matches a rule, and whether the outbound can connect. If everything recovers immediately after disabling TUN, focus on the virtual interface, routes, or DNS capture. If the problem remains, check for a leftover system proxy, a still-running client process, and whether the operating system routes were restored. If necessary, exit the client and reconnect the physical network to verify the baseline in a clean state.

FakeDNS: mapping principles and limits

FakeDNS works by returning a temporary address from a dedicated pool instead of immediately giving the application the real destination address after a domain query. The application then connects to that address; the core uses the mapping table to recover the original domain and performs domain routing and remote resolution. Even when an application makes only an IP connection, the core can retain the domain information. FakeDNS mainly addresses lost domain context and premature local resolution in TUN scenarios; it is not a universal switch for faster connections.

How a query and connection are completed

The application first asks DNS for service.example.com. FakeDNS returns a mapped address from the pool and records the relationship between that address and the original domain. When the application connects to the mapped address, TUN passes the traffic to the core, which looks up the mapping, restores the domain, and selects an outbound using domain rules. If the proxy protocol and server support remote resolution, the real DNS query can occur later in the chain. The mapping table has capacity and a lifetime, so an old address cannot preserve the same relationship indefinitely.

This process requires both the DNS query and the subsequent connection to enter the same core. If the browser's independent encrypted resolver bypasses the DNS path while the connection enters TUN, the core may see only the real IP and FakeDNS will not participate. Conversely, if DNS returns a mapped address but the connection bypasses TUN and goes directly to the physical network, that address will not receive a valid public response. Before enabling it, ensure that query and connection paths are consistent; otherwise, the domain may resolve to an address while every connection fails immediately.

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

198.18.0.0/15 is a reserved range commonly used for benchmarking and mapping, and should not overlap with actual LAN addresses. poolSize controls the number of mappings that can be allocated; exact support depends on the core and the configuration generated by the client. If the graphical client provides a FakeDNS option, configure it there so the required DNS, sniffing, and routing relationships are generated together. When inserting partial JSON manually, confirm that the final configuration has no duplicate or conflicting fields.

Address-pool conflicts and bypass connections

When choosing an address pool, check whether enterprise networks, virtual machines, containers, or other networking software already use the same range. A conflict can send mapped traffic to the wrong interface or make a real internal address look like a FakeDNS result. Before enabling it, inspect the routing table and confirm that no more-specific route already covers the range. If the conflict cannot be avoided, choose another supported reserved range and update the TUN routes and exclusions together.

Some applications cache DNS addresses for a long time and may continue using old mappings after a network change. After the client restarts, the mapping table may have changed while the application still holds an old address, causing only that application to fail. Restart the target application or clear its DNS cache as well. Frequently toggling FakeDNS makes cache state difficult to interpret, so keep the configuration fixed during testing and complete a query, connection, and restart cycle before deciding whether to retain it.

LAN domains, printer discovery, device broadcasts, and applications that require real IP addresses are usually poor candidates for FakeDNS. Send internal domains to the LAN DNS and bypass mapping with domain rules; keep private addresses direct. For programs that use returned addresses for access control or certificate binding, confirm that mapping does not disrupt their workflow. FakeDNS is best suited to ordinary TCP and UDP connections that need public domain information restored inside TUN.

Working with sniffing and domain routing

Sniffing can recover a destination domain from some application-layer protocols, while FakeDNS recovers it from a DNS mapping; neither is a simple replacement for the other. Sniffing depends on recognizable protocol content and may not work for encrypted or non-standard traffic. FakeDNS depends on both the query and connection passing through the core. They can be combined according to traffic type, but avoid forcing every target to be replaced with a sniffed result. Logs should distinguish the original target, sniffed target, and FakeDNS-mapped target.

To validate FakeDNS, query a previously uncached domain and confirm that the returned address belongs to the mapping pool. Immediately connect to that domain and check whether the log restores the original name and matches the expected domain rule. Finally, test a LAN domain and confirm that the internal DNS still returns its real address. All three steps must pass to show that mapping, restoration, and exclusions are complete. Seeing a reserved address alone does not prove success; the subsequent connection may never have been captured by TUN.

Enable FakeDNS only when the actual problem calls for it. If ordinary DNS and domain routing are stable and applications can pass domains to the client, do not add complexity unnecessarily. Consider FakeDNS when many TUN connections show only IPs and domain-based splitting cannot work reliably. Before deploying it, test browsers, everyday applications, LAN resources, and network changes, and keep a fallback plan that disables it.

Custom outbounds, chained connections, and final validation

An outbound is the execution target selected after routing. A basic setup usually includes proxy, direct, and blocked outbounds; advanced scenarios may also need interface-specific direct connections, a dedicated DNS outbound, chained proxies, or independent connection parameters for a traffic class. Custom outbounds are valuable for expressing a clear network path, not for adding layers. Every outbound should have a unique label, a routing rule that calls it, and a target that can be tested independently.

Use stable, readable labels

Outbound labels are referenced by routing rules, DNS settings, and chain relationships. Use short, stable combinations of English letters or numbers, such as proxy-main, direct-lan, and dns-direct; avoid descriptions that change with server names. When changing a label, check every reference. A spelling mismatch usually causes a configuration-load error or sends a rule to the default outbound. Do not casually overwrite labels generated by the graphical client; first confirm which fields support user extensions.

{
  "outbounds": [
    {
      "protocol": "freedom",
      "tag": "direct-lan",
      "settings": {
        "domainStrategy": "UseIP"
      }
    },
    {
      "protocol": "blackhole",
      "tag": "blocked"
    }
  ],
  "routing": {
    "rules": [
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct-lan"
      },
      {
        "type": "field",
        "domain": [
          "domain:blocked.example"
        ],
        "outboundTag": "blocked"
      }
    ]
  }
}

freedom means establishing the connection directly from the local machine, while blackhole rejects matching traffic. Blocking rules should target explicit destinations; avoid broad conditions that disrupt normal services. The example shows only the relationship between outbounds and routing and does not include server configuration. To add a custom outbound to v2rayN, first confirm how the current configuration template merges changes. Some interfaces regenerate the core configuration when saving, so manual edits to generated files may be overwritten after switching servers.

Dependencies in chained connections

A chained connection means that one proxy outbound establishes its underlying connection through another outbound. It is useful when an intermediate path is genuinely required, but every layer adds a possible failure point. Before creating the chain, verify that the upstream and target outbounds work independently. If the upstream fails, later logs may show only a handshake timeout; if the downstream parameters are wrong, the upstream may still appear healthy. Troubleshooting must allow each segment of the chain to be tested separately.

Chained configurations must also avoid loops. If outbound A dials through outbound B, while routing sends outbound B back through outbound A, the cycle can never complete. Define which underlying exit resolves and connects to each server address, and create bootstrap rules for necessary addresses that do not depend on the chain. DNS must avoid depending on the final outbound before it exists, or the client will be unable to resolve any server at startup.

Do not mistake multiple ordinary entries in a server list for automatic chaining. Switching the active server usually only replaces the main proxy outbound; traffic passes through multiple outbounds only when forwarding relationships are explicitly configured. A longer chain does not mean better connectivity—the result depends on every network segment, protocol overhead, and recovery behavior. Without a clear requirement, one proxy outbound that can be tested independently is easier to maintain.

Direct traffic by interface or address family

Devices with multiple network adapters may use wired, wireless, virtual, and enterprise networks at the same time. A custom direct outbound can bind selected traffic to a local address or interface so it leaves through the intended network. Before configuring this, confirm that the interface name and local address are stable; a changing dynamically assigned address can invalidate a fixed binding. Linux and macOS more often use system and policy routing to control interfaces, while Windows also requires attention to interface metrics and client-side outbound binding.

Address-family policy is also an outbound boundary. If a network has only stable IPv4 connectivity, a custom outbound should not force unreachable IPv6, and vice versa. The address family returned by DNS, routing rules, and outbound connection policy must agree. When a domain has multiple addresses but fails only on some networks, test the address families separately instead of merely changing servers. After adjusting them, confirm that direct and proxy outbounds use compatible policies so the same domain does not behave differently through each exit.

Save, reload, and perform final acceptance testing

After creating custom outbounds, first verify that the core can load the configuration. Syntax errors, unknown labels, and unsupported fields usually appear in the startup log. Successful loading does not prove that the path is correct. Next, choose a clear test target for each outbound: a LAN address for direct access, a defined domain for the main proxy, a blocked target for rejection, and a chained path tested one segment at a time. Record the target, matched rule, outbound label, and result as a repeatable acceptance checklist.

A graphical client may regenerate its runtime configuration when switching servers, updating subscriptions, or changing routing schemes. After saving custom content, run the full workflow once: restart the client, update a test subscription, switch servers, reload routing, and confirm that the extension still exists. If it was overwritten, use the client's supported custom-configuration entry point, template, or merge feature instead of repeatedly editing a temporary runtime file. Long-term configuration must be stored in a location the client recognizes as persistent.

A complete advanced setup should keep input traceable, rules explainable, DNS observable, capture reversible, and outbounds independently testable. When a connection fails, identify the layer where the request stopped, then inspect that layer's logs and system state. To rebuild a minimal environment, return to the quick-start path for a basic connection, or visit the downloads page for client installation and platform choices. Restoring capabilities layer by layer from a minimal baseline produces clearer conclusions than rebuilding subscriptions, routing, DNS, and TUN simultaneously.