v2rayN Subscription Groups and Server Filters: Manage Multiple Subscriptions

At a glance

This guide is for v2rayN users who can already import subscriptions but have a growing, cluttered server list. Follow the workflow in order: group by source, filter by name, update one group at a time, then review the results. The examples use two purpose-based groups and two filter expressions. Subscription filters, list search, and routing serve different purposes—organizing your list does not automatically select an outbound route.

Subscription Groups, Filters, and Routing: What’s the Difference?

Subscription groups organize server entries by source. Each group stores its own subscription URL and update settings. When you update a group, the client reads the subscription and creates or refreshes that group’s server list. A group name is only a local label: it does not change the provider’s servers or automatically route traffic through that group.

Create a source group Read subscription data Filter by server name Refresh the server list Test the connection manually

A group’s name filter narrows the imported results; search or filtering on the main screen helps you find entries in the current list. They take effect at different times: after changing a subscription filter, you generally need to update that group again. Closing the settings window alone won’t apply the change. Routing happens when a connection is made: rules based on domains, IP addresses, and other criteria select an outbound route. Routing does not organize the subscription list.

Action	What it affects	Where to check
Subscription groups	Subscription sources and their server entries	“Subscription Groups” → “Subscription Group Settings”
Subscription filters	Server names imported during an update	The “Filter” setting for the relevant group
List search	Entries currently shown in the interface	The search or filter area on the main screen
Routing rules	Network connections as they’re made	Routing settings and core runtime configuration

Group by source, then label each group by purpose

Go to “Subscription Groups” → “Subscription Group Settings,” add a group, then enter a “Remarks” label and the “Address (URL).” Button locations and field names may vary between interface versions. Make sure you’re editing a subscription group—not an individual VMess or VLESS server. If the interface has an enable switch, make sure the group is enabled.

Create a separate group for each source. For the remarks, use “short source name / main purpose,” such as “Source A / Daily.”
Paste the full URL. The path, query parameters, and token are all part of the subscription URL. Don’t copy just the domain or include explanatory text from a chat message.
Leave filters empty for the first update. Save the group, update it, and confirm the subscription imports successfully. Note the server names as they appear.
Set filters after reviewing the names. Choose stable keywords from the names you actually see; don’t assume the provider uses HK, JP, or Chinese region names before checking the list.

These examples show how to organize groups by purpose; they don’t represent real subscription sources or server counts. Enter a subscription URL you’re authorized to use. Keeping the two sources separate makes it easier to tell whether one subscription is unavailable or all subscriptions are failing to update.

Source A / Daily

Remarks: Source A / Daily
Address: Full subscription URL provided by Source A
Initial filter: Leave blank and inspect the original names
Goal for later: Keep entries for Hong Kong and Japan

Including both source and purpose in the remarks makes groups easier to identify when switching between lists.

Source B / Backup

Remarks: Source B / Backup
Address: Full subscription URL provided by Source B
Initial filter: Leave blank and confirm the import works
Goal for later: Exclude entries with “test” or “expired” in the name

Keep the backup source in its own group; don’t duplicate server entries to simulate grouping.

Filter by keyword: start with an allowlist, then exclude

In v2rayN subscription group editors that support regex filters, the “Filter” field matches server remarks and keeps entries that match. It is not an exclusion box where anything you enter gets removed. Check the field’s description first. If your version doesn’t have this setting, don’t enter an expression in the subscription URL, remarks, or address-conversion fields.

Start with a simple keyword for an allowlist. To keep only entries whose names contain “Hong Kong,” enter Hong Kong. To keep multiple regions, use the regex alternation symbol |. Don’t enter “Hong Kong,Japan” as if the comma separates two choices: in regex, a comma usually matches a literal comma.

Goal	Filter expression	Notes
Keep only Hong Kong	`Hong Kong`	The name must contain these characters
Keep Hong Kong or Japan	`Hong Kong\|Japan`	Keeps a match for either alternative
Also match English region abbreviations	`(?i)(Hong Kong\|Japan\|\bHK\b\|\bJP\b)`	Ignores English letter case; check that word boundaries match the separators in your server names
Exclude names containing “test” or “expired”	`^(?!.(?:test\|expired)).$`	A negative lookahead means the full line must not contain these strings

The final expression in the table assumes a filter field that uses .NET regex syntax. Other tools or custom configurations may use a different regex engine and may not support the same syntax. After entering it, update the current group and check the results before applying it to other groups.

Avoid overly broad abbreviations. A bare US may match other words; word boundaries don’t replace checking the actual names.
Watch the punctuation. . matches any character. To match a literal period in a name, use \..
Don’t assume search-box syntax. Spaces, commas, or exclamation marks may not mean “and,” “or,” or “exclude.”
Be explicit about case. To match English names regardless of capitalization, use (?i) rather than guessing how case is handled.

Check your filter: test one keyword before adding conditions

First, update once using “Hong Kong” to verify the filter works. Then change it to a region allowlist or an exclusion expression. If even a simple keyword doesn’t produce the expected results, check the field, when the filter takes effect, and the original server names. Don’t keep piling on regex conditions.

Run a repeatable test with two groups

This walkthrough tests the management workflow only; it makes no claims about speed or latency. It uses two groups and two rules. The server names are test strings for demonstrating matches, not entries guaranteed to be available from a subscription provider. Update one group at a time so you can tell which rule caused a change.

Test groups: Daily and Backup

Test rules: keep selected regions and exclude matching names

In the filter for “Source A / Daily,” enter Hong Kong|Japan and save. Return to the main screen, select that group, then update the current subscription from the “Subscription Groups” menu. Common options include “Update current subscription (without proxy)” and a corresponding “through proxy” option. Choose based on your current network access.
Check the server names. “Hong Kong-Daily” and “Japan-Backup” should match; “Singapore-Daily” should not. Clear the main-screen search first so you don’t mistake search results for subscription import results.
In “Source B / Backup,” enter ^(?!.*(?:test|expired)).*$, save, and update only that group. “Hong Kong-test” should not match; “Japan-Backup” should.
Manually select one of the remaining servers as the active server. Check that the core starts correctly, then test the connection with a service you actually need to access.

Filtering checks names only. It doesn’t tell you whether a server has expired, identify its actual location, or guarantee that it works. An entry is excluded for “expired” only because those characters appear in its name. To find out where a server named “Japan” actually exits, test it separately; the group or remarks won’t tell you.

Keep your list tidy after updates: save rules in the group

Subscription entries come from remote content. If you delete unwanted servers only from the main list, they may reappear on the next update. Edits to a subscription entry’s local remarks may also be overwritten. For long-term organization, use group-level filters; edit entries manually only when you need to maintain them independently.

Before updating: Confirm the selected group, and note the active server and filter expression. Don’t rely on row numbers; sorting and updates can move entries.
During the update: Check the status message and distinguish a download failure from a parsing error or no entries matching the filter. Error messages vary by version, so keep the full context.
After the update: Clear temporary searches, check the group, server names, and protocols, then confirm the active server is still available.
If names change: Temporarily clear the group’s filter and update it again. Check whether the source changed Chinese region names to English abbreviations, then adjust the rule.
To restore your setup: Before editing groups or reorganizing entries in bulk, use the client’s backup feature to save your configuration. Treat backup files as data that may contain credentials.

You can use the same subscription URL in groups for different purposes, but this creates multiple sets of update results and adds maintenance overhead. Do this only when you genuinely need separate filters. If both groups have the same filtering goal and you just need to find a region temporarily, searching the main list is usually simpler.

Rule of thumb: group by source, label by purpose

Keep each source’s update boundary clear, and split it into separate groups only when you need different import results for different purposes. That way, you can trace an update failure to its source and a filtering issue to its expression, rather than guessing through a mixed list.

Troubleshoot an empty list, duplicates, or failed connections

First identify which layer the problem is in. An empty list is an import or display issue; entries that appear but won’t connect point to the active configuration, core, or network. If a subscription download fails, don’t keep changing regexes. If a server is unavailable, renaming its group won’t fix it.

Symptom	Check first	Next step
List is empty after adding a filter	Filter logic, name capitalization, and selected group	Clear the filter and update the group to confirm the original entries return
List doesn’t change after editing a rule	Whether you saved, updated again, and the update succeeded	Update only the current group and check the status message
Deleted entries reappear	The remote subscription still includes the entry	Use a group filter instead of repeatedly deleting entries by hand
The same server name appears in multiple groups	Whether the source was added more than once or sources overlap	Check which group each entry belongs to; identical names don’t guarantee identical connection settings
Subscription URL won’t download	URL validity, network access, and proxy route	Choose between updating through or without a proxy; don’t rely on an outbound route that no longer works
Entry remains in the list but connection fails	Active server, core logs, and protocol parameters	Return to connection troubleshooting; changing the name filter won’t help

Protocol names such as VMess and VLESS describe connection configurations, not group labels. Filtering by name won’t convert VMess to VLESS or fill in TLS, transport paths, or other settings required by the server. If the subscription imports successfully but the core fails to start, check the logs and selected configuration instead of blaming the group.