v2rayN Multiple Subscription Groups: Filter Servers by Keywords and Sort Groups

First, separate subscriptions, groups, servers, and routing

The most common mistake in multi-subscription management is treating subscription groups as network traffic groups. A subscription is an address used to retrieve server information; a subscription group stores that address's name, update schedule, filters, and sort value; servers are the VMess, VLESS, and other configurations generated during an update; routing rules decide whether a domain or IP uses the proxy, a direct connection, or a block after a connection is initiated. These four components operate at different stages and cannot replace one another.

For example, both a company subscription and a personal subscription may contain a server named “Hong Kong 01.” If they are imported into one combined list, the server remark alone makes the source hard to identify. Put them in separate groups such as “Work Routes” and “Personal Routes.” Even when server names match, you can switch, update, or troubleshoot each group without deleting the other subscription.

The figures above illustrate a reproducible cleanup scenario: three subscriptions contain about 180 entries in total, including possible plan-expiration notices, remaining-traffic messages, and announcements. After keeping selected regions and removing notice entries, the daily list can usually be reduced to a few dozen candidates. A shorter list does not improve server quality, but it substantially reduces mistaken selections and repeated testing.

Create a separate group for each subscription

The steps below use the v2rayN 7.x desktop interface as a reference. Open the top menu “Subscription groups” → “Subscription group settings,” then choose Add in the group window. Some minor versions may label the entry “Subscription settings,” but you need the editor containing the remark, address, enabled state, update interval, filter, and sort fields—not the server editor.

Give the first subscription a purpose-based name, such as “Work-Asia,” “Personal-Low Latency,” or “Backup-Long-Term.” Avoid generic names like “Subscription 1,” since the name will appear repeatedly in the main-list filter and update menus. Paste the complete subscription URL, make sure “Enabled” is selected, save, and run an update for the current group once.

1. Open “Subscription groups” → “Subscription group settings,” then choose Add group.
2. Enter a recognizable remark; each subscription should have exactly one group record.
3. Paste the subscription URL, set the automatic update interval, and enter a sort value.
4. Save, return to the main window, and run “Subscription groups” → “Update current subscription.”
5. Switch groups in the server list and confirm that the new entries belong to the correct source.

Saving a group only records its configuration; it does not write servers to the main list. After creating a group, you must run an update manually. When the update finishes, check the status bar or log for added, updated, and removed counts, then return to the main list and view the group. If the result is zero entries, do not repeatedly retry. First check that the URL is complete, that the filters did not exclude every name, and that the system clock is correct.

Keep servers by regional keyword

Build filters from the actual spelling used in server remarks rather than guessing from regional names. Temporarily disable filtering and run an update to see whether the subscription uses “Hong Kong,” “HK,” “HKG,” or another format. Record the common names before writing the include rule; this avoids an empty list caused by naming differences.

Multiple keywords can usually be separated with a regex vertical bar to mean “match any one.” To keep only Hong Kong and Japan, for example, use “Hong Kong|HK|HKG|Japan|JP|Tokyo|Osaka.” Because providers may mix capitalization and naming styles, the safest approach is to include every variant that actually appears, then update the current group immediately after saving to verify the result.

Hong Kong|HK|HKG|Hong Kong
Japan|JP|Tokyo|Osaka
Singapore|SG|Singapore
United States|US|Los Angeles|San Jose

Include filters are useful for narrowing regions; exclude filters are better for removing entries that are not servers. Common exclusion terms include “Remaining,” “Expired,” “Plan,” “Announcement,” and “Official Site.” Do not exclude every name containing “倍率” solely because of that term: some providers include multiplier information in valid server names, so the filter may remove usable routes by mistake.

Set update intervals and group sorting

The automatic update interval controls how often v2rayN reads a subscription again. It is not a server latency-test schedule and does not automatically switch the active server. After an update, new nodes enter the corresponding group and removed nodes are handled according to the client's update logic. Manually edited subscription nodes may be overwritten by remote content, so custom servers should be saved separately rather than mixed into a group that refreshes continuously.

Set the interval according to how quickly the subscription changes. A primary subscription that frequently changes routes can use 12 or 24 hours; a stable backup subscription can use 48 or 72 hours. Intervals that are too short create unnecessary repeated requests, while intervals that are too long may leave expired nodes visible. Desktop scheduled tasks do not continue while the client is closed; after restarting, manually update all subscriptions once.

• Sort value 10: Frequently used work group, placed first.
• Sort value 20: Personal daily-use group, used as the second choice.
• Sort value 30: Infrequently used backup group, kept visible without taking the top position.
• Reserved sort-value gaps: Use 10, 20, and 30 instead of 1, 2, and 3 so that 15 or 25 can be inserted later without renumbering everything.

Group sorting only controls the display order of groups in related lists. It does not set connection priority or automatically select the server with the lowest latency. Servers within a group can still be sorted by latency, speed, or remark, but each test depends on the local network, target address, and test time. A safer workflow is to switch to the target group, run a real latency test on its candidates, and then manually set the chosen server as active.

Coordinate subscription groups with routing rules

Subscription groups answer “which servers exist and where do they come from?” Routing rules answer “which outbound should handle a request?” Choosing a VLESS server in “Work-Asia” only selects the remote configuration used by the proxy outbound. Whether a domain uses that proxy is still determined by the active routing mode. Naming a group “Direct” does not make traffic connect directly, and naming a node “Office” does not automatically match office domains.

In v2rayN, open “Settings” → “Routing settings” to review rule sets, and choose the current routing mode in the main window. Rules generally match domains, IPs, ports, or protocols by priority, then send matching traffic to a proxy, direct, or block outbound. After making changes, reload the configuration and use the core log to confirm that requests matched the intended rules.

For example, if the local mixed proxy port is 10808 and the browser follows the system proxy, requests first enter v2rayN's local inbound and are then evaluated by the routing rules. If the rules send LAN addresses direct, frequently used mainland-China domains direct, and all other requests through the proxy, the active server carries only the last category of traffic. Switching to a server in another subscription group does not require rewriting these routing rules.

1. Select a tested active server in the target subscription group.
2. Open “Settings” → “Parameter settings” and confirm that the local listening port does not conflict with another program.
3. Open “Settings” → “Routing settings” and check the rule order and target outbound.
4. Enable the system proxy, visit a test target, and verify the match result in the core log.
5. Keep the routing rules unchanged while switching servers, then compare latency and connection stability.

Common issues and troubleshooting order

Handle multi-subscription problems in this order: group records, subscription requests, filtering results, server connections, and routing matches. First confirm that data reached the client, then check connectivity, and only afterward determine whether traffic is leaving according to the rules. Skipping the data checks and changing routing immediately usually adds more variables.

After organizing everything, keep a short record of each group's purpose, sort value, update interval, include terms, and exclude terms. When a provider changes its naming scheme, compare the old and new server remarks before editing the filters. This turns one-time list cleanup into a maintainable configuration workflow.