V2Ray Advanced Setup Guide

Subscription Groups and Server Filters

Subscription groups organize server sources and update scope; server filters control which entries appear in a list. Neither controls traffic routing. A group can contain multiple servers, but everyday connections still use the currently active server. Switching group tabs doesn’t necessarily switch the active server. Knowing the difference prevents the mistaken assumption that seeing another group’s list means the connection has changed.

Create traceable groups

In v2rayN, open “Subscription Group” and add a group. Enter a note that identifies the source, then paste the full subscription URL. These URLs usually contain access credentials, so use the note for the source or purpose—never copy URL parameters into it. Check for leading or trailing spaces and line breaks. After saving, update only this group. For the first update, check the log and confirm the list has entries before enabling automatic updates, filters or bulk deletion.

Name groups by source and purpose, such as “Work” or “Mobile Backup.” Server aliases come from the subscription and may change on a later update, so don’t rely on manual renaming as a permanent way to organize them. For personal notes, use a dedicated client field if available, or keep a separate record. Put manually added servers in their own group to avoid confusing them with subscription entries when checking update results.

When updating, distinguish between fetching directly and fetching through a proxy. If your existing connection works but a direct update fails, try the client’s “Update subscription via proxy” option. During initial setup, with no working connection, proxy-based updates aren’t a guaranteed workaround. Check whether the error is a DNS lookup failure, connection timeout or server rejection. Repeated attempts won’t fix an expired URL and may trigger rate limits at the source.

Check the list before adding filters

Search and filters in the main window usually just narrow what’s displayed. A server filter in group settings may also affect which entries are retained during updates. Check the description of the specific setting to confirm its behavior. Before filtering, select “All,” clear the search and confirm the target entry exists. Then test one simple keyword in the intended group. Avoid stacking conditions until you know which one is excluding a server.

If the field explicitly supports regular expressions, a vertical bar separates alternatives, parentheses group expressions, and a period matches any character by default. The expression below matches entries whose aliases contain either of these two purpose words; it’s only a filter syntax example. If the field accepts plain keywords only, search for each term separately rather than entering regex symbols. Test case sensitivity against a known entry.

(Work|Backup)

If the list goes blank after an update, clear the display filter first, then check the group filter, and finally inspect what the source returned. An empty display doesn’t mean the remote subscription is empty. Preserve each server’s type, address, port and transport settings; aliases alone aren’t enough to identify duplicates. Two entries with the same name may use different transports. Before cleanup, note the active server so you don’t delete your only working test entry.

Verify and recover after updates

Server filters narrow the list by descriptive information; they don’t test connectivity or automatically select the fastest route. After an update, run “Test server real connection latency” or the equivalent speed-test option on the retained entries, then manually select an active server. Results depend on your network, test target and server status. Compare repeated tests on the same network and confirm with real-world use.

If an update replaces existing entries, the client may no longer retain the previous active selection. Select a server again, reload the configuration and check the log for a successful core startup. Don’t compare new entries against old test results: matching aliases don’t guarantee matching connection parameters. If a test fails, return to a known-working group and confirm the basic connection before troubleshooting the updated list. Don’t change routing and DNS at the same time.

Subscription menus, group displays and filter options vary between Android clients v2rayNG and v2flyNG. Don’t assume desktop regex instructions apply. Manage subscriptions by source, then select a configuration from the list. Before exporting a configuration or sharing a screenshot, remove subscription URLs, server credentials and notes that could identify an account. Treat subscription links as account credentials; don’t put them in public notes or screenshots posted for support.

Routing Rules in Practice

Routing rules determine which outbound handles connections that reach the core. They don’t automatically send all app traffic through it. The system proxy affects apps that honor proxy settings; TUN brings in more connections at the network layer. If a browser follows routing rules but another app doesn’t, first check whether that app enters the proxy path, then inspect the rules. Otherwise, you may mistake a traffic capture issue for a domain-matching problem.

Start with a preset

In v2rayN’s routing settings, note the current preset first. Then choose “Bypass mainland China (Whitelist),” “Blacklist,” or “Global” as a starting point. Preset names are just entry points; actual behavior depends on the rules, default outbound and rule sets. Global mode doesn’t necessarily override every exception, such as local addresses. To determine what will happen, inspect the generated routing configuration rather than relying on the mode name.

Rules are usually evaluated in order, and the specified outbound is used when a rule matches. Put LAN traffic and necessary explicit exceptions first, broader rule sets next, and check where unmatched traffic goes. Domain, port and network type entered in the same rule generally have to match together; they aren’t alternatives. If you want to route by domain alone, don’t add an unrelated port restriction.

This Xray-style routing snippet assumes the full configuration already has outbounds named direct and proxy. The first rule sends private addresses direct; the second routes the specified domain and its subdomains through the proxy. The example domain illustrates syntax—replace it with the specific domain used by your application. This snippet defines neither a default outbound nor connection credentials, so it can’t run on its own.

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

Domains, Addresses and Rule Sets

full: matches an exact domain. domain: matches a domain and its subdomains. geosite: references a domain rule set, and geoip: references an IP address rule set. A plain string may use keyword matching, which can match more than intended. For precise exceptions, use an exact domain; use a domain suffix only when you need to include subdomains. This helps avoid matching unrelated sites.

Domain rules require the core to know the destination domain. Apps that send a domain through the proxy can usually match it directly. Apps that resolve the name first and send only an address may require sniffing or another domain-mapping mechanism. Sniffing can’t recover domains for every protocol. If the same site matches different rules in different apps, check the target shown in the logs: one may be a domain and the other only an address. Don’t start by expanding the rule set.

AsIs doesn’t resolve the destination domain for routing matches. Other domain strategies may trigger resolution when there’s no match or when address rules require it; check the core documentation for exact behavior. Resolved addresses can also depend on cache and network location, so switching to address-based matching isn’t necessarily more reliable. Prefer domain rules for services with known domains; add address conditions only when you need to target a specific network range.

Rule set files must match the rule syntax. Use the client’s update option to fetch the required resources, then check the log to confirm they loaded successfully. An unknown set name, unreadable resource file or mismatched core can prevent startup. Don’t rename another core’s rule files and assume they’ll work. For rule set updates and common syntax, see the GeoIP and GeoSite Rule Sets Guide.

Verify with observable results

After making a change, reload the configuration and test one target site. Check the access log for the destination, matched rule or outbound tag. Existing browser connections may continue on the old path, so close the relevant tabs or restart the app before testing again. Change one rule per test. If you also update rule sets, switch servers and change DNS, you won’t know which change fixed the issue.

If a local printer, file share or intranet page stops working, check that private addresses are routed direct before broad proxy rules, then check whether another proxy layer is capturing the app. If internal domains use private DNS, confirm it returns an intranet address. When routing is correct but DNS isn’t, the connection can still go to the wrong destination. That’s why routing and DNS need to be checked together, but changed in separate rounds.

Tune DNS Settings

DNS troubleshooting starts with three questions: which component makes the query, which path does it take, and where is the result cached? The system resolver, browser Secure DNS and the proxy core’s built-in resolver may all be active at once. Changing the DNS address in the client doesn’t mean every app will use it. Map the request path before tackling timeouts, inconsistent results or failed intranet lookups; don’t blindly pile on more resolvers.

Find where resolution happens

Apps that send a domain through the proxy can leave resolution to the proxy path. Apps that resolve locally and then connect to an address have already made a DNS query before traffic reaches the core. TUN mode may also capture system DNS queries and route them to the core. Browser-level encrypted DNS can create yet another independent path. If browser and command-line results differ, check each resolver’s settings rather than assuming one is using the wrong server.

Keep the client’s default DNS setup initially and establish a baseline with a working server. Then change one thing at a time. For example, intranet names may require an organization’s internal resolver, while ordinary public lookups can use a reachable DNS service. Access to public resolvers varies by network, so no single address works everywhere. The goal is reliable paths and correct results, not the largest list of DNS servers.

This minimal example shows Xray’s built-in DNS server list and query strategy. It doesn’t include DNS interception rules or guarantee that system queries will reach this resolver. Using an IP address avoids the bootstrap problem of resolving the DNS server’s own hostname, but routing and core behavior determine whether queries go direct or through a proxy. Verify reachability on your current network before using it.

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

Domain-Specific and Bootstrap DNS

Intranet domains, public service domains and proxy server addresses may need different DNS strategies. Sending an intranet domain to a public resolver usually won’t return the expected result. If resolving a proxy server requires a proxy connection that hasn’t been established yet, startup can get stuck. First make sure the proxy server’s bootstrap lookup works independently, then configure DNS for regular traffic. Recheck this startup path whenever you change networks.

Encrypted DNS services identified by hostname require the service’s address to be resolved first. That first lookup is called bootstrap DNS. If it points to the same service that isn’t available yet, resolution can get stuck in a loop. Some clients provide a dedicated bootstrap setting; others rely on the core or system. Don’t assume the same field exists everywhere. After saving, use the logs to distinguish “couldn’t resolve the resolver’s hostname” from “failed to resolve the destination domain”—they require different fixes.

Keep DNS and routing strategies aligned. A direct connection may get an unsuitable content delivery address if DNS resolves from a location far from the current network exit. A service accessed through a proxy may also behave differently depending on where DNS resolution happens. There’s no guaranteed speed advantage either way. Compare connection setup, page resource loading and sustained access for the same service instead of judging by a single lookup time.

Choose an IPv6 strategy based on the actual network path. Having an IPv6 address on the system doesn’t mean there’s a working IPv6 route to the destination. Disabling all IPv6 isn’t a universal fix either. If logs show repeated attempts over an unreachable address family, adjust the DNS result or outbound strategy accordingly. Check system routes and network support first; hiding DNS results alone may not stop an app from resolving and choosing a different address family itself.

Caching and troubleshooting

DNS results may be cached by the system, browser and core. After changing settings, restart the affected apps and core, then test the same destination again. If needed, use the cache-clearing method provided by your system. A command-line lookup only reflects that command’s resolver path; it doesn’t necessarily match the browser or a proxied request. When comparing logs, record the destination domain and test time instead of mixing results from different cache layers.

“The domain fails, but the IP address works” is a reason to check DNS, not proof of a DNS failure. Using an IP address for HTTPS can change the certificate name, request host and server routing; many sites don’t support that test. A more reliable sequence is to confirm the lookup succeeds, check that the result makes sense, test whether the destination port is reachable, then investigate application-level errors. Keep the full error category.

Switching to address-based routing can expose a previously hidden DNS problem because connections now depend on local resolution. Restore the previous domain strategy first and verify the basic connection, then troubleshoot DNS separately. Don’t enable FakeDNS to mask the symptoms; it depends on additional mapping and interception requirements, covered below. For startup and connection issues, continue troubleshooting by category in the FAQ.

Configure TUN Mode

TUN mode uses a virtual network interface and routes to send more app connections through the proxy. It’s useful for programs that don’t honor system proxy settings. TUN expands the scope of captured traffic; it doesn’t automatically improve connection quality or force all traffic through the same outbound. Routing still decides which captured connections go direct, through a proxy or get blocked. Make sure ordinary proxy mode works before enabling TUN, so you can troubleshoot server and traffic-capture issues separately.

Permissions, Core and Capture Scope

Before enabling “Enable TUN Mode” in the v2rayN main window, check that the client has the required permissions. Windows may require elevated permissions or a service mode supported by the client. Other desktop systems may require authorization to create a network interface and change routes. Grant permissions according to your installation; repeatedly running with elevated privileges isn’t a good long-term troubleshooting method. Logs should show whether the interface and routes were created successfully.

Desktop clients may use different components to run TUN, so their fields may not match those of the regular proxy core. Check the runtime logs and generated configuration to see which component handles traffic capture and outbound connections. Don’t paste an Xray JSON snippet into a different TUN configuration format. If the interface switches modes normally but the logs report unknown fields, restore the default template first and check that the configuration matches the runtime component.

Android clients usually capture app traffic through the system VPN service; you’ll need to approve the system prompt the first time you connect. Per-app settings determine which apps are included or excluded. Check whether the list means “proxy selected apps” or “bypass selected apps.” This isn’t a field-by-field equivalent of the desktop “Enable TUN Mode” switch. Another app using the system VPN service may conflict or replace the connection.

Check loopback before routing

After TUN starts, traffic from the proxy process to its server must bypass TUN capture, or it can create a loop. Clients usually handle the necessary routes or process exclusions automatically, but custom templates, extra network adapters or another tunnel can break this assumption. Common symptoms include losing the server connection as soon as TUN starts, repeated retries in the log or timeouts for every request. Turn TUN off to restore the basic connection, then check outbound routing. Don’t widen the proxy scope further.

LAN access requires checking both routing and DNS. If public sites work but a printer or internal service doesn’t, check whether private addresses go direct, whether internal domains use the right resolver, and whether a broader capture rule overrides the LAN route. Don’t send the entire local network through a remote proxy just to test. If you need access to a remote private network, distinguish it from local address ranges to avoid ambiguous destinations when ranges overlap.

Test in three steps: open a known-working webpage, test an app that normally ignores system proxy settings, then check LAN access and internal domains. Also verify that traffic actually reaches the client instead of relying on a taskbar icon. If the system proxy is enabled too, a successful browser test may still be using the old path. After noting the original settings, you can temporarily disable the system proxy to test TUN capture on its own.

UDP, Path MTU and Restoring Network Access

An app entering TUN doesn’t guarantee that every protocol can use the current server. Voice, games and some other traffic use UDP, which must be supported by the client, core, server and network path. If webpages work but real-time apps fail, check UDP support and logs; webpage tests alone aren’t enough. Some apps also choose different transport protocols, so keep settings consistent during tests to avoid attributing a protocol change to routing.

If a few sites connect but stall when transferring large resources, the cause could be path MTU, packet loss, a protocol issue or the server. Don’t apply a fixed MTU value by default. First try a known-working server and compare behavior with TUN off, then narrow down the cause using logs and network diagnostics. Change MTU-related settings only when there’s evidence of fragmentation or a path issue, and record the original value. Otherwise, you’ll add another variable that’s hard to trace.

When finishing, turn off TUN before exiting the client, then check that regular network access and system DNS have recovered. If the problem started after waking from sleep or switching networks, rebuilding the capture setup is usually a better first step than changing configuration. If access still doesn’t recover, check for leftover interfaces, routes or another traffic-capture service. Don’t delete system routes in bulk without understanding their purpose; managed networks may rely on them.

For Android background disconnects, check battery optimization, background restrictions and per-app proxy settings rather than trying desktop network repair commands. Choose the right balance between persistent connections and battery life for your use case. See v2rayNG Background and Battery Troubleshooting. After testing, keep one stable mode and avoid starting several traffic-capture tools at boot.

How FakeDNS Mapping Works

FakeDNS assigns a synthetic address to a domain temporarily, then restores the domain when the connection reaches the core. This preserves the domain information needed for routing. The synthetic address isn’t the server’s real address or an additional encryption protocol. FakeDNS can help when an app resolves a domain first and then connects using only the address, but the proxy needs the domain to match routing rules. If ordinary DNS and routing already meet your needs, there’s no reason to enable it just to add another setting.

Queries and connections must complete the loop

The full path is: the app queries a domain, the query reaches FakeDNS, the app receives a synthetic address, the app connects to that address, and the connection returns to the core that holds the mapping. A missing step can mean “DNS returned a result, but the connection won’t work.” Make sure app queries aren’t bypassing interception and that direct-routing rules don’t let the synthetic address range through early. Configuring an address pool without a query path won’t make FakeDNS work.

This Xray-style snippet shows how the synthetic address pool, DNS server selection and inbound sniffing fit together. 198.18.0.0/15 comes from a reserved benchmarking address block, not from the public internet. The example covers IPv4 mapping only; it doesn’t show complete inbound, outbound or DNS forwarding rules. The correct place to merge these fields depends on the configuration generated by your client.

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

The inbound that restores the mapping must also have sniffing settings that recognize FakeDNS. The object below is an example of the inbound’s sniffing field, not a top-level configuration. It won’t work directly in runtimes that don’t support these fields or use a different configuration format. Confirm core support first, then check whether the client already generates equivalent settings to avoid adding them twice.

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

Address Pools, Caching and Compatibility

ipPool defines the synthetic address range available for assignment, and poolSize sets the mapping capacity. Keep the pool separate from your actual network and other tunnels; don’t replace it with a LAN range that’s already in use. Even the default reserved range can conflict with a test environment or another networking product. If there’s a conflict, check address ownership and routes instead of changing one field and assuming the whole path has moved.

Mappings are valid only for the relevant core and its lifetime. After a core restart, an app may still have a cached synthetic address while the new instance has no record for its domain. DNS may appear to work, but the connection then fails. When switching modes, restart affected apps and clear DNS caches if needed, then test with a fresh domain lookup. Long-running background apps are especially likely to keep stale mappings.

Not every app accepts synthetic addresses. Some check whether an address is publicly routable; others pass the result to another process or device; some use a hard-coded IP address. The first two cases can break the mapping loop, while hard-coded addresses have no domain to restore in the first place. If only one app fails, try ordinary DNS or a different capture method for that app instead of expanding the address pool. More capacity won’t fix compatibility problems.

When a browser uses its own encrypted DNS, queries may bypass local FakeDNS, so the connection won’t have a mapping. Conversely, other devices usually can’t use synthetic results shared from a machine that runs a different capture path—or none at all. Don’t distribute the host’s FakeDNS results as regular LAN DNS, and don’t copy synthetic addresses into static server configurations.

Coordinate with routing, DNS and recovery

After FakeDNS restores the domain, routing still has to select the right outbound. The connection may also need to resolve the real address or pass the domain to a remote server. FakeDNS doesn’t eliminate every need for ordinary DNS. Keep a working bootstrap lookup for the proxy server in particular. Otherwise, the server may be assigned a synthetic address that can only be resolved through a tunnel that hasn’t started yet, creating a startup dependency.

For a test, close the app, start a configuration that supports mapping, then open the app and visit a known domain. Check whether the query reaches FakeDNS, whether the connection targets an address in the pool, and whether the core restores the domain and matches the expected rule. If the query never reaches FakeDNS, check DNS interception. If a synthetic address is returned but the connection doesn’t enter the core, check routing. If the connection enters but the domain isn’t restored, check sniffing and mapping state.

To roll back, restore ordinary DNS, undo dedicated interception changes and clear caches in apps that used synthetic results. Disabling the address pool alone may leave processes trying to connect to old synthetic addresses. After rollback, test the basic connection with ordinary DNS before deciding whether to re-enable FakeDNS. Keeping the original DNS and routing settings lets you limit recovery to those layers instead of rebuilding the entire subscription configuration.

Managing Multiple Subscriptions

Managing multiple subscriptions is about keeping sources separate, updates under control and switching verifiable—not combining every server into one huge list. Create separate groups for your primary subscription, backup and temporary tests so each entry has a traceable source. As subscriptions grow, keep the relationships clear: which group is for everyday use, which is only for outages, which entries can be replaced by updates and which need to be retained manually.

Update by source, choose by purpose

Create a separate group for each source and use clear notes to identify its purpose and update method. Don’t duplicate the same subscription URL across groups just to organize by purpose; that creates extra update requests and duplicate entries. If you need different views of the same source, first check the client’s filter options. Keeping source groups stable and finding entries with search or supported filters is usually easier to maintain than importing duplicates.

When adding a backup subscription, update only that group first. Confirm the log shows success and the list looks right, then test a real connection. Don’t immediately replace the primary server or bulk-update other sources. If the subscription returns no entries or the new configuration won’t start, the impact stays contained. Clients handle failed updates and empty results differently. Back up important manual settings separately instead of relying on an update to preserve them.

Set automatic update intervals to match how often each source actually changes; frequent requests don’t keep a subscription fresher. Sleep, network changes or a proxy that hasn’t started can all cause automatic updates to fail. When troubleshooting, check the last successful update in the log instead of relying on the automatic update toggle. For subscriptions fetched through a proxy, note which existing connection they depend on so a primary connection outage doesn’t also prevent the backup list from refreshing.

Deduplication and Active Server Management

When checking for duplicates, compare connection parameters—not just aliases. The same address and port can use different IDs, transport paths, service names or TLS parameters, so don’t merge entries casually. Before using the client’s deduplication feature, find out which fields it compares and make sure you can undo the change. For servers with similar names, keep them separate by source first. Remove entries only after confirming they’re identical, so you don’t discard a working backup configuration.

Subscription updates may reorder entries or replace their internal IDs. Selecting a server by its position in the list can lead to mistakes, so check its current alias and source before connecting. Real connection test results may also stop matching after an update; don’t use old results to rank new entries. If an update changes the primary subscription’s parameters, test the server again, set it as active, reload and verify access in the apps you use.

A backup subscription doesn’t mean automatic failover. The active server selection usually uses one current outbound. Switching based on health checks, selection rules or load balancing requires explicit support and configuration. Don’t assume that having multiple sources means one will take over automatically. For most everyday setups, a verified backup path and clear manual switching steps are easier to recover than complex automation.

Backups, Migration and Sensitive Information

Back up subscription groups, essential manually added servers, custom routing rules and DNS settings. Check exactly what the client’s export includes; exporting server links alone may omit routing and app preferences. Backup files may contain subscription credentials and server keys, so store them securely. Before moving to another device, confirm the target client supports the protocol and transport. A successful import doesn’t prove the configuration is compatible.

Don’t copy the entire configuration between desktop v2rayN and Android v2rayNG or v2flyNG. Server share formats may be compatible, but per-app proxy settings, system proxy, TUN capture and local file paths depend on the platform. During migration, import the servers first, then configure traffic capture and routing for the target platform. Recheck Android background settings too; don’t assume a setup that worked on one device will behave the same on another.

If a subscription URL stops working, distinguish expired access from a changed URL or a temporary network error. For access issues, get a valid URL from the original source and replace it in the existing group. For network timeouts, check the current connection and update path first. Don’t leave an invalid URL in the automatic update queue. After replacing it, remove old records and screenshots containing credentials so the link doesn’t remain in synced notes, clipboard history or public support posts.

After changing networks, test the primary server first, then the backup source; don’t reinstall the client right away. If both sources fail at the same stage, investigate local ports, DNS or traffic capture. If only one fails, focus on that source’s settings. For a startup log reporting a port conflict, see How to Diagnose a Local Port Conflict rather than deleting every subscription to fix an unrelated problem.

Custom Outbounds and Configuration Validation

An outbound describes how the core sends a connection to its next hop; routing rules select an outbound by its tag. Direct, blocked and proxied connections are different outbound behaviors, not different subscription groups. Clients usually generate a proxy outbound for the selected server, along with supporting outbounds. Consider custom configuration only when the interface can’t express what you need. For everyday server changes or domain exceptions, prefer the existing server and routing settings.

Tags and Routing References

tag is an internal configuration identifier and must match the rule’s outboundTag. A tag name has no built-in magic: naming an outbound direct doesn’t make it direct. The protocol and its parameters determine what it does. When troubleshooting, check that the tag exists, isn’t duplicated and uses the right protocol. A spelling mismatch may prevent a rule from finding its target, and the client log often points to the issue.

This complete local Xray SOCKS direct-connection configuration is for understanding how inbounds, rules and outbounds fit together; it doesn’t provide a remote proxy connection. Before starting it, stop any other instance using the same listening port and confirm it’s accessible only from this machine. All incoming connections are explicitly sent through the direct outbound, so this can’t test a remote server and isn’t a replacement for an existing subscription.

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

The example binds to a loopback address to avoid exposing an unauthenticated local proxy to other devices. Binding to all interfaces changes the access boundary and may let devices on the same network use the port. If you need LAN access, design access controls, authentication and firewall rules separately; changing the listen address alone isn’t enough. Confirm port availability against what’s actually in use on your machine.

Client-Generated and Custom Files

For servers managed through the GUI, the client usually generates the runtime configuration. Editing a temporary generated file directly can be undone when you reload or switch servers. Put persistent rules in a custom configuration field supported by the client. With a fully custom configuration, be clear about which functions are no longer controlled by the regular server settings. Don’t edit both generated output and GUI fields and expect them to stay in sync.

When creating a proxy outbound, use an actual configuration for the address, port, user credentials, transport and security parameters; don’t guess missing values. The same protocol name doesn’t guarantee the same transport path, service name or certificate settings. First verify the connection using the regular server configuration, then consider moving it into a custom structure. This separates connection parameter issues from outbound reference issues and keeps troubleshooting focused.

Multiple outbounds don’t automatically chain connections. A rule that selects a backup outbound chooses a route based on conditions. Having one proxy outbound connect through another is a chain and depends on specific core features and fields. You can’t achieve the same result just by rearranging the outbound array. Chaining also adds startup dependencies, latency and failure points. Verify each hop independently, then check for circular references.

Don’t overlook the default outbound. Some configurations use the first outbound when no rule matches; other runtimes have an explicit final outbound field. Before inserting a new outbound into a list, confirm where unmatched traffic will go. The example explicitly maps the inbound tag to an outbound to avoid relying on list position. During migration, check the order of client-generated and custom rules so earlier rules don’t prevent later ones from ever matching.

Layered Testing and Recovery Baseline

Test in this order: confirm the configuration loads, the local inbound can listen, the outbound can connect, and the app traffic matches the intended route. Valid syntax only addresses part of the first step; unknown fields, missing rule sets and nonexistent tags can all cause startup failures. When the log reports an error, keep the original message and note where it comes from in the configuration. Don’t change several parameters in response to a generic warning.

If the local port accepts connections but the app still fails, check whether the intended outbound is actually selected, then investigate DNS, the remote connection and the app protocol. For proxy testing, make sure the test tool points to the correct local protocol and port. Don’t use an HTTP proxy port as a SOCKS port. Client versions and runtime modes can change the listening setup; check the status bar and current settings instead of relying on port numbers from an old guide.

Temporarily increasing log detail can help identify outbound selection, but logs may contain destination domains, server addresses and usage patterns. Restore the normal log level once troubleshooting is complete, and remove sensitive fields before sharing logs. If the configuration remains unstable, return to a verified regular server, default routing and basic DNS. Confirm the connection works, then reintroduce custom settings one at a time. Keep a working baseline backup, not just the latest edited version.