v2rayN
Advanced Configuration Guide

Configuration layers and backups

Know the difference between the client, core, and operating system

The v2rayN main window stores server details, subscription groups, routing presets, and interface options. When a connection starts, the client uses this information to generate the runtime configuration required by the core. The system proxy is an operating system setting that tells apps configured to use it to send requests to a local proxy port. These three layers are connected, but they are not the same switch. Changing the server list does not change how every app connects, and enabling the system proxy does not add routing rules to the core.

Before inspecting configuration files, check the selected server, routing preset, and running core in the client, then review the status bar and logs. This site's desktop instructions focus on v2rayN; the Android client is v2rayNG, and v2flyNG is an alternative client that uses the V2Fly core. Similar interfaces do not mean identical configuration fields. Even when two clients can import the same share link, they may generate different configurations internally. When switching clients, migrate connection details first, then recreate advanced settings one by one.

Set a baseline you can restore

Before making changes, use the client's backup or export option to save your current configuration. Note the system proxy state, listening address, local port, routing preset, and TUN setting. If you plan to copy the client data directory, exit the client first so its database and configuration files are fully written. Backups may contain subscription URLs and server credentials; keep them in a secure local location rather than attaching them to a public support post.

A baseline means more than “the webpage loads.” Check that a regularly used app connects, devices on your local network remain accessible, and the system network recovers when you close the client. Note which actions rely on the system proxy and which rely on TUN. If a particular type of request fails later, you can narrow the cause to the entry point, routing, or DNS instead of reverting everything at once. To re-establish a basic connection, follow the user guide and verify it before moving on to advanced settings.

Change one variable at a time

Make changes in this order: subscriptions, routing, DNS, then TUN. Change one topic at a time, save and reload, then start a new connection. Existing long-lived connections usually do not move to a new route just because a rule changed. When reviewing logs, use the same target and app each time to avoid mistaking cached results, app retries, or a temporary site issue for a configuration change. To compare two settings, write down the expected result first—for example, “local network traffic should go direct instead of through the proxy”—then check the actual outbound.

Set a baseline for log verbosity, too. Keep the client default for normal use and increase detail briefly when troubleshooting. Logs may include domains, addresses, paths, and subscription request details; remove credentials and personal network information before sharing them. An error log shows what happened, but the last line is not necessarily the cause. Trace back from the first failure: confirm the core started successfully, then check DNS and the target connection. Do not treat every resulting error as a separate problem.

Do not edit a temporary runtime file generated by the client and expect the change to persist. Reconnecting, switching servers, or updating a subscription can regenerate it. Change options in the interface when they are available there; for custom settings, use the client’s designated configuration interface and back up the original. Passing JSON syntax validation does not mean a field is supported by the current core. If you see an unknown field, unsupported protocol, or configuration parse error, check the core type first, then verify where the field is nested.

All the configuration advice on this page follows the same principle: the client saves your intent, the core applies the rules, and the operating system controls the traffic entry point. For startup failures, port conflicts, or a system proxy that remains enabled, see Common Questions and find the matching symptom. For the locations of controls in the main window, see A tour of the v2rayN main window.

Subscription groups and server filters

Give each subscription its own management boundary

Group subscriptions by configuration source, not by the results of a single speed test. In v2rayN, add a group under “Subscription Groups,” enter a recognizable note and the subscription URL, save, then update it. Use a note that identifies the source and purpose, such as a work device or test configuration; do not copy authentication details from the URL into the note. Update this group by itself first, confirm that the contents are from the expected source, and only then include it in your regular server selection.

“All” is usually an aggregate view of the server list; it does not mean every row comes from the same subscription. Before deleting items or running a bulk action, switch to the target group and check the active filters and selection. The same alias can appear in different groups, and an alias is not a unique server identifier. To identify duplicates, compare the protocol, destination address, port, and transport settings. Do not delete an entry just because its name matches another.

Distinguish list search from update filters

Search in the server list mainly affects which items are displayed. Filters in subscription settings may affect which items remain after an update, so the risks are different. If an entry is missing, clear the search text first, check that the right group is selected, then inspect the subscription update filters. Do not assume a subscription has been emptied while a filter is still active, and do not delete and re-add the group straight away—you could lose working filter and update settings.

Some interfaces match keywords, while other filters accept regular expressions. Follow the instructions next to the input field; do not mix the two syntaxes. If regular expressions are explicitly supported, start with a broad inclusion pattern and narrow it down gradually. These examples show how to filter by alias; they match specific name fragments only. They are not routing rules and do not determine which outbound handles traffic. Subscription providers supply the names, which do not guarantee a server's actual location or capabilities.

Hong Kong|Japan
^(Hong Kong|Japan)
Test|Backup

The first line matches names containing either term; the second requires a name to start with one of them; the third can be used in an input that supports exclusion patterns. Each line is a separate example, not part of a multi-line configuration to paste. If the client has only one filter field, check whether it includes or excludes matches. In a regular expression, the pipe means “or”; it is not an ordinary text separator. If subscription names include characters such as parentheses or plus signs, you may also need to escape them.

Keep working entries before updating

Updating a subscription usually replaces the server details managed by that source. Manual changes to subscription servers may be overwritten the next time you update. To keep a separate version, copy the entry to a dedicated manual group, edit the copy, and add a note describing its purpose. This keeps source-managed details separate from locally maintained ones. Manual copies do not receive address changes from the subscription, so check periodically that they still work; copying one does not guarantee it will remain usable.

After changing a filter, update one group and read the update notice. If no entries appear, check the filter direction, expression, subscription response, and network connection in that order. The response may be an error page, login prompt, or quota notice rather than a parseable server list; an update failure is not necessarily a regex problem. Keep the original group details, restore a broader filter, and try again. Do not overwrite working configuration by repeatedly running full updates.

Treat importing a share link and updating a subscription as separate workflows. A clipboard import adds a set of connection details as they exist at that moment; a subscription URL provides a way to update them later. Both may add the same servers, but they are maintained differently. Keep configurations that need ongoing updates in clearly named subscription groups; one-off test links are easier to clean up in a manual group. QR codes and links contain connection credentials, so do not share them in ordinary screenshots.

Choose servers based on real connection tests. A successful TCP connection to a port only confirms that part of the path is reachable; it does not prove that the protocol handshake, destination lookup, or webpage request will succeed. Do not permanently filter out large numbers of entries based on one brief test. To understand different test results, see TCPing, real connection latency, and download speed tests, then choose filters that fit your everyday use.

Routing rules in practice: order, matching, and outbounds

First identify which traffic the rules handle

Routing rules only apply to connections that have entered the core. If an app does not use the system proxy and is not handled by TUN, changing core routing will not change its network path. A “Global” preset generally means that requests entering the core use the proxy outbound by default; it does not mean that all operating system traffic is going through the proxy. Before troubleshooting rules, confirm the app's entry point. For more on the difference between the system proxy and routing, see System proxy and routing modes.

In v2rayN's routing settings, copy the current preset before adding or removing rules. Cores usually check rules from top to bottom, and the first match determines the outbound, so put specific exceptions before broad rules. When a rule specifies both a domain and a port, both conditions usually have to match; multiple entries in the same domain array match any of those entries. Packing every condition into one rule can make it more restrictive than you expect.

Use an order that's easy to verify

This snippet handles local network domains and private destination addresses first, then shows an exact-domain blocking example, followed by direct routing for a domain group. It shows only the routing object. The complete configuration must define outbounds named direct and block and load the corresponding rule data. The reserved domain in the example illustrates syntax; it does not suggest blocking a real service. The outbound for unmatched requests still depends on the complete configuration.

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["domain:lan"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["full:blocked.example"],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      }
    ]
  }
}

full: matches an exact domain, domain: matches a domain and its subdomains, geosite: references a domain set, and geoip: references an IP address set. Whether a set exists and what it covers depends on the data files actually loaded. Missing rule data can prevent the configuration from loading or make rules unavailable. Correct field spelling alone does not mean the environment is fully configured. Domain classifications may also change when the data is updated, so recheck critical services.

geoip:private matches private and other reserved destination addresses; it does not mean “all local service names.” When you access a router, printer, or internal service by domain name, the core may not yet have a destination IP address. With the AsIs strategy in particular, internal domains may need explicit rules. Enterprise networks may also use internal addresses outside common private ranges; add the actual CIDR ranges rather than broadening direct access indiscriminately.

Understand domain strategies and fallback behavior

AsIs does not actively resolve every domain to an IP address for IP rules. IPIfNonMatch can try to resolve a domain after it fails to match a domain rule, then check the resulting address against IP rules. IPOnDemand resolves more proactively when an IP-based rule requires it. The latter strategies tie routing results to DNS results and may add lookups and wait time. Before choosing a strategy, decide whether your rules are primarily based on domains or IP addresses; proactive resolution is not a universal performance improvement.

In a complete Xray configuration, connections that match no routing rule usually use the first outbound in the array. A client preset may also generate additional fallback rules, so a partial snippet does not tell you the final default behavior. To use a final rule as a fallback, specify the network types and destination it covers, and make sure it does not match traffic intended for later rules. After changing a preset, inspect the generated configuration or routing logs to confirm the actual order rather than relying on the preset name.

For validation, choose a repeatable request for each important rule: check that an internal service goes direct, an exact domain uses the specified outbound, and other domains use the fallback. Start a new connection each time and note the destination domain, resolved address, and outbound tag. If a rule does not take effect, check in this order: did the traffic enter the core, is the rule high enough in the list, do all conditions match, and does the outbound tag exist? Browser caching and connection reuse can hide changes; reloading a page does not necessarily start a new network connection.

DNS configuration: align resolution with routing

Check the resolver separately from the destination connection

A single visit may involve system DNS, browser Secure DNS, the client's built-in DNS, and remote resolution. Not all of them are necessarily used, and they may follow different network paths. If an app passes a domain name to the proxy, the local device may not need to resolve the destination first. If the app resolves it before connecting, the core may see only an IP address. Before tuning DNS, establish who is making the query, which resolver it asks, and where the query travels. Otherwise, changing the DNS server may not change the resolver actually in use.

The DNS server address and whether its queries go direct or through a proxy are separate questions. Some cores route internal DNS requests; some special modes bypass normal handling. Whether the remote server can resolve a destination is also different from which resolver the local device uses. When troubleshooting, use the client logs to identify which layer issued the request, then determine whether the failure occurred during lookup or while connecting to the destination. Do not assume that a failed destination handshake means DNS poisoning or a resolver failure.

Start with a limited split

This partial example uses Xray's built-in DNS: regular queries go to a public resolver, while selected domain groups and local network names prefer the local resolver. 192.168.1.1 is suitable only if a DNS server is actually available at that address on your network. Replace it with the actual gateway or internal DNS address before use. Plain DNS is used here to explain the roles; it may not suit every network and does not encrypt queries.

{
  "dns": {
    "queryStrategy": "UseIPv4",
    "servers": [
      {
        "address": "192.168.1.1",
        "domains": ["geosite:cn", "domain:lan"],
        "skipFallback": true
      },
      "1.1.1.1"
    ]
  }
}

domains specifies the domain scope a server should handle first. skipFallback keeps it out of general fallback selection for other domains; by itself, it does not guarantee that internal domains will never be sent to another server. For strict separation of internal domains, also account for the fallback options in your core and verify the actual query logs. If the internal resolver returns no result, fix the internal records rather than adding a public fallback that could send internal names to an unrelated resolver.

UseIPv4 is an example query strategy, not a recommendation to disable IPv6 for everyone. If your network has reliable IPv6, use a dual-stack strategy supported by your core. Test address families only when IPv6 connections consistently fail. If DNS returns an IPv6 address but the app or outbound has no usable IPv6 route, the connection may stall before falling back. Check the system's addresses, default route, DNS response, and proxy support separately instead of simply removing one DNS result.

Prevent DNS requests from looping back

When encrypted DNS uses a hostname for its server address, that hostname must be resolved first—this is the bootstrap DNS problem. If bootstrapping depends on the same encrypted connection that has not yet been established, the requests can loop. The client may offer bootstrap DNS or static host mappings; configure them according to your core's documentation. With TUN enabled, also make sure the resolver's connection is not mistakenly routed back through the same entry point. Repeated queries and connection retries in the logs are a sign to check for a loop.

Domain routing and DNS routing should express the same intent. Internal services need an address recognized by the internal network when routed direct. For destinations accessed through a proxy, consider whether their resolved addresses are reachable from the remote side. IP-set rules depend on DNS results, so different resolvers may return addresses that match different outbounds. If a destination's route keeps changing, compare the routing domain strategy with DNS server selection before adding every domain to IP rules.

After changing DNS, account for caches at each layer. Apps, the operating system, and the core may all cache answers, so restarting just one may not be enough. Start by reconnecting the app, then clear the system cache using its supported method, and restart the client core if necessary. A browser with Secure DNS enabled may keep bypassing system DNS settings. For comparison, temporarily use system DNS during testing, then restore the original setting once you have identified the cause. Do not change the browser, system, and core resolvers all at once.

When comparing configurations, keep the app and destination fixed. Observe the first lookup, requests after the result is cached, and what happens when a new connection is established. More resolvers do not necessarily mean faster results; too many fallbacks make the path less predictable. Set one default resolver and a small number of necessary exceptions before considering more granular rules. If problems arise, restore the default DNS and keep the original routing to see whether the issue really came from the resolution layer.

TUN mode: traffic scope and routing rollback

TUN handles the entry point; it does not replace connection details

TUN receives IP traffic sent by the operating system through a virtual network interface, then processes it using the client's network stack or associated core component. It is useful for apps that do not follow the system proxy, but it does not guarantee the same behavior for every protocol. A standard system proxy mainly handles proxy connections explicitly requested by apps; TUN involves system routes, DNS, and a virtual interface. They use different entry points, but both still depend on a working server and suitable routing rules.

Before enabling “Enable TUN mode” in v2rayN, make sure the regular proxy works for your destination. If the server itself is unavailable, enabling TUN only broadens the impact of the problem. The client may require administrator privileges, system network extension approval, or a companion component, depending on the platform and installation method. Follow the prompts to grant access. Do not disable system protections or make the entire application directory writable to all users just to bypass an error.

Start with a minimal traffic-capture test

For the first test, close other software that creates virtual network adapters or changes the default route, and note your current network interfaces. Then enable TUN. Check the startup logs for successful interface creation, confirm the corresponding virtual interface appears in the system, and test an app that does not normally use the system proxy. If the interface switch is on but the core has not started, traffic may not be handled correctly. Trust the logs and an actual request, not the switch color.

Different components may handle the TUN interface in desktop clients, so do not treat an Xray routing snippet as a universal TUN configuration. Start with the client's default template, confirm it works, then adjust excluded networks, DNS interception, or network stack options. Android's v2rayNG uses the system VPN interface to handle app traffic, and its options differ from those in desktop clients. After changing app scope, reconnect before testing the result.

Distinguish entry-point exclusions from direct routing in the core

An entry-point exclusion keeps traffic out of TUN; direct in the core means traffic has already entered the core and is then connected directly to its destination. Both may allow access to a local network, but they affect logs, DNS, and system routing differently. When accessing a printer, file share, or internal service, first check whether its protocol works with your current network stack, then choose an entry-point exclusion or direct routing in the core. A webpage loading does not prove that every local network discovery protocol will work.

Pay particular attention to the route used by the server connection itself. Connections from a proxy outbound to its server must reach the real network; they must not be sent back into the same TUN entry point, creating a loop. The client's default template usually handles the necessary exclusions or binding, but custom routing, multiple virtual interfaces, and external networking tools can disrupt them. If the logs repeatedly show the same server connection, CPU usage spikes, or connections time out immediately, check for an outbound loop before switching servers.

Enabling the system proxy and TUN at the same time is not necessarily wrong, but it makes the traffic entry point harder to identify. Some apps may use the system proxy to connect to a local port, while TUN handles others directly. To establish a baseline, clear the system proxy and test with TUN alone. To return to regular proxy mode, turn off TUN and enable the system proxy. Record each change so you do not leave the system proxy pointing at a stopped port after closing the client.

After waking from sleep, switching Wi-Fi networks, or connecting an Ethernet cable, the default interface and gateway may change. If failures happen only in these situations, reconnect the client and check whether the interface and DNS settings update with the network. Do not hide a recovery problem by permanently expanding the traffic capture scope. When testing is done, turn TUN off, confirm its virtual routes have been removed, and verify basic connectivity without the client. If problems remain, restore system network settings one at a time.

FakeDNS: virtual addresses and domain recovery

A virtual address is not the destination server's address

FakeDNS assigns a domain an internal virtual address and stores the mapping between the domain and address in the core. When an app connects to that address, the traffic must re-enter a processing chain that can read the mapping. The core can then recover the domain and continue routing. This preserves domain information, especially when an app resolves a name before connecting. A virtual address does not provide a remote service and cannot be accessed directly over a regular network.

FakeDNS is not a feature you can enable just by switching to a different DNS server. The DNS response, virtual network range, mapping lookup, and outbound handling must work together. If an app receives a virtual address but its connection never reaches the corresponding core, the request will time out. Likewise, if one process answers DNS and another process handles the connection without access to the same mapping, domain recovery will not work reliably. Map out this path before adjusting the address pool size.

The configuration snippet needs a matching inbound

This partial Xray-format example shows a virtual address pool and DNS selection. It does not include TUN handling, a complete inbound, or outbounds, so it cannot run on its own. The address range is reserved for this purpose, but still check whether it conflicts with your network or other virtual interfaces. Do not paste this into a TUN core that uses a different field structure. If the client provides a complete FakeDNS template, use it to keep all the components consistent.

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

An Xray inbound that supports this mechanism also needs the appropriate domain recovery capability. The snippet below shows only the sniffing field inside an inbound object; it is not a standalone inbound. Here, fakedns means attempting to recover the destination domain from a virtual address mapping. It does not mean the core can read application-layer data in every encrypted protocol. Enable other destination-detection options only as needed for the protocol and core in use.

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

The address pool size determines how many mappings can be maintained, not the connection speed. If the pool is too small, there are too many concurrent domains, or cached mappings live too long, older mappings may be replaced. If an app is still caching an old address, later connections may lose their domain association. Increasing pool capacity is only one possible fix; also consider memory use, app caching, and reconnection behavior. Do not treat a larger pool as a universal solution to intermittent connection errors.

Handle exceptions that need real addresses

Local network names, internal authentication services, and apps that share resolved addresses with other devices may need real addresses. Exclude these queries from FakeDNS by domain or purpose and send them to an appropriate internal resolver. Exceptions need consistent routing as well as DNS rules: requests with real addresses must use the right outbound, while virtual-address requests must stay in the mapping chain. If the same domain sometimes resolves to a real address and sometimes to a virtual one, check resolver selection and cache sources first.

An app's built-in Secure DNS may also bypass FakeDNS. Some connections may then use real addresses and others virtual ones, resulting in inconsistent behavior. For testing, use a fixed DNS entry point. Check whether the response falls within the configured address pool, then verify that the core can recover the domain. Seeing a virtual address only confirms that the DNS response worked; it does not prove that the connection succeeded. Confirm that the request matches the expected domain rule and reaches the real destination.

For a safe rollback, restore the regular DNS configuration, reload the core, clear system and app DNS caches, then reconnect. If needed, close apps that still retain connection pools. Once virtual addresses no longer appear, check that regular DNS and routing work. If only one app fails with FakeDNS enabled, create a controlled exception to compare behavior; do not immediately enlarge the entire address pool or route all traffic direct.

Whether FakeDNS is worth enabling depends on whether you need to solve routing problems caused by lost domain information. If your existing domain entry point, regular DNS, and routing work reliably, leave them as they are. FakeDNS changes the relationship between resolution and connections; it is not a required performance switch. Stability depends on a complete processing chain, clearly defined exceptions, and reliable cache clearing and rollback steps.

Managing multiple subscriptions: updates, deduplication, and device migration

Set naming and update conventions first

When using multiple subscriptions, the biggest risk is not their number but mixing up their sources and purposes. Create a separate group for each source, then use notes to distinguish everyday use, temporary tests, and manually retained entries. Keep group names stable; server aliases may change when a source updates. Do not use a subscription URL as a group name: it may contain credentials and is unsafe to quote in screenshots or logs. Order groups by how often you use them so you do not have to search the “All” view every time.

Set automatic updates based on actual needs, not as frequently as possible. First make sure manual updates work reliably, then choose a reasonable schedule. If multiple subscriptions update at the same time while the network is not ready or a source responds slowly, errors can compound. If the client allows separate schedules, stagger test and everyday sources. Otherwise, confirm the connection works after switching networks before running a bulk update.

Keep a network path available for subscription updates

Subscription updates may connect directly or go through the current proxy, depending on the client settings. If updates depend on the current server and that server has already stopped working, you have a maintenance dependency loop. Keep a recently verified working configuration as a recovery path, or update directly on a network where the source is reachable. Do not delete your last working server group before retrieving new details, and do not assume an update failure means the whole subscription is invalid.

When an update fails, first distinguish a connection timeout, an unexpected response, and a parsing error. For a timeout, check the network path; for an unexpected response, check whether the source returned subscription data; for a parsing error, check the format and the client's supported formats. An error page can arrive in a successful network response, so “request completed” does not mean the import succeeded. Keeping the original group and recording the error type is more useful than repeatedly pasting the URL. Remove credentials from the URL before sharing error details.

Deduplication takes more than comparing aliases

Two subscriptions may contain the same server, or they may use the same address with different credentials, transport, or TLS settings. Compare the complete connection parameters when deduplicating, and check what criteria the client's deduplication feature uses. Deleting by alias alone may remove entries with the same name but different settings; deleting by address alone may merge different services. Back up before cleaning up, process one group at a time, and confirm the selected server still exists afterward.

If a server in a subscription is replaced or removed, the client's current selection may stop working or switch automatically to another entry. After updating, check the selected server, routing preset, and connection status; a nonempty list does not mean the session is restored. If automatic selection depends on test results, make sure the test matches your actual use. For a stable business route, a clear manual selection process is often easier to troubleshoot than constantly reorganizing the entire list.

Migrate connection details, not the entire runtime environment

Using the same subscription URL on a computer and phone means both devices retrieve details from the same source; it does not automatically sync routing, DNS, or app coverage. When moving to v2rayNG or v2flyNG, check core support, VPN permissions, and app scope again. Desktop file paths, listening ports, and TUN templates should not be copied unchanged to another platform. Establish a basic connection on the target device first, then add any necessary advanced rules.

A complete backup is useful for restoring a similar environment; a single-node share link is suited to a temporary move; a subscription URL supports ongoing updates. Choose a method based on whether the source allows multiple devices, device limits, and update frequency. A backup may include interface settings and local paths as well as the server list; after restoring, check log directories, listening addresses, and startup options. For a detailed comparison of the three approaches, see Sharing a configuration between your computer and phone.

If a subscription URL is exposed, deleting a screenshot will not invalidate it. Use the configuration provider's management interface to rotate or revoke the URL, then update your devices. For routine maintenance, keep an operating note without credentials that records each group's purpose, filter intent, and recovery steps. That way, if you replace a device, you can rebuild the management structure without relying on memory to remember what each group does.

Custom outbounds: tags, interfaces, and connection chains

Outbound tags must refer to objects that exist in the configuration

An outbound is where the core hands a connection off for further processing. direct, block, and proxy are common tag names, but a tag is just a name in the configuration; the word alone does not create a feature. The outboundTag in a routing rule must match an actual outbound object. An outbound tagged direct will not behave differently just because of its name if it uses another protocol. When reviewing custom configuration, check the tag, protocol, and parameters together.

This snippet defines two Xray outbounds: one connects directly to the destination using the Freedom protocol, and the other rejects connections using Blackhole. It illustrates routing targets and does not include a remote proxy server. The direct outbound is first in the array, so a complete configuration with no matching routing rule may default to a direct connection. When merging this into an existing configuration, check the order again; do not overwrite the outbound array generated by the client.

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

A remote proxy outbound also requires complete server details, authentication, transport settings, and security parameters. This page does not provide a fictitious server configuration. In actual use, the client generates these details from an imported server entry, which you can reference through a supported routing or custom configuration interface. If the client generates a proxy tag automatically, do not create another object with the same name without checking first. Duplicate tags can cause errors or unpredictable selection; give each purpose a clear, unique name.

Know how many proxy hops a connection uses

Multiple outbounds listed side by side usually provide separate choices; they do not automatically form a connection chain. After routing selects an outbound, the request is generally handled by that outbound. To send a connection from one proxy outbound through another, the core must explicitly support the relevant forwarding or chaining configuration. The fields vary by core, so do not mix configuration formats. Before making changes, map the app, local inbound, first hop, next hop, and destination, and identify what each layer does.

A connection chain does not necessarily improve performance. It adds handshakes and failure points, makes troubleshooting harder, and may change where DNS resolution occurs. If the first hop is unreachable, correct settings later in the chain do not help. Verify each outbound separately before testing the combined route. In the logs, distinguish a failure to connect to a proxy server from a failure by that proxy to connect to the destination. A working TCP request does not guarantee equivalent support for UDP or other transports; test each real use case separately.

Custom local outbounds and listening scope

If you want to forward requests to another local proxy program, first check its listening address, port, and protocol. SOCKS and HTTP proxies are not interchangeable. Two programs also cannot listen on the same address-and-port combination. When connecting to a local service, prefer a loopback address. Expand the listening scope only if devices on your local network really need access, and check firewall rules and access controls too. Opening a listener does not automatically provide authentication.

Binding an outbound to a network interface or local address is useful in specific multi-network setups, but it reduces portability. The bound interface may disappear when Wi-Fi changes, Ethernet disconnects, or the system wakes from sleep. Unless you need a fixed exit and can maintain the required settings, relying on normal system routing is easier to recover. In a TUN setup, check that the binding bypasses the virtual interface to avoid sending the outbound connection back into itself. After changing interface settings, test recovery from a network disconnect—not just the current connection.

Start by adding one exact-domain rule that points a test destination to the new tag, while leaving other requests on the existing preset. Confirm that the core starts, the tag exists, the rule matches, and the request reaches its destination before expanding the scope. If the logs report an unknown outbound, check the spelling and whether the client overwrote the object. If the outbound exists but the connection times out, check the local listener, remote reachability, and transport support. A configuration that loads is only the first step; the complete request must succeed.

For everyday use, keeping a standard configuration as a recovery path matters more than maintaining a complex chain of custom connections. To add a server, first visit the client downloads page to choose a client, then use the user guide to establish a basic connection. Add a custom outbound only when the standard options cannot meet a specific need. Document the configuration intent, key tags, and rollback steps so the next change starts from a clear baseline.