Subscription Groups, Routing, DNS, and TUN Configuration

1. Subscription Groups and Server Filtering

Subscription groups answer “where does the configuration come from?”, while server filters answer “what appears in the list?” Configure them separately: groups manage sources, while filters only change what is visible and should not be used to delete configurations.

Set clear group boundaries

When importing multiple subscriptions into v2rayN, create a separate group for each source instead of leaving every server piled into the default group. Group names should describe a purpose or source, such as “Daily,” “Office Testing,” or “Manual Config,” rather than a region name that may change. Region, protocol, and route labels are better handled by filter rules. This way, changing a subscription URL does not invalidate existing routing and filtering logic tied to the name.

After adding a subscription, update that group once manually and check whether configurations appear. Enable automatic updates only after the result looks correct. If the update returns nothing, do not delete the old group immediately. Check that the subscription URL is complete, that exclusion rules are not enabled for the current group, and whether the update request needs to use the current system proxy. For a more complete sequence, see the subscription update failure checklist. Keeping the old data until the new data is verified prevents a bad update from overwriting a usable configuration.

Put manually added VMess, VLESS, Trojan, or Shadowsocks configurations in a separate group. Subscription updates generally rebuild the list from the remote content, so mixing manual entries with subscription entries makes it difficult to tell where a record came from after an update. A separate group also makes exporting, migrating, and checking transport parameters one by one easier.

Include, Exclude, and Regex Filters

Filters usually provide two types of conditions: “include keywords” and “exclude keywords.” Include conditions narrow the candidate set; exclude conditions remove known unwanted labels. Set exclusions first, then add include conditions gradually. When both are present, only records that match an include condition without matching an exclusion are normally shown. Filtering applies to remarks or labels supplied by the subscription; it does not verify a server’s actual location, protocol capabilities, or availability.

Use ordinary keywords for simple cases. When several terms should mean “any one of these,” use the vertical bar in a regular expression, such as home|office. Use ^ to match the beginning and $ to match the end. Parentheses, dots, and plus signs have special meanings in regex; escape them when matching the literal characters. Check the result count and the first and last records immediately after saving to make sure the expression is not too broad.

Include: ^(Home|Office).*(VLESS|Trojan)$
Exclude: Test|Expired|Maintenance
Note: Show only records that start with “Home” or “Office” and end with one of the specified protocol labels

If the filtered list is empty, troubleshoot in three stages. First, clear all filters temporarily and confirm that the original list contains entries. Second, keep only one ordinary keyword and verify that the remark field actually contains it. Only then restore the regex and add the expression piece by piece. Do not change the subscription URL, group, and regex at the same time, or you will not know which change caused the result.

Sorting, Selection, and Stability After Updates

Server sorting only changes the display order; it does not determine routing priority. After sorting by remark, address, or protocol, the selected server is still controlled by the client state. A subscription update may reorder the list or rebuild record identifiers, so do not use “the server on row N” as a long-term selection criterion. Clear remarks, fixed groups, and repeatable filter rules are more reliable.

After grouping the subscriptions, check each group’s update method, automatic update switch, and filter conditions separately. Enable scheduled updates for groups used regularly; temporary test groups are better updated manually so remote changes do not interrupt comparison tests. If the server count changes sharply before or after an update, check the client log and filter results before switching the active configuration.

2. Routing Rules in Practice and Match Order

Routing rules send connections to different outbounds. The result depends on the destination information, rule order, and outbound tags. Define the policy first, then write the syntax.

Understand top-to-bottom matching

A routing engine generally checks rules from top to bottom. The first rule whose conditions are satisfied determines the outbound, and later rules are ignored. Put specific rules first, broad rules later, and keep a clear default policy at the end. For example, direct connections for private network addresses should come before broad proxy rules; direct or blocking rules for specific domains should also precede category sets. A very broad rule at the top prevents later, more specific rules from taking effect even when their syntax is correct.

Common match targets include domains, IP addresses, ports, network types, and processes. Domain rules can use full domains, suffixes, keywords, or geosite categories; IP rules can use individual addresses, CIDR ranges, or geoip categories. A port describes only the destination port and cannot identify the application type. Process matching depends on the operating system and whether the client can obtain process information, so it should not be the sole condition when moving configurations across platforms.

A clear baseline order

Start basic traffic routing with three layers. First handle private addresses so printers, routers, and local network services do not go through a remote outbound. Next handle explicit domain categories. Finally set the default proxy outbound. Avoid adding large rule sets from unknown sources all at once. The more rules you have, the harder priority conflicts are to locate and the harder resource updates are to manage.

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:geolocation-!cn"],
        "outboundTag": "proxy"
      }
    ]
  }
}

domainStrategy determines whether to continue resolving an IP when a domain rule does not match. With IPIfNonMatch, routing first tries domain rules, then obtains an address through DNS and checks IP rules if nothing matched. This works well with configurations that use both geosite and geoip. If you choose domain-only matching, rules that depend on the destination IP may not run; resolving every domain in advance increases DNS queries and changes connection timing.

How to find an ineffective rule

First confirm whether the actual target is a domain or an already resolved IP. Browsers usually submit a domain, while some applications resolve it themselves and connect directly to the IP, leaving domain rules with no original name to inspect. Next verify that the outbound tag selected by the rule exists. When tags are case-sensitive, proxy and Proxy are different targets. Then check rule order, especially for broad rules at the top that cover every port, network, or a large set of domains.

When testing a single rule, temporarily narrow its conditions. For example, replace a category rule with one full domain, raise the log level enough to observe the routing decision, create a new connection, and confirm the selected outbound. Existing connections may reuse an old path, so close the relevant application connections or restart the client core after changing rules. Refreshing a page alone may not create a new connection.

UDP and TCP can use different rules, but application behavior must be understood. Domain resolution usually involves UDP and may fall back to TCP; real-time communications may also use multiple destination ports. If only TCP is allowed through a particular outbound, related UDP requests may follow the default rule, producing the familiar “the page opens, but some features fail” result. During troubleshooting, observe the network type, destination port, and final outbound together instead of looking only at the domain.

3. DNS Optimization and Query Paths

DNS configuration is more than entering server addresses. It must answer three questions: who makes the query, which outbound carries it, and how the response participates in routing.

Distinguish system and core resolution

In system proxy mode, some applications call the system DNS themselves and pass the resolved IP to the proxy; others pass the domain directly to the proxy client. The two request types carry different information into the core. The former may contain only an IP, leaving routing dependent on geoip or network-range rules; the latter preserves the domain and can use geosite, suffix, and full-domain rules first. If the same site uses different outbounds in different applications, first check whether resolution happens in the application or in the core.

TUN mode can capture more system traffic and make the DNS path more consistent, but it can still create competition among system DNS, TUN DNS, and browser-native resolution. The goal is not to send every query to the same server, but to keep query results consistent with routing policy. If routing by domain category is planned, preserve domain information where possible; if routing by destination IP, make sure the resolution results used for decisions are stable and reachable.

Server types and match conditions

DNS servers can be grouped by domain conditions. Queries for domains that should go direct can use a resolver reachable from the local network, while other queries can travel through a proxy outbound. Make clear how the server address itself will be resolved and reached. If an encrypted DNS hostname requires another DNS lookup, provide a reachable bootstrap resolver; otherwise the configuration creates a circular dependency.

queryStrategy controls whether IPv4, IPv6, or both are returned. Choose based on the current network and the actual reachability of the target service. Returning IPv4 only can reduce uncertain branches on dual-stack networks, but it excludes IPv6-only targets; returning both requires the system routes and outbound paths to handle dual-stack traffic correctly. Do not disable one address family merely because the logs show the other; first test whether the local network provides a stable connection.

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

expectIPs checks whether response addresses match the expected category. It does not force results to a particular region; when a response fails the condition, the resolver can try another candidate server. skipFallback excludes a server from ordinary fallback, which is useful for a resolver dedicated to a specific domain set. Supported fields depend on the core configuration format in use, so inspect the complete configuration generated by v2rayN and the startup log before importing custom fragments.

Distinguishing cache, fallback, and poisoned-DNS errors

If results do not change immediately after editing DNS, the browser, system, client core, or upstream resolver may still have cached data. Close existing connections in the test application first, then restart the core; clear the system DNS cache if necessary. Do not refresh the same page repeatedly and judge the new configuration from one result, because connection pools and caches may bypass it.

Resolution failures generally fall into four categories: timeouts, empty responses, unreachable addresses, and mismatched response types. For timeouts, check the outbound and firewall used by DNS requests; for empty responses, verify the domain and query type; for unreachable addresses, inspect the routing table and target network; for mismatched types, check queryStrategy. If the log shows successful resolution but a failed connection, the problem has usually moved from DNS to routing, the outbound, or the transport layer.

When evaluating DNS, test at least three types of targets: a domain explicitly routed direct, a domain explicitly routed through a proxy, and a test target that provides only a particular address family. Record the resolution result, matched rule, and final outbound for each. Testing only one frequently used site cannot prove that fallback order and boundary conditions are correct.

4. TUN Mode: Capture Scope and System Routing

The system proxy affects only applications that actively read proxy settings; TUN mode captures a broader range of traffic through a virtual network interface. They are not simply stronger and weaker versions of the same feature, but different integration methods.

When should TUN be enabled?

When browsers, download tools, and most desktop applications can read the system proxy, use the system proxy first: the path is shorter and it is easier to disable for individual applications. Consider TUN only for game launchers, command-line programs, some store components, or applications that ignore the system proxy and connect directly. Before enabling it, confirm that the ordinary system proxy already works; adding a virtual adapter and route table before validating the basic path only expands the troubleshooting surface.

After TUN starts, the client creates a virtual interface and writes system routes according to its settings. Traffic reaches the virtual interface first, then the core determines the route and outbound. DNS may also be redirected to the core. When closing the client, the original routes should be restored. An abnormal exit can leave a temporary interface or route state behind, making the network appear broken even after the client is closed. Restart the client and shut down TUN normally before checking the system network settings.

What common parameters mean

stack specifies the network stack implementation used by TUN. Implementations differ in their handling of TCP, UDP, dual-stack traffic, and system compatibility. Normally keep the client’s recommended value, switching only when testing a specific application that cannot connect, abnormal UDP behavior, or high load. Fully restart the core after changing the network stack; existing connections will not migrate automatically.

autoRoute automatically adds routes so target traffic enters the virtual interface. When disabled, system routes must be maintained manually; this suits environments with a known network topology, not first-time setups. strictRoute more strictly limits bypass paths. It can keep more traffic inside TUN, but may affect LAN discovery, virtual machines, or other networking tools. mtu controls the maximum transmission unit of a packet. A value that is too large can cause fragmentation or packet loss on some links, while a value that is too small adds overhead.

LANs, virtual machines, and other networking tools

If the router admin page, network storage, or printer becomes unreachable after enabling TUN, first confirm that geoip:private is routed directly and check whether strict routing is blocking the local subnet. A LAN may use an uncommon private range, so do not rely only on category data; add a CIDR direct rule for the actual range when needed, such as 192.168.50.0/24. The rule must come before the default proxy rule.

Virtual machines, containers, and enterprise network clients can also write to the route table. When several tools are enabled at once, the system may choose different interfaces based on prefix length and metric. Do not toggle everything repeatedly and hope for the best. Record the route-table differences before and after starting TUN, disable other software that modifies the network stack, and verify whether TUN works alone. If it does, restore the other components one by one.

After sleep and wake, switching from wired to wireless, or moving from a home network to an office network, the original interface index may change. If connections stall, disable TUN, wait for the virtual interface to exit, and enable it again. If the client continues reporting interface-creation failures, check permissions, the state of the system networking components, and whether a leftover interface with the same name exists.

5. How FakeDNS Works and Where It Fits

FakeDNS temporarily assigns reserved addresses to domains, allowing connections that carry only a destination IP to recover the original domain. Its main purpose is to preserve domain information lost when an application resolves a name itself.

From query to connection mapping

With FakeDNS enabled, an intercepted DNS query does not immediately return the real destination address to the application. Instead, it returns a temporary address from a dedicated pool. The application then connects to that address; the core uses the mapping table to recover the original domain before applying domain routing and performing the real resolution. This makes domain rules more reliable in TUN scenarios: even if the application resolves first and connects by IP, the core can still identify the original name.

A temporary address is meaningful only while its current mapping is valid. Do not treat it as the real server address, save it, share it, or put it in long-term rules. If an application caches the result longer than the core keeps the mapping, the connection may fail. Restarting the application or clearing its DNS cache usually creates a new mapping. After the client core restarts, an old temporary address may no longer map to the original domain.

Address pools and excluded domains

The FakeDNS address pool must not overlap with the current LAN, virtual-machine, container, or other tunnel address ranges. With an overlap, the system may send temporary addresses through the wrong interface, and the logs may not even show the connection entering the core. Before choosing a pool, inspect the local route table and common network environments rather than checking only the current Wi-Fi network.

Not every domain belongs in FakeDNS. Names for LAN devices, internal corporate domains, names that must be handled by a particular system resolver, and applications that use the real IP for local decisions may be added as exceptions. Keep the exception list precise, preferably using full domains or explicit suffixes. Excluding an overly broad category weakens FakeDNS’s ability to restore domain information.

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

198.18.0.0/15 is often used for benchmark networks and should not be interpreted as the location of any real target. Confirm before configuring it that the range is not already used by a virtual network. poolSize determines how many mappings can be maintained; everyday desktop use normally does not require enlarging it blindly. A larger pool does not speed up an individual lookup and can make conflicts harder to inspect.

How FakeDNS relates to real DNS, sniffing, and routing

FakeDNS does not replace real DNS. It first returns a temporary address to the application; the core still needs the real destination address when preparing the connection. The resolver, query strategy, and outbound path used for real resolution are still determined by DNS configuration. If real resolution times out, the application may simply appear unable to connect to the temporary address, so inspect both the FakeDNS mapping and subsequent resolution logs.

Protocol sniffing can also recover domains from some traffic, such as host information in a TLS handshake or HTTP request, but it depends on identifiable fields being present. FakeDNS restores the domain through a mapping before the connection is established; the two features operate at different stages. Enabling one does not mean the other must be enabled. Base the configuration on the information actually missing from the logs instead of turning on every related option.

To determine whether FakeDNS is useful, choose a clear domain rule and observe a TUN connection without FakeDNS to see whether it can match only IP rules. Then enable FakeDNS, clear the application cache, create a new connection, and check whether the log recovers the domain and reaches the expected outbound. If domains already reach the core reliably, the benefit of adding FakeDNS is limited.

6. Multi-Subscription Management and Update Governance

The goal of multi-subscription management is not to import more addresses, but to make updates, filtering, switching, and rollback traceable. Every subscription should have a separate boundary and a clear purpose.

Separate naming, updates, and responsibilities

Subscription names should include a purpose and source category, such as “Daily Primary,” “Temporary Test,” or “Manual Archive.” Do not put the update time in the name; it becomes stale quickly and makes automated filtering harder. If one source provides subscriptions for different protocols or purposes, import them separately so each group can be updated and disabled independently.

Do not use the same short automatic-update interval for every group. Update the primary group on a stable schedule, trigger test groups manually, and disable automatic updates for groups that are temporarily unused while retaining their URLs. During an update, the client must reach the subscription URL. If that request depends on the current proxy, confirm that “use proxy when updating subscriptions,” or the equivalent option, matches the current network. If the current server is unavailable, using it to update the subscription can create a loop, so keep a path that can reach the update URL directly or retain an old configuration that can be restored manually.

Before running a batch update, update one group alone and observe the result. Check more than the success message: verify that the record count is not unusual, remarks have not changed unexpectedly, protocol fields are complete, and filters still match. When a remote subscription format changes, the client may download it successfully but produce an empty parsed result. Successfully fetching content and successfully generating a server list are not the same thing.

Deduplication and conflict handling

Different subscriptions may contain records with the same address, port, and protocol but different remarks, or the same remark with different transport parameters. Deduplicating by remark alone can delete valid configurations; deduplicating by address alone ignores the port, user identity, transport layer, and security parameters. For long-term management, treat the protocol, address, port, identity fields, transport method, and security settings as one configuration fingerprint, comparing the fields actually displayed by the client one by one.

When duplicate records appear, do not delete a source immediately. First decide which group owns long-term updates and whether the other is only a temporary backup. Deleting one record may not survive the next subscription update; the proper control point is usually group filtering or the subscription source. For remark conflicts, use group prefixes where the client allows it instead of changing core parameters generated by the remote source.

Safe rollback and migration

Before changing a subscription source or applying broad filters, export the current client configuration and routing settings. Store the export in a controlled location because it may contain subscription URLs and server credentials and should not be shared publicly. During recovery, import it into a new group rather than overwriting the active group. After verifying connections, routing, and DNS, disable the old source.

When migrating between devices, distinguish server configuration from client preferences. Server links usually do not include the system proxy mode, TUN parameters, routing rules, DNS, auto-start, or interface filters. Importing a subscription alone does not reproduce the full working environment. Use a migration checklist covering subscription groups, the active server, routing rules, DNS, TUN, automatic-update intervals, and custom outbounds.

v2rayN suits Windows, macOS, and Linux desktops; on Android, use v2rayNG or choose v2flyNG according to core requirements. Menu structures and importable fields differ between clients. When migrating routing, convert it to rule expressions supported by the target client instead of assuming the entire desktop configuration can be reused unchanged. Client entry points and platform notes are available on the download page.

7. Custom Outbounds and Chained Routing

Outbounds define how a connection ultimately leaves the core. Common tags include proxy, direct, and block. The essentials of a custom outbound are unique tags, consistent references, and no loops.

Outbound tags and routing references

Each outbound is referenced by routing rules through its tag. Use short, stable English names such as proxy, direct, block, or dns-out. After changing a tag, update every routing rule, DNS outbound reference, chained-proxy setting, and traffic policy that uses it. A startup-log message saying an outbound cannot be found usually means the spelling is inconsistent or a configuration merge overwrote the tag.

A direct outbound establishes connections through the local network; a block outbound explicitly rejects matching traffic. Keep block rules precise and begin testing with a full domain or specific port. A range that is too broad makes ordinary connections appear unresponsive instead of producing a clear error. Proxy outbounds are usually generated from the active server configuration; when editing manually, do not omit transport, security, or identity fields.

{
  "outbounds": [
    {
      "protocol": "freedom",
      "tag": "direct",
      "settings": {
        "domainStrategy": "UseIP"
      }
    },
    {
      "protocol": "blackhole",
      "tag": "block",
      "settings": {
        "response": {
          "type": "none"
        }
      }
    }
  ]
}

The domainStrategy of a freedom outbound determines how domains are handled during direct connection setup. If routing has already resolved the domain, the outbound may use the resulting address directly; if the domain is still retained, the outbound resolves it according to the strategy. Coordinate this setting with global DNS and routing policies to avoid inconsistent results for the same domain at different stages.

Practical uses for custom outbounds

A separate direct outbound can bind to a specific interface or address for multi-NIC environments; a separate block outbound can handle destinations that are explicitly unwanted; a DNS-only outbound can send resolution requests through a designated path. For every additional outbound, document its entry rule, dependencies, and fallback behavior. An outbound with no routing reference does not participate in connections automatically.

When binding across multiple network interfaces, confirm that the selected source address belongs to the active interface. After a network change, an old address may become invalid, causing only the bound outbound to fail. Devices that move between networks frequently should not pin a source address that changes easily. Let system routing choose the exit when possible, and bind an interface only when isolation is genuinely required.

Chained outbounds and loop risks

Chained proxying means that one outbound establishes its connection through another. It suits environments with a clear upstream relationship, but adds handshake, resolution, and failure points. Verify each segment independently before combining the chain. If the base outbound is unstable, chaining only makes the error harder to identify.

A chain must not form a closed loop. For example, if A connects through B while B’s connection is routed back through A, recursion continues until failure. Prevent loops by creating precise direct or designated-outbound rules for the upstream server address and placing them before ordinary proxy rules. If the upstream address is a domain, also determine which outbound carries its DNS query.

When testing a chained outbound, first inspect the connection order in the log, then confirm which rules match the target request and the upstream connection. Do not judge correctness only by whether the final page opens; the system may have bypassed the intended chain through the default outbound. Temporarily disabling the default fallback can reveal omissions, but restore a controlled fallback policy when testing is complete.

Before creating a complete custom configuration, keep the configuration generated automatically by v2rayN as a reference. Export the generated result, locate the outbounds, routing, and dns sections, and add the new tag with minimal changes. After saving, check the core startup log to confirm successful parsing. If startup fails, remove the most recently added section first instead of rewriting the entire structure.

8. Configuration Verification, Log Reading, and Rollback

After completing an advanced configuration, use layered tests to prove that each part works. Test in order: configuration loading, resolution, routing, outbound selection, and system traffic capture.

First confirm that the core accepts the configuration

Saving settings does not mean the core is already using the new configuration. First inspect the startup log and confirm that the configuration parses, ports do not conflict, referenced outbound tags exist, and resource files can be read. Syntax errors usually identify a field or nearby structure. When an error appears, revert from the most recent change, paying particular attention to JSON commas, array and object nesting, tag spelling, and unsupported fields.

After the core starts successfully, confirm that the local listening port matches the system proxy target. If the client reports that it is running but applications cannot connect, the system proxy may still point to an old port or another program may have claimed the listening address. TUN mode also requires checking that the virtual interface was created, routes were written, and DNS capture did not fail.

Test in layers; do not use one result as proof of everything

Layer one tests the subscription and server configuration: select a known-working record and temporarily use minimal routing. Layer two tests DNS: query a direct domain and a proxied domain separately, recording the response type and resolver. Layer three tests routing: add a temporary rule for one full domain and confirm the match in the log. Layer four tests system capture: use the system proxy first, then enable TUN. Add the next layer only after the current one passes.

A latency test shows only whether a particular probe received a response at that moment; it does not replace a real connection test. Some servers accept the actual protocol connection without responding to a simple probe, while others respond to the probe but fail for the target connection. Evaluate the configuration using core logs, connection establishment, and application behavior rather than a single list status.

Create a new connection after changing rules. Browser connection pools, DNS caches, and background application processes may continue using an old path. A reliable test is to close the test application, wait for connections to release, and reopen it; restart the core if necessary. If the problem appears only after sleep and wake or a network change, include that state transition in the reproduction steps.

Build a minimal working configuration

A minimal configuration contains one working server, one proxy outbound, one direct outbound, a direct rule for private addresses, and an explicit default policy. Use a simple reachable DNS server and leave FakeDNS, chained outbounds, and complex process rules disabled for now. Once the minimal configuration works, restore items one at a time in this order: subscription filtering, domain routing, conditional DNS, TUN, FakeDNS, and custom outbounds.

For every restored item, record the change, test target, and result. Configuration notes do not need authentication fields; record only switches, tags, and rule order. This makes it possible to tell whether a later problem comes from a core-version behavior change, a system network change, or a local rule adjustment.

Verification checklist
1. The core startup log shows no configuration parsing errors
2. The active server and local listening port are correct
3. DNS queries return the expected address type
4. The test domain matches the expected routing rule
5. The target connection uses the correct outbound
6. The network recovers after the system proxy is disabled
7. The virtual interface and temporary routes disappear after TUN is disabled

Where to look for common symptoms

If no applications can connect, start with the core, listening port, and server configuration. If only one application fails, check whether it reads the system proxy, resolves DNS itself, or uses UDP. If only LAN access fails, check direct rules for private ranges and strict routing. If a domain rule does not match, check whether the application submits only an IP and whether FakeDNS or sniffing can recover the domain. If a subscription update succeeds but the list is empty, check the parsed result and group filters.

If the logs do not provide enough detail, temporarily increase the log level, reproduce the issue once, record a complete connection, and restore the normal level. Keeping verbose logs enabled permanently increases file size and can bury important errors under routine entries. Before sharing logs, remove subscription URLs, user identifiers, server authentication parameters, and local file paths.

If the cause is still unclear, consult the FAQ Troubleshooting, then use the v2rayN main window overview to confirm where settings are located. Differences between protocol fields are covered in the VMess, VLESS, Trojan, and Shadowsocks comparison. When reporting an issue, include the operating system, client name, capture mode, reproduction steps, and a sanitized error log instead of writing only “it doesn’t work.”