v2rayN Multiple Subscription Groups: Server Filtering, Naming Rules, and Automatic Updates

At a glance

This guide is for users who have imported more than two subscriptions into v2rayN and have dozens or hundreds of servers in the list. Once configured, you can maintain groups by source, filter servers by region, protocol, or purpose, schedule updates independently, and use a proxy when a subscription cannot be reached directly.

Create subscription groups by source first

Open v2rayN and choose “Subscription groups” → “Subscription group settings” from the main menu. Do not paste multiple subscription URLs into one group. Create one group per source, with its own alias, subscription URL, update interval, and enabled status. Updating one group will then leave servers from other sources untouched.

A group alias should describe both its source and purpose; avoid names like “Subscription 1” or “Backup 2”. Use a “short source name-purpose” format, such as “Alpha-Daily”, “Beta-Backup”, or “Lab-Test”. The alias appears in group selectors and server details, so keeping it between 6 and 16 characters makes lists easier to scan.

Create group Enter URL Set schedule Update subscription Filter nodes

How to fill in group fields

Daily-use group

Alias: Alpha-Daily
Update interval: 180 minutes
Enable updates: On
Proxy update: Disable when not needed

For the primary source used every day, an interval shorter than 60 minutes is usually unnecessary.

Backup source group

Alias: Beta-Backup
Update interval: 720 minutes
Enable updates: On
Proxy update: Enable when needed

Update backup lists less often to avoid refreshing sources you are not currently using.

After saving, choose the relevant group from the “Subscription groups” menu and run an update. Import groups one at a time initially, and note each group’s server count before and after the update. For example, Alpha may import 64 servers and Beta 38. If the next update suddenly returns zero, check the update log before deleting the original group.

Filter servers with keywords and regex

Once you have more than 100 nodes, do not rely on scrolling. Use ordinary keywords in the server-list filter, such as “Tokyo”, “Singapore”, “VLESS”, or “Backup”. Filters usually match server names, so stable naming makes search results more reliable.

Ordinary keywords work well for quick searches. To filter several regions at once, use a regular expression. First confirm that regex mode is enabled in the current version, then start with a simple rule. The more complex the expression, the easier it is to miss targets because of spaces, parentheses, or changing node names.

To show Tokyo nodes only, enter Tokyo and check for inconsistent names such as “Japan-Tokyo” and “JP-Tokyo”.
To show Tokyo or Osaka, enter Tokyo|Osaka in regex mode.
To show nodes marked for daily use, enter ^\[Daily\]; this requires names to use the same prefix.
To exclude test nodes, filter by the target region first, then inspect names for “Test” or “Temporary” markers. Do not infer a node’s purpose from latency alone.

Search target	Filter input	Expected result
Single region	`Singapore`	Servers whose names contain “Singapore”
Two regions	`Tokyo\|Osaka`	Either region appears in regex mode
Fixed purpose	`^\[Work\]`	Only names beginning with “[Work]” are shown
Protocol marker	`VLESS`	Only works when the protocol name is already included in the server name

The filter only changes what is visible in the current list; it does not modify server protocols, addresses, or routing settings. If a node is missing, clear the filter first, then check the subscription group selected on the left or at the top. The most common mistake is leaving a filter term in place and treating the empty list as an update failure.

Bottom line: standardize names before relying on search

Filters can only read existing fields. Keeping the source, purpose, and region consistent in server names is more reliable than maintaining increasingly long regex patterns. When subscription names change, you only need to adjust the naming rules.

Create naming rules for hundreds of nodes

A server name should answer three questions: where it came from, what it is for, and which region it uses. A useful format is “[Purpose] Source-Region-Number”, such as “[Daily] A-Tokyo-01” or “[Backup] B-Singapore-03”. Bracketed prefixes are easy to filter, source codes identify groups, and the final number distinguishes servers in the same region.

Do not put live latency in server names. Latency changes with network conditions, so “Tokyo-50ms” may be inaccurate a few hours later. Add a protocol name only when protocol-based filtering is genuinely needed, such as “[Test] A-Tokyo-VLESS-02”. For everyday nodes, check the type column to distinguish VMess from VLESS.

128

Example server count

Independent subscription sources

12 characters

Typical name length

10808

Example local proxy port

Split names into fixed fields

Daily node

Purpose prefix: [Daily]
Source code: A
Region: Tokyo
Number: 01

The final name is “[Daily] A-Tokyo-01”, suitable for long-term use.

Temporary test node

Purpose prefix: [Test]
Source code: C
Region: Frankfurt
Number: 02

After testing, filter by the prefix to review these nodes together, then decide whether to keep or remove them.

Use one letter or 2 to 4 characters for the source code, and do not change it when the subscription display name changes.
Choose one spelling for each region; do not mix “Tokyo”, “Tokyo”, and “JP-TYO”.
Always use two-digit numbers starting at 01, so sorting does not produce the order 1, 10, 2.
Keep purpose prefixes to two to four characters, such as “Daily”, “Backup”, “Test”, or “Work”.
Before making bulk changes, filter by group so that a prefix from source A is not applied to source B.

An update may overwrite local names with names supplied by the service. Test the behavior with a small number of nodes first: rename one node, update its group, and check whether the name remains. If it is overwritten, put the main classification in the group alias and filter rules instead of spending hours renaming every node.

Bottom line: naming rules must be reproducible

Record the naming convention as a one-line template and keep a mapping of sources and regions. Even if an update replaces the names, you can quickly restore the same structure instead of reorganizing each node from memory.

Set independent update intervals and proxy updates

Go to “Subscription groups” → “Subscription group settings” and set an update interval for each group. Use 180 minutes for a primary source, 720 minutes for a backup source, and disable automatic updates for temporary test sources so they can be updated manually. Avoid very short intervals for every group; refreshing a node list every few minutes does not make it more stable.

Before automatic updates run, make sure v2rayN is open, the system is not asleep, and the group is enabled. The log should show a clear request, parsing result, and server count. If it only records that a scheduled task ran without any additions or updates, inspect the content returned by the subscription URL.

Daily group: update every 180 minutes
Backup group: update every 720 minutes
Test group: disable automatic updates
Update order: Daily → Backup → Test
Error check: inspect the log first when 0 servers are returned

When a subscription URL cannot be reached directly, first connect to a known-working server, then enable “Proxy update” or the corresponding “Update through proxy” option for the target group. If the local proxy listens on 10808, the update request will use the current proxy chain. Field names may vary slightly between v2rayN versions, so follow the labels shown in the “Subscription group settings” window.

Select a tested, working server from the main list and set it as the active server.
Enable the system proxy and confirm that the browser can send requests normally.
Open the target subscription group and enable proxy updates or update through proxy.
Update the group manually and watch the response status and parsed server count in the log.
After a successful update, check the node count, names, and protocol types instead of relying only on the “Completed” message.

Troubleshoot duplicate nodes, empty groups, and update timeouts

The most common issue with multiple subscriptions is not import failure but the same server appearing in several groups. Compare the address, port, transport, and server identifiers rather than judging by name alone. Two nodes named “Tokyo 01” may use different entry points, while differently named nodes may actually point to the same address and port.

Empty groups usually have one of three causes: an invalid subscription URL, a filter that excludes every server, or content the current client cannot parse. Clear the filter and disable temporary filters before updating again; if the count is still zero, inspect the log. Do not delete the group first, because its original URL, update time, and options can help identify the problem.

What should I do if a subscription update keeps timing out?

Connect to a working server first, then go to “Subscription groups” → “Subscription group settings”, enable proxy updates for the failed group, and update it manually. If it still times out, check that the local proxy port is set to 10808 and look for a connection-refused message in the log.

What should I do if the node count suddenly becomes 0 after an update?

Clear the server filter, confirm that the correct group is selected, and check the download and parsing results in the update log. If the returned content is empty or malformed, temporarily disable automatic updates for that group and keep the original configuration.

A node appears in two groups. Which one should I delete?

Compare the address, port, protocol, and transport parameters first, then keep the source with more reliable updates and clearer names. If the groups serve primary and backup roles, you can keep both and distinguish them with source prefixes.

What if my bulk-edited names come back after an update?

This means the update is writing the service’s names back into the client. Put the source in the group alias and record purpose and region rules in a fixed template. Next time, bulk-edit only the filtered target nodes instead of renaming the entire list one by one.

Why are scheduled automatic updates not running on time?

Make sure v2rayN stays open at the scheduled time, the device does not sleep, and automatic updates are enabled for the group. Then check the scheduled-task entries in the log. If the client has just started, run one manual update to verify the URL and proxy-update settings.

Organize your groups once a month

Record the normal server-count range for each group, such as 55 to 70 servers for a primary group.
Remove temporary nodes confirmed to be invalid and still missing after two consecutive updates.
Check that name prefixes remain consistent, and merge duplicate purpose labels such as “Backup” and “Spare”.
Test at least two servers in each group; do not rely solely on the latency shown in the list.
Export all configurations once, adding the date to the filename, for example v2rayN-config-2026-08.json.

After cleanup, keeping one primary group, one backup group, and only the test groups you need is usually easier than maintaining many active sources. More groups are not automatically better; as long as source, purpose, update schedule, and naming rules are easy to identify, hundreds of nodes can be located with just a few filters.