v2rayN Advanced Configuration

Configuration Basics and Core Boundaries

Start advanced configuration with a baseline that works. For desktop, use v2rayN; find the installer on the Client Downloads page. On Android, choose v2rayNG or v2flyNG based on the core you need. The client stores servers, generates configuration and controls runtime state; the core handles protocol connections, routing and DNS resolution. An option appearing in the interface does not mean every core handles it the same way. Before troubleshooting, identify the client, connection protocol, core and traffic-capture mode in use so you can distinguish issues at different layers.

Keep a verified connection path

First disable extra traffic-capture features. Use a known-working server and simple routing, then confirm that a browser can access the internet through the system proxy. Note the local listen address, HTTP or SOCKS port, routing mode and DNS settings. If this baseline fails, hold off on TUN and FakeDNS: adding features only adds variables; it cannot fix an incorrect server address, port or authentication parameter. A local note such as “baseline” is also more reliable than relying on a server’s fixed row number in the list.

Test real-world use cases, not just one test result in the client. A successful server test usually means the request to its test target worked with the selected configuration. It does not prove that every app follows the system proxy or that every connection type to a given service will work. Try a commonly used website, complete a routine sign-in, and check the logs to see which outbound was selected. If an app fails while the browser works, check the app’s proxy settings, connection protocol and cache before replacing the entire configuration.

Separate client settings from raw configuration

The v2rayN server editor, routing editor and DNS settings are configuration interfaces; the files generated at runtime are their output. Editing a generated file directly may not survive a server switch or core restart. For changes you need to keep, use a setting supported by the client whenever possible. If custom configuration is necessary, use the relevant custom configuration feature and save a separate copy of the original. Menu labels and setting locations may change between versions. Follow what a setting does and what the generated configuration contains, not where it appeared in an old screenshot.

The JSON examples on this page are Xray configuration snippets. They show selected fields, not a complete client configuration that can run on its own. A full configuration also needs inbounds, server outbounds and other required parameters. Do not copy fields verbatim to a different core: even when concepts share names such as “routing” or “DNS,” their field structures, defaults and behavior may differ. For desktop TUN, identify the component the client actually launches; do not infer it from the selected server protocol alone.

Change one variable at a time

Save a recoverable copy of your settings before making changes, and write down a specific goal, such as “send the test domain through this outbound,” rather than “optimize the network.” Change one related variable at a time, restart the necessary component, repeat the same test and record the result before proceeding. Routing, DNS and traffic capture often interact. Changing all three at once makes it difficult to tell what helped—even if the connection comes back—and the issue may return after the next update or restart.

Keep logs only as detailed as needed. Temporarily increasing the log level can help confirm configuration loading and rule matching, but logs may also contain domains, addresses and connection details. When asking for help, share only the relevant lines around the error and remove subscription links, authentication fields and personal browsing history. If the issue is a timeout, follow the server timeout troubleshooting steps. Once the baseline is stable, move on to the subscription and routing sections below.

Subscription Groups and Server Filters

A subscription is a way to fetch updates to a set of server configurations; a group is how the client organizes and displays those configurations. They are related, but not the same: a group can be linked to a subscription or contain servers added manually. Create groups by configuration source rather than putting every server in one list. That makes it easier to identify which source failed during an update and what will be affected if a subscription is removed or disabled. Name groups by purpose or source instead of copying long, promotional server names.

Organize sources before updating servers

Create a group in the subscription group settings, enter the subscription URL you received, save it, and update only that group. When the update finishes, check the number of results and any errors. Then return to the server list and review the addresses, protocols and remarks. For the first import, leave automatic updates off and avoid importing multiple sources at once. Confirm that fetching, parsing, saving and connecting all work for one source before adding another; this makes it easier to distinguish network issues from subscription content or group conflicts.

Subscription URLs often contain account-identifying parameters, so protect them like account credentials. Do not put the full URL in a server remark, public screenshot or support log, and do not send it through an unfamiliar URL-shortening service. If the provider changes the URL or account identifier, replace the old one in the group settings. A URL that opens but returns no servers does not necessarily indicate a client problem: account status, content format or a page returned by the service can all affect parsing.

Filters only narrow the list

Filters usually reduce the list of candidates based on server remarks or conditions supported by the client. They do not change a server’s actual location, protocol capabilities or availability. Distinguish interface search from subscription filtering: search temporarily hides non-matching rows, which return when you clear it; subscription filters can exclude entries during an update, so they never enter the local group. Check which type of setting you are using before assuming that a filtered-out server was removed by the provider.

Filter fields may accept plain keywords, multiple conditions or regular expressions, depending on the interface. Follow the instructions for the specific field. If regular expressions are supported, ^(测试|备用) matches remarks starting with “测试” or “备用”; it is only an example, and not every client filter can parse it. If the list is empty after an update, clear the filter and update again, then add conditions one at a time. Case, spaces, full-width characters and provider renames can all make a previously working filter stop matching.

Protect local changes and your current selection

Entries imported from a subscription are generally managed by later updates. If you change an address, port or transport field locally, the next update may restore the subscribed value; whether remarks are preserved also depends on how the client merges entries. If you need to maintain a configuration with different parameters, copy it to a separate manual group and note why you changed it. The subscription can then keep following its source while the manual entry remains available for controlled testing, without mixing the two maintenance approaches.

After an update, check the active server again. List order changes, renamed entries or removed subscription records can make your previous selection unsuitable. Do more than confirm “update successful”: verify that the active server is still in the expected group and test it with a real request. For batch testing, narrow the selection to servers relevant to your needs. Large concurrent tests consume network and local resources, and results depend on the test targets; they are not a reliable server-quality ranking.

Troubleshooting Empty Lists and Parse Errors

When an update fails, first identify where: if the request cannot complete, check the URL, network and whether the update requires a proxy; if the request succeeds but parsing fails, confirm the response is a subscription rather than a sign-in or expiration page; if the update succeeds but the list is empty, check filters and protocol compatibility. Do not repeatedly reset the client before confirming the source is valid. For specific troubleshooting branches, see Subscription Update Failures and Parse Errors. Keeping the original group while testing a new configuration is easier to recover from than deleting every entry.

Routing Rules and Split Tunneling

Routing decides which outbound handles a connection; it does not generate subscriptions or fix server parameters. Think of it as a decision table that checks conditions in order: once a rule matches, traffic goes to the outbound it specifies. In standard Xray routing, earlier matches take priority, so specific exceptions usually belong before broad rules. Selecting “global” or a preset in the client may change the generated rules. Before customizing, confirm which routing configuration is active.

Start with one specific goal

Write down the behavior you want to change, such as sending a test domain directly or blocking a destination you know you do not need. Do not start by importing a large set of rules from unknown sources and guessing from whether a page loads. Domain rules suit services with stable hostnames; IP rules suit networks with well-defined address ranges; use port rules cautiously and in context. A service may use several domains, content delivery addresses and sign-in endpoints, so handling only its main page may not cover the entire workflow.

In Xray rules, full:example.com matches the exact domain, while domain:example.com can match that domain and its subdomains. A plain string without these prefixes may use different matching semantics, so do not confuse “contains this keyword” with “belongs to this domain.” IP conditions can specify an address or CIDR range. For each rule, record its purpose, scope and test method. A name like “optimize rules” will not help you decide whether to remove it later.

Understand how conditions within a rule work

Different conditions within the same rule generally must all be met—for example, both the domain and port must match. Multiple candidates in the same list usually define alternatives. To send a domain and a separate IP range through the same outbound, you would normally create two rules rather than put both in one rule and expect “either/or” behavior. This detail can leave a rule in place that never matches. After adding a rule, test with a request that actually meets its conditions and check which outbound was selected.

This snippet shows a simple rule order: send a specific test domain directly, send private address ranges directly, then explicitly route remaining TCP and UDP traffic through a proxy. The direct and proxy examples must match actual outbound tags; they are not reserved names generated by the core. Merge the snippet into a valid Xray configuration—it cannot run on its own. Adjust private-address rules to your network; not every private address belongs to your device’s local network.

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["full:example.com"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": [
          "10.0.0.0/8",
          "172.16.0.0/12",
          "192.168.0.0/16"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

Domains, Resolution and Default Outbound

AsIs means the routing stage does not proactively resolve domains for IP-rule matching; an existing IP destination can still match an IP rule. If a destination is available only as a domain, some IP rules may not work as expected. IPIfNonMatch attempts to resolve the domain when no domain rule matches, then checks the result against the rules. This introduces dependencies on the resolver and resolution path. Do not ignore whether DNS requests are reachable just to make one IP rule work. Confirm the default outbound for unmatched connections, too; an explicit final rule is easier to understand.

The presence of a rule does not mean the client can see the domain it needs to match. An app may connect directly to an IP, or resolve the domain itself before connecting. Whether sniffing is enabled, which protocols it can identify, and whether the sniffed result is used for routing all affect what the client can see. Sniffing cannot recover domains from all encrypted traffic and is not a universal fix. First determine whether the request contains a domain or an IP, then decide whether to adjust routing, DNS or traffic capture. That is usually more effective than piling on matching conditions.

Test a destination covered by the rule, one outside its scope and a local service; otherwise you have only confirmed that one path works. If a new rule causes many requests to fail, disable it to restore the baseline, then check its order, conditions and outbound tag. Put blocking rules in a clearly defined scope so they do not also block DNS, authentication or update requests. Review routing tables periodically to remove outdated exceptions, and check the generated configuration again after client updates or core changes. Do not assume an old setup will always behave exactly as before.

DNS Configuration and Resolution Paths

DNS issues are rarely as simple as “use a different resolver.” Apps can use the system resolver, the client core can manage its own resolution for routing or direct connections, and a proxy server may resolve a destination remotely. These requests happen at different points and are affected by different routing and network conditions. Identify whether the failure occurs during app-side resolution, core-side resolution or the remote connection before choosing where to change a setting. If a webpage fails while the server test succeeds, DNS is one possibility—but the app may also be bypassing the expected proxy.

Map the three resolution paths

The first path is from the device to a local resolver for the domain lookups apps normally make. The second is from the core to its configured DNS service, which may be used for IP-rule matching or direct outbounds. The third is when a proxy outbound passes a domain to the server for remote resolution. Not every connection uses all three paths. For the mode you are using, note where the query originates, which outbound carries it and what type of address it returns. That makes it easier to see why a DNS setting affects some sites but not others.

Also check how the resolver itself connects. Traditional UDP queries and encrypted HTTPS queries have different transport requirements; changing the address to a URL does not mean every core will adapt automatically. Xray DNS handles different address formats in specific ways, including whether queries use core routing or a local connection. Other components may use different fields. Check which formats your current core supports, then verify that DNS requests actually use the outbound you intend.

Prevent bootstrap resolution loops

A DNS service configured by domain needs an IP address before it can be reached. If the proxy server address is also a domain, it must be resolved before the proxy connection can be established. Requiring all DNS traffic to go through a proxy that is not up yet creates a loop if that proxy depends on the same DNS. The result can be timeouts for every request after startup. Provide a reachable bootstrap resolution path for the server or DNS service, independent of the connection that has not yet been established, instead of adding more timeouts and retries.

This simplified snippet shows Xray’s built-in DNS: a static mapping overrides a test domain, while the server list and query strategy control lookups by the built-in resolver. It does not take over all operating system DNS or specify an outbound for DNS requests. example.com and the documentation example addresses illustrate structure only; do not use them as production DNS settings. Choose actual resolvers based on network reachability and your operational requirements.

{
  "dns": {
    "hosts": {
      "example.com": "192.0.2.10"
    },
    "servers": [
      "1.1.1.1",
      "8.8.8.8"
    ],
    "queryStrategy": "UseIP"
  }
}

A static mapping bypasses normal dynamic resolution for that domain. It can help with short-term diagnostics, but avoid pinning addresses for content delivery services. A service may return different addresses by region, load or time; a stale fixed result can break connections. Remove temporary mappings after testing and send a new request. A correct DNS result does not prove the service is reachable: check the destination port, transport protocol and server behavior before attributing later connection errors to DNS.

IPv4, IPv6 and Caching

UseIP queries for both IPv4 and IPv6 addresses; UseIPv4 or UseIPv6 limits the query to one address family. Restricting queries to IPv4 can help isolate an IPv6 path problem, but it is not universally faster. A device receiving an IPv6 address does not mean the selected outbound can connect to it correctly. Conversely, a destination that supports only IPv6 cannot be reached by forcing IPv4. Consider the capabilities of the device network, proxy server and destination service.

DNS results may be cached by the operating system, browser, app and core. Reloading an open page immediately after changing DNS may reuse an old address or existing connection. For testing, create a new connection and, if needed, restart the affected app and core. On Windows, use the system DNS cache-clearing tool. Cache management on macOS and Linux depends on the system service; do not copy commands from another platform. Recording resolution results before and after a change is more useful than repeatedly clearing every setting.

Use symptoms to narrow it down, not just the resolver name

If a domain fails but a known IP path to the same service works, check for query timeouts, address types and returned results. If the domain resolves but the connection fails, investigate routing, ports and server parameters. If the problem occurs only under TUN, check DNS capture and the virtual interface path. If changing resolvers fixes the issue, that only shows the old path failed in this test; it does not prove the new resolver is better for every app. Align the final configuration with your routing goals and keep a known-good resolution path for restoring the baseline.

TUN Mode and Traffic Capture

Apps that follow system settings use the system proxy. TUN captures selected IP traffic through a virtual network interface and passes it to a processing component, so it operates at a different layer. TUN may offer another path for apps that ignore the system proxy, but it does not mean all traffic will necessarily use a proxy. System routes, exclusions, DNS capture, UDP support and outbound configuration still matter. A working system-proxy setup is an important baseline before enabling TUN. Do not treat TUN as a fix for a failed server connection.

Check the processing component and system permissions

Before enabling TUN in v2rayN, review the relevant settings in your client and check the startup logs for the component it launches. A server using the Xray protocol does not mean the same core creates the TUN interface. Components may differ in configuration structure, network stack and DNS behavior, so do not apply raw Xray fields to another component’s TUN configuration. For the first test, keep the defaults or make few changes. Verify interface creation, route installation and request paths before adjusting finer details.

Virtual interfaces and system route changes often require elevated permissions. On Windows, grant the permissions required by the client; on Linux, allow interface creation and route changes; on macOS, complete the system authorization requested by the client. Confirm permission errors in logs or system prompts rather than relying on the toggle’s state. The setting may appear enabled even if no interface was created or routes installed, leaving apps on their original path. Fix permissions or startup failures before changing split-tunneling rules.

Avoid loops and double capture

Connections captured by TUN use an outbound to establish their network connection; the outbound’s own connection cannot simply be sent back through the same entry point. Clients usually handle this with interface selection, route exclusions or other mechanisms. If the device is also running another VPN, gateway app or traffic-capture tool, their mechanisms may conflict or override one another. Disable the other capture tools to establish a baseline, then re-enable them one at a time and watch for route conflicts. Two apps both showing “connected” does not prove they can work together.

After enabling TUN, decide whether to keep the system proxy enabled. If an app sends requests to a local proxy and another layer captures them, you may get double capture, unexpected routing or confusing logs. Client modes differ, so do not assume both must always be on or always off. Follow the instructions for your mode and test each setup. Checking whether requests still pass through the local proxy port can help explain why some apps behave differently when the system proxy is disabled.

MTU, UDP and Local Network Access

MTU sets the maximum packet size allowed on an interface. Encapsulation and network conditions can cause problems with larger packets, but lowering MTU without a reason can increase fragmentation and processing overhead. Investigate MTU when symptoms point to it, such as a successful handshake followed by stalled transfers or failures on specific large requests. Make small adjustments and retest the same request; there is no single value that works for every platform. Test UDP separately, because working TCP requests from a browser do not prove that apps relying on UDP will work.

Pay special attention to local network printing, file sharing and device discovery. Some features rely on broadcast or multicast, so adding a direct rule for a private address will not necessarily restore them. First confirm that ordinary local network addresses are reachable, then check whether the virtual interface or firewall is affecting discovery. Capturing this device’s traffic with TUN does not automatically let other devices use its proxy. Sharing a proxy requires separate listen-address and firewall settings; see Allowing LAN Connections.

Test in stages and restore on exit

After enabling TUN, test in this order: confirm the component starts, verify the interface and routes, check DNS, then test a browser, an app that does not follow the system proxy, and a local service. On Android, when using system VPN capture, also check which apps are included or excluded and whether background restrictions apply. If the network still behaves differently after capture is disabled, check whether the system proxy and DNS were restored and whether any routes remain. Do not keep toggling the setting to mask leftover state. Restore the baseline, then use the symptom categories in the Help Center to continue troubleshooting.

FakeDNS and Domain Recovery

FakeDNS does not return a destination service’s real address. Instead, it assigns a controlled address to the domain and stores the mapping between them. When an app connects to that address, the processing component uses the mapping to recover the domain before routing and selecting an outbound. This can preserve domain information when an app provides only an IP at the network layer, but only if both the DNS query and subsequent connection pass through a compatible processing chain. FakeDNS is not simply an alias for ordinary DNS; entering a DNS server address alone does not configure the full flow.

Verify the full request path first

The complete path has four steps: the app makes a DNS query, FakeDNS returns a mapped address, the app connects to that address, and the entry point recovers the domain. If any step bypasses the processing component, the app may try to connect to a controlled address it cannot reach. Common causes include system DNS not being captured, an app using its own resolution path, the destination bypassing the expected interface, or the client entry point lacking domain-recovery support. First confirm that DNS and traffic capture work; do not add FakeDNS on top of an already broken DNS setup.

Different cores and TUN components may offer similar concepts with different fields. Xray FakeDNS must work with its built-in DNS and inbound sniffing settings; do not apply Xray fields directly to another component’s fake-IP feature. Configure it only when the active component explicitly supports it and provides the required entry point. If the client only offers a choice of standard DNS modes, do not paste the snippet below into an unknown field or try to imitate a mapping by changing a subscription server address.

Address Pool and Mapping Capacity

This Xray address-pool snippet does not enable a complete FakeDNS request path by itself. ipPool specifies the controlled address range, and poolSize sets the mapping pool capacity. The example uses a special-purpose network range, not a public address range for apps to access directly. Make sure it does not overlap with an existing device network or another traffic-capture tool. Set capacity within the component’s supported range; do not increase it blindly for “performance” or exceed the number of addresses available in the selected range.

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

The mapping pool is finite, and the component may evict old mappings under capacity pressure. If an app keeps a controlled address in its cache, later connections may encounter a missing or changed mapping. Consider mapping lifetimes alongside app caching. Problems that appear after a long uptime but briefly disappear after a restart do not necessarily mean the server is unstable: the app may retain a stale address, or the capture component may have lost mappings when it restarted. When troubleshooting, note how restarts, caches and reproduction times relate.

Know when mapped addresses are a poor fit

Local network services, tools that require real IPs, and apps that pass a resolved address to another device may not work well with controlled addresses. For example, if this device gets a mapped address and sends it to another device on the LAN that does not share the mapping, that device cannot connect. For exceptions, use a domain-exclusion or real-resolution method supported by the current component, and verify that subsequent routing remains consistent. Excluding only the DNS query is not enough if the real connection still goes through an unsuitable outbound.

If an app uses encrypted DNS or connects directly to an IP, FakeDNS may not be involved at all. A missing mapping in the logs does not necessarily mean the feature is broken; the request may have taken a different path. Change an app’s resolution behavior through its own settings where available. Assuming every query is intercepted can lead to incorrect conclusions. Sniffing also has protocol limits and cannot recover the original domain from every connection, especially when the request contains no identifiable host information.

Test the benefit with a limited trial

Start with a regular test destination you can access repeatedly. Confirm that the query returns a controlled address, the connection is captured, the logs show the original domain, and the expected outbound is selected. Then test a LAN destination and one configured exception to make sure they still use real DNS. If you are enabling FakeDNS only to make an existing domain rule work, but the request already includes a domain, FakeDNS may not help. Simpler routing and DNS settings are usually easier to maintain; do not add complexity just to turn on a feature.

To roll back, disable the related mapping settings in order, restore the DNS setup, restart affected components and apps, then retest the baseline. Turning off one setting while leaving an old address-pool route in place—or changing DNS while an app still holds a mapped address—can leave the issue unresolved. Save experimental and stable configurations separately so it is clear which settings were for FakeDNS and you do not leave behind a confusing, half-configured request path.

Managing Multiple Subscriptions and Updates

The goal of managing multiple subscriptions is not to make the list longer; it is to give each source a clear maintenance boundary. If one source is for everyday use and another is for a specific environment or backup, use separate groups and state their purpose. A successful subscription fetch, correct server parameters and a working connection are three different outcomes; verify each separately. Do not reuse unknown credentials across sources. A link whose provider and purpose you cannot explain should not be part of a long-term automatic update workflow.

Keep a source list and update schedule

For each subscription, note its source name, purpose, last manually verified result and whether updates need to go through a proxy. These notes do not need to be in a public file, and you do not need to store the full URL. The point is to know which source to check when something goes wrong. Set automatic update frequency based on the provider’s update schedule and your needs. Frequent fetching may trigger rate limits and cause the client to replace the list more often. Manual updates may suit groups used infrequently or still being tested for compatibility.

Updating automatically at startup is convenient, but the network may not be ready yet. The device may just have joined Wi-Fi, the proxy may not have started, or the account page may require authentication. First establish a working saved connection, then update sources that depend on the proxy if needed. Avoid a circular dependency where your only working connection must be fetched from a subscription, but fetching that subscription requires the connection to already exist.

Update one group at a time, not every source at once

When maintaining multiple sources, update one group, review added and removed entries and any errors, then test key servers before moving to the next group. This preserves a comparison point if one source returns bad content. Copy important manual changes to a separate group beforehand. Subscription content is managed by its source, so do not expect the client to keep servers the provider has withdrawn. Design update handling and local customization as separate workflows.

If a server count changes substantially after an update, check filters, protocol compatibility and provider messages before concluding that the content changed. Counts alone do not indicate quality: one server may have multiple transport endpoints, and entries with the same name may point to different addresses. When needed, compare addresses, ports, protocols and transport parameters—not just remarks. If the client cannot parse an entry, confirm which core features it requires. Updating the client may resolve some compatibility issues, but cannot replace correct server parameters.

Duplicate Entries and Failure Correlation

The same remark appearing in two sources does not necessarily mean they are distinct backups. If the address, port, authentication and transport settings are identical, the entries may simply be duplicate copies of the same configuration. Even different addresses may share the same underlying infrastructure, so having more subscriptions does not automatically spread risk. Keep source information while reviewing duplicates, then decide whether to hide or remove them. Do not strip all source labels just to make the list look tidy; they are useful for future updates and troubleshooting.

When a problem occurs, first determine its scope: if one entry fails, check its parameters; if an entire group fails, check the source and shared settings; if every source fails, check the local network, system time, runtime core, DNS and capture mode. This order avoids unnecessary bulk deletion and re-imports. Test a few real requests from backup sources periodically rather than leaving them idle in the list. A recorded successful test is more useful than a long list of servers that merely look available.

Disabling Sources and Restoring Settings

For a source you no longer use, first disable automatic updates, check whether the active server still comes from that group, then delete it if needed. Before removing it, confirm that no routing rule or custom configuration depends on its entries and that you will not lose your only working connection. Configuration backups may contain subscription URLs and credentials when moving to another device. Transfer them using a method you control, test the new device, and only then remove the old copy. Client settings backups are not suitable for public sharing as tutorial attachments.

A simple maintenance note is enough: which source you updated, which filter you changed, which group is currently stable, and how to roll back if something goes wrong. There is no need to log every request, but important changes should be clearly described. If subscriptions still fail to parse, return to Groups & Filters and check the import process. If subscriptions work but one app fails, investigate routing, DNS or TUN instead of adding more sources to mask a configuration problem.

Custom Outbounds and Configuration Validation

An outbound describes how traffic leaves the core; routing selects which outbound to use. A server in the list is not necessarily addressable by its remark in custom rules: rules usually refer to outbound tags in the runtime configuration. Before customizing, clarify whether you need an additional direct outbound, an explicit block, a specific server outbound or a chain between outbounds. Each goal requires different fields. Custom configuration is for needs the client’s standard settings cannot express; it is not the best starting point for everyday use.

Tags must resolve within the same configuration

Give each outbound a clear, unique tag. The outboundTag in a rule must match it exactly; tags are not display names and similar capitalization does not link them automatically. A common mistake when copying rules is referencing someone else’s tag without defining the corresponding outbound. Another is that the client reorganizes outbounds when regenerating the configuration. Save persistent rules through a supported interface and verify the generated configuration, not just the text in the editor.

This Xray snippet defines only two basic outbounds: freedom for direct connections and blackhole for blocking. It has no proxy server outbound, inbound or complete routing, so it cannot run as a full configuration. When merging it, check existing tags to avoid duplicate definitions. To use the proxy tag in the routing example above, you also need a real proxy outbound with valid parameters in the same configuration; an empty object cannot stand in for server details.

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

Direct Resolution and Server Protocol Parameters

A direct outbound ultimately connects to the actual destination address, so domains require a resolution path. In Xray, domainStrategy under freedom can change how domains are handled during direct connections. It is not the same setting as routing.domainStrategy: the former applies when establishing an outbound connection, while the latter applies to routing matches. Do not change both just because their names are similar. First determine whether the problem occurs before rule selection or while establishing the connection, then adjust the relevant layer.

Configure proxy outbounds with the protocol and parameters provided by the service provider; a protocol name alone is not enough to infer the remaining fields. The address, port, authentication, transport and security settings must work together. When using REALITY, the provider must also supply its related parameters; see the REALITY glossary entry for what the fields mean. Supported features vary between cores; for core family details, see the Xray entry. Do not leave required parameters blank just to pass a syntax check.

Chained Outbounds Do Not Provide Automatic Failover

When one outbound connects through another, consider reachability of the underlying connection, where DNS resolution occurs and whether UDP is supported. Xray proxy relationships may use proxySettings; other components may use different fields. Follow the current core’s configuration structure rather than copying fields blindly. Chains must not form a loop—for example, outbound A depends on B while B depends on A. Each additional connection adds a potential failure point; it does not automatically improve availability or switch connections based on tag order.

Automatic selection or failover needs a matching health-check and selection mechanism, along with clear definitions of failure, when to switch and what happens to existing connections. Without those mechanisms, defining multiple outbounds does not make the core try them in rotation. For most use cases, test each outbound separately first, then create a fixed rule for a specific target. For a chain, test the underlying outbound, then the upstream server connection, and finally the destination request. This helps identify which of the three layers failed instead of labeling everything “server timeout.”

Check the structure, then run comparison tests

Validate configuration in three steps. First, check the JSON for trailing commas, unclosed quotes and duplicate fields. Next, confirm that the current core supports each field and that every tag reference is defined. Finally, start the component and observe real requests. Valid syntax does not guarantee valid fields, and a successful startup does not prove that routing selects the intended outbound. Watch for same-named fields copied from another component and snippets placed at the wrong level. If the configuration fails, restore the saved original and add only the required content, one step at a time.

At minimum, test a target covered by a rule, the default path, DNS and a local service. Check the logs to confirm the new configuration loaded, the expected outbound was selected, and whether failure occurred during resolution, handshake or data transfer. When testing is done, return temporary verbose logging to a level suitable for everyday use and remove experimental rules you no longer need. A stable configuration should make the purpose of every outbound and exception clear. A block of unexplained text is often a greater maintenance risk than the original problem.

If customization disrupts basic connectivity, restore the quick-start setup using the Getting Started Guide, then return to the relevant section based on the symptoms. If you need another client installer, use the Downloads page; do not assume a configuration issue is caused by the installer. Advanced configuration is not about the number of fields: request paths should be clear, problems reproducible, changes reversible, and the apps you rely on tested in practice.