Multi-Subscription Management: Server Filtering Rules and Node Selection Tips

Separate subscription sources from the server list

The more nodes you have, the less practical it is to keep every server in one long list. A subscription answers “where is the configuration updated from?”, while a server entry answers “which route am I connecting to now?” They are different layers. One subscription may contain dozens of VMess, VLESS, or other compatible configurations, and updates may add, rename, or remove entries. If you rely only on server names to remember their source, the list can become confusing after a few updates.

A reliable structure is to create subscription groups by source, then filter nodes within each group. In the v2rayN desktop client, open “Subscription Groups” → “Subscription Group Settings” to review the name, URL, and update options. In v2rayNG, manage sources from Subscription Group Settings in the side menu. Menu wording may vary slightly between versions, but the principle is the same: every subscription URL should have a distinct, recognizable label that remains stable over time.

Do not copy temporary titles generated by the subscription provider, since they may change with a plan or promotion. A more useful format is “source shorthand + purpose + billing cycle,” such as “North-Daily-Monthly” or “Backup-Mobile.” The source shorthand distinguishes subscriptions, the purpose supports quick decisions, and the billing cycle is worth adding only when renewal tracking requires it. Keep labels concise.

Do not give the same subscription completely different labels on different devices. Keeping desktop and Android labels consistent lets you refer to “Hong Kong 02 in the Primary group” during troubleshooting instead of relying on a list position. Server order may change after an update, so stable group names and node keywords are better ways to locate entries.

Create a reusable labeling convention

Node names often include a region, multiplier, route, or sequence number, but different subscription sources use different naming conventions. Hong Kong may appear as “Hong Kong,” “HK,” or “Hong Kong,” while Singapore may appear as “Singapore,” “SG,” or “Singapore.” A single keyword can therefore miss equivalent names when searching across groups. First inspect the naming used by each source, then choose filter terms; this is more reliable than applying a fixed template.

Keep filtering dimensions to three categories: region identifies the exit location, route or purpose separates daily, backup, and low-multiplier options, and status terms exclude entries such as “maintenance,” “expired,” or “traffic remaining.” Protocol names such as VMess and VLESS are useful when troubleshooting compatibility, but they should not be used alone to judge speed. Protocol, transport layer, server load, and the local network all affect connection performance.

Sequence numbers are useful only for distinguishing nodes within the same region, such as “HK-01” and “HK-02.” Do not use “Node 1” or “Node 2” as universal names across subscriptions, because an update may assign the old number to a different server. If the client supports local labels, retain the region and route markers from the original name and add a short prefix, such as “Primary-HK-02.”

There is no need to rename every entry manually before updating a subscription. First check whether the group settings overwrite local labels, then add local identifiers to only a few frequently used nodes. For frequently changing subscriptions, maintaining filter rules is usually faster than maintaining dozens of custom names; for long-term self-managed configurations, more detailed labels can include region, entry point, and purpose.

Shorten the server list with include and exclude rules

Filtering can be either temporary or persistent. Temporary filtering is useful for an immediate search, such as typing “HK” into the server filter box in v2rayN or using search in v2rayNG’s configuration list; clearing the field restores the full list. Persistent rules belong in the subscription group’s filter settings and allow only matching entries into that group. Before using them, confirm whether the field accepts plain keywords or regular expressions; do not paste regex syntax into a plain-text keyword field.

The safest starting point is a single include term. If you need Hong Kong entries, try “Hong Kong” and “HK” separately and check whether the results cover the intended nodes. Once the naming pattern is clear, combine synonyms with “Hong Kong|HK|Hong Kong.” In a regex, the vertical bar means “either option,” while parentheses define a grouped expression. Whether English case matters depends on the client implementation, so verify it with a known node.

Region include:
(HK|Hong Kong|SG|Singapore)

Status exclusion:
^(?!.*(expired|expiry|remaining|traffic|maintenance|test)).*$

Keep selected regions and exclude status terms:
^(?!.*(expired|expiry|remaining|traffic|maintenance|test)).*(HK|Hong Kong|SG|Singapore).*$

The negative lookahead in an exclusion rule means that the entire line must not contain any of the listed terms. It is useful for removing plan-expiration reminders, traffic notices, and maintenance messages, but avoid adding words such as “test” when they may be part of a normal route name. Before saving a rule, preview it with temporary filtering and inspect at least five retained entries and five excluded entries.

The longer the rule, the higher the maintenance cost. A common mistake is putting region, multiplier, protocol, transport, and sequence number into one expression, so a minor rename by the provider breaks the match. A better approach is to use a broad region filter first, then apply a second temporary filter by latency or keyword in the client list.

Sort by latency, variation, and real-world access

A latency test only shows whether the test target responded quickly at that moment; it does not fully represent sustained downloads, initial page loads, or long-lived connections. After sorting, keep several candidates instead of retaining only the lowest value. A practical method is to run three consecutive tests about 30 seconds apart and record consistency. A node returning 72, 76, and 74 ms is usually a better daily choice than one returning 48, 260, and a timeout.

Control variables during testing. On desktop, pause large file transfers and system updates, confirm that the current v2rayN core is running, and then test latency within the same group. With the system proxy enabled, a common local listening port may be 10808, but use the actual value shown under “Settings” → “Parameter Settings.” If another process occupies the port, both latency results and web access from the node list may be abnormal.

1. Update the target subscription group; do not test every source together immediately after a single update.
2. Use region keywords to narrow the candidates to 12–24 nodes.
3. Run the first latency round and remove entries that consistently time out or are clearly unusable.
4. Wait about 30 seconds and run two more rounds. Watch the variation instead of looking only at the minimum value.
5. From the stable results, choose 3–5 nodes and test initial page loads, video loading, or the actual workload.
6. Keep one primary node and two backups on different routes so all candidates do not depend on the same path.

Android is more affected by mobile-network changes and background system policies. When testing with v2rayNG, keep the network type unchanged and do not switch repeatedly between Wi-Fi and mobile data. If the app has just resumed from the background, wait for the connection state to stabilize before testing; otherwise, the first result may include extra network setup time.

The end product of sorting is not a permanent ranking but a short list. For each frequently used region, keep 4–6 nodes, with roughly half from the primary subscription and half from the backup. This enables quick switching without letting the list grow beyond practical judgment.

Use the same group logic in v2rayN and v2rayNG

The desktop and Android lists do not need to have exactly the same order, because the two clients may import, sort, and test locally in different ways. What should be synchronized is the group naming, region keywords, and retention criteria. As long as “Primary-Daily” and “Backup-Emergency” mean the same thing on both devices, you can quickly identify the type of source in use.

v2rayN is better suited to reviewing server columns in bulk, sorting by test results, and handling many entries; v2rayNG is better for keeping a compact set of frequently used configurations. Start by observing the subscription’s naming patterns on desktop, then apply the same include and exclude terms on Android. If the relevant Android field supports only plain-text search, use several short keywords instead of forcing in a complex expression.

• Weekly maintenance: Update the primary group, run three consecutive tests, and replace failed nodes in the short list.
• Before use: The backup group does not need frequent sorting; update and test it when you need to switch.
• Protocol troubleshooting: When connections fail, temporarily filter by VMess or VLESS and compare the performance of entries using the same protocol.
• Routing check: Reconnect after changing routing rules so that an old session does not continue using the previous outbound.
• Update record: If a group suddenly loses many nodes, check the filter conditions before deciding that the subscription content has changed.

Routing and subscription groups must also be treated as separate concerns. Group management determines which servers enter the list; routing rules determine which requests go direct, through the proxy, or are blocked after a connection is established. Switching nodes does not automatically fix incorrect routing rules, and changing routing does not alter the number of nodes in a subscription. During troubleshooting, check the list first, then inspect core logs and routing matches.

If v2rayN and v2rayNG both show missing nodes in the same group, first check the subscription content or shared filter keywords. If only one client is affected, check that client’s group selection, update time, and local filter state. This comparison quickly shows whether the issue lies with the source, the rules, or a single client.

Common issues and fixes

The most common subscription-management problems are not complete failures, but mismatches between the list size, filter results, and expectations. Do not change several conditions in succession. Change one variable at a time—for example, clear the temporary search first, disable persistent filtering next, and then update the target group—so you can identify which step affected the result.

For long-term maintenance, aim for every group to provide a usable node within one minute. This depends not on complex rules, but on stable group names, a few clear keywords, and a fixed testing sequence. When node counts change, check filtering first; when connection performance changes, run latency and real-world access tests. Keep these two troubleshooting paths separate.

Even after adding more than three subscription sources, keep the number of active groups controlled by purpose. Expand only the primary and backup groups for daily use, and give infrequently used sources clear labels. A readable list is often more valuable than saving every entry.