v2rayN Subscription Groups: Organize Servers by Provider, Filter by Keywords, and Manage Nodes

Understand subscription groups, server remarks, and the active server

In v2rayN, subscription links are the source of your nodes, subscription groups store each source and its update settings, and the server list displays the parsed nodes. Keep these three layers distinct: changing a server’s remark doesn’t change its subscription link, and switching the active server doesn’t move it to another group. When managing multiple subscriptions, group them by source before filtering.

For example, if you have subscriptions for “Commute” and “Backup,” create a separate group for each instead of replacing the first address with the second. If an update goes wrong, you can identify which subscription returned no nodes instead of guessing from one large list. Name groups by source and purpose, rather than including an expiration date you’ll have to keep changing.

These figures are organizational suggestions, not client limits or promises of automatic updates. Even with just two groups, make sure each link comes from a service you actually use and keep subscription URLs private: they may contain account-identifying parameters and shouldn’t appear in public screenshots.

Create groups and update subscriptions individually

These steps are based on the common v2rayN 7.x interface. Button locations may vary between minor versions, but the target is always “subscription groups,” not an individual server in the list. When setting things up for the first time, add and update subscriptions one at a time so it’s easier to catch a mistyped URL, a network timeout, or an unexpected response.

1. Create a group

   Open “Subscription groups” → “Subscription group settings” in the main window and click the add button. Enter an easy-to-recognize name, such as “Primary | Weekdays.” Save each subscription URL in its own group.

2. Enter the URL

   Paste the full subscription URL into the subscription address field and check for extra spaces at either end. If the settings page offers an “Update through proxy” option, enable it based on whether your current network can reach the subscription URL directly.

3. Save and verify

   After saving, return to the main window and verify that each group name matches the right URL. Repeat the first two steps for your second subscription; don’t replace the first URL in an existing group.

4. Update each group separately

   Choose the subscription update command from the “Subscription groups” menu. Update one group first, then check the server count and logs before updating the next. Start filtering only after you’ve confirmed the new servers are in the right group.

An update doesn’t simply “add new nodes”: the list may also change when a provider removes or renames nodes. Don’t treat subscription nodes you’ve edited manually as permanent, standalone configurations. If you need to keep custom settings, record the original parameters and your changes, then decide whether to create a separate manual server. You can also use the client’s configuration backup feature before routine updates to preserve the current state.

Filter by keyword to narrow the list without changing the subscription

Once you’ve identified the subscription group, select it and use the filter box near the server list. Filtering narrows what’s displayed, making it easier to find nodes whose remarks contain names such as “Hong Kong” or “Japan,” or provider-specific tags. It doesn’t send filtering rules to the provider or replace a subscription update. Before a bulk operation, check whether a filter is still active.

Use keywords taken from the actual remarks; don’t assume every provider uses the same naming convention. One group might use “HK” for the region while another says “Hong Kong,” so searching for “Hong Kong” won’t find both. If the results suddenly disappear, clear the filter first, confirm the group contains nodes, then check whether the provider changed the remarks in its latest update.

A shorter filtered list doesn’t mean the hidden nodes have been deleted. Before selecting multiple servers, testing, or deleting, check whether the action applies to visible items, selected items, or the entire group. Clear the filter afterward and check the full list. This prevents mistaking “not displayed” for “missing from the subscription.”

Sort by latency within a group—but don’t confuse latency with bandwidth

Select a group, filter by region if needed, then select the servers you want to compare. Find the real connection latency test in the server list’s right-click menu, run it, and sort by the results column. Menu labels and column names may differ slightly between v2rayN versions. The key is to test the same set of nodes the same way; don’t compare results collected at different times or on different networks in one list.

• First, test connectivity: distinguish nodes that time out or fail to connect from those that complete the test. Don’t rush to delete failures.
• Next, retest only the candidates a few minutes later. A single high-latency result may be caused by local network fluctuations and doesn’t prove a node is consistently unavailable.
• After switching to a server, try opening the websites you normally use. Low latency only means the test connection was fast; it doesn’t guarantee high download speeds or access to a particular site.
• Keep the network conditions consistent when comparing results. Don’t rank an old test from your office network alongside a new one from a mobile hotspot and call the winner “fastest.”

For example, if two nodes in the same group test at 85 ms and 120 ms, that can help you decide which to try first—but it doesn’t tell you their throughput. Use VMess and VLESS servers with the parameters provided by the service. Don’t change the protocol, port, or transport just to chase lower latency. If a test passes but a website won’t load, check the system proxy, routing rules, and connection to the site separately instead of immediately marking the entire group as unusable.

Cleaning up inactive nodes: investigate first, then decide whether to delete

Deleting a subscription node from the list usually doesn’t block it permanently; the next update may import it again from the subscription. First determine whether the problem is a temporary network issue, a subscription update failure, or a route the provider has withdrawn. Check the source before cleaning up to avoid a cycle of deleting nodes only to see them return.

If you really need to bulk-delete servers, first clear the filter, return to the target group, and verify how many servers are selected. Then remove only the items you’ve confirmed you no longer need. If you’re still using the subscription, remember that those nodes may return with the next update. If you’ve stopped using the entire subscription, back up any manual configurations you want to keep, then manage the group in subscription settings. That’s easier than deleting servers one by one and helps keep the list tidy.

Make cleanup a quick, repeatable check

Managing multiple subscriptions doesn’t mean renaming every server each day. Use the same sequence: check groups, update subscriptions, clear old filters and check the total count, narrow the list by region or route keyword, test candidates, then verify with an actual connection. Dig into logs or clean up inactive nodes only when something looks wrong.

1. Check that each group name matches its subscription URL. Don’t overwrite an existing group that’s still in use with a new URL.
2. Update one group at a time and check the number of servers returned. If a group has a problem, troubleshoot the network and URL for that group only.
3. Select a group and enter a keyword, then test candidate servers under the same conditions. Clear the filter when testing is done.
4. Retest failed nodes before deciding whether to keep them, ignore them for now, or follow up with the provider about the route.

This workflow separates source issues, display issues, and connection issues. Groups show where nodes come from; filters control which nodes you see; tests and real-world access show whether they work. When the list changes unexpectedly, tracing these steps makes it easier to find the cause than repeatedly updating every subscription or clearing the entire server list.