v2rayN Subscription Groups: Manage Multiple Providers and Filter Servers

Group subscriptions by source instead of mixing every node into one list

After importing a subscription into v2rayN, server names, addresses, ports, protocols, and transport parameters are parsed into individual configurations. When several subscriptions share one view, similarly named servers in Hong Kong, Japan, and Singapore can easily get mixed together. If an update fails or a route becomes unstable, it is also difficult to tell which provider supplied the configuration.

Subscription groups handle source management, not protocol conversion. A group usually maps to one primary subscription URL, but it can also contain a backup URL for the same service. VMess, VLESS, and Trojan servers can coexist in one group. v2rayN invokes the appropriate core capabilities for each server configuration; the group itself only organizes, updates, and filters entries.

Give each source a short name that will remain recognizable over time, such as “Primary-A,” “Backup-B,” or “Low-Multiplier-C.” Avoid labels like “Subscription 1” or “New Subscription,” which make it hard to know three months later which group to keep, disable, or refresh. Group names do not need to include sensitive parameters from the subscription URL.

• Separate by source: Create one group for each provider so failed updates can be investigated independently.
• Label by purpose: Record uses such as “daily,” “large files,” or “backup” in the group notes instead of renaming every server.
• Keep inactive groups: Disable subscriptions you are not currently using, and delete them only after confirming they are no longer needed.
• Avoid duplicate imports: Do not place the same URL in two enabled groups, or the server list may contain duplicates.

Create a subscription group: names, URLs, and update settings

The steps below use the Chinese interface in v2rayN 7.x as an example. Open “Subscription Group” → “Subscription Group Settings,” add a record, then enter an alias, subscription URL, and update interval. Some 7.x builds may label the entry “Subscription Group Settings” or “Subscription Settings,” but the fields work the same way. Save the changes, return to the main window, then choose “Subscription Group” → “Update Current Subscription” or “Update All Subscriptions.”

When creating several subscription groups for the first time, do not update every source repeatedly right away. Enable and update the first group, confirm that its server count and names look correct, and then move on to the next one. This makes it easier to identify a newly added URL when the result is empty, malformed, or filled with duplicates.

1. Open “Subscription Group” → “Subscription Group Settings,” then choose Add.
2. Use a stable source name for the alias, such as “Primary-A,” rather than pasting the full URL into the name field.
3. Enter the subscription URL and leave it enabled; disable a backup group while it is not needed.
4. Set the automatic update interval to 24 or 48 hours so every startup does not request all subscriptions.
5. Save the settings, return to the main window, and manually update the current group once.
6. Check the group label, server count, names, and protocol column before adding the next group.

If a subscription must be updated through the current proxy, first connect to a verified working server, then enable an option such as “Update through proxy” in that subscription’s settings. This only changes how the subscription request exits; it cannot repair an invalid URL. If timeouts or empty responses continue, check whether the URL is still valid.

Keyword filtering: remove informational entries first, then keep the target region

A subscription may contain more than connectable servers. It can also include entries such as “remaining traffic,” “expiry date,” and “plan information.” These usually convey account status through the server name and have no value in latency tests. First exclude informational terms, then keep region or route terms that match your current needs.

Different v2rayN 7.x builds may place filtering under subscription settings or in the server-list filter box. Subscription-level filters affect what remains after an update and are suited to lasting rules; the main-window text filter only changes what is visible now and is better for temporary searches. For a first setup, test keywords in the main window before saving them as subscription-level rules.

If the current version supports regular expressions, you can combine regional synonyms in one rule. Before entering one, confirm that the interface explicitly mentions “regular expression” or “Regex”; a normal text filter may perform literal matching only. The two expressions below match Hong Kong region names and common informational entries. Test them in a temporary filter first.

Region match: (Hong Kong|HK|Hong Kong)
Informational entry: (Remaining|Expiry|Plan|Official site|Traffic)

The longer a filter rule becomes, the greater the chance of false positives. For example, matching “US” for US servers may hit those letters inside unrelated English names, while “Hong Kong” may match notes that are not region labels. A safer approach is to inspect the provider’s naming conventions, prefer complete terms such as “Hong Kong,” “HK-,” or delimited names, and record the node count before and after applying a rule.

How to set update intervals: avoid excessive requests and stale lists

Updating a subscription is not the same as testing server latency. An update downloads and parses the latest server configurations; it does not mean those servers are currently reachable. A latency test sends test connections using existing configurations. Scheduling these tasks separately prevents v2rayN from requesting multiple subscriptions and testing hundreds of connections every time it opens.

Set a primary subscription used daily to update every 24 hours. A backup subscription that changes less often can use 48 or 72 hours. Temporary subscriptions and paused sources can have automatic updates disabled and be refreshed manually only when needed. If the provider explicitly requires a new subscription URL, changing the interval will not fix an expired URL.

When updating several subscriptions at once, check the request results in the v2rayN log. A subscription can return successfully but still contain zero servers because the filter is too strict, the content format changed, or the URL returned an information page. Connection timeouts call for checking the network path and the “Update through proxy” setting. Do not delete an entire group because of one timeout.

• Before updating, note the approximate server count for each group, such as 86 in the primary group and 42 in the backup group.
• If the count drops sharply to 0–3 after an update, disable the filters first and update again.
• If the same group times out twice in a row, connect to a working server and try updating through the proxy.
• After a successful update, test a small number of candidates first instead of immediately running a full test on hundreds of configurations.

Test servers by group: narrow the field with real connection latency

Once the server list is organized, test by group rather than across the entire collection. Switch to the target subscription group, select its servers, and run a real connection latency test. This test performs the protocol handshake and target connection, making it closer to the time required to establish an actual proxy connection than a simple address response, but it still is not the same as download speed.

Suppose the primary group has 86 servers. Use a keyword filter for “Hong Kong” or “HK” to reduce the candidates to 18. Run a real connection latency test, remove or ignore timeouts, then choose 3–5 candidates in the 120–220 ms range. Open several commonly used websites and run short downloads through each one to check for slow first loads, sustained jitter, or a clear drop in throughput.

1. Switch to the “Primary-A” group and confirm that no backup servers are mixed in.
2. Enter a region term in the filter box to reduce 86 servers to roughly 10–20.
3. Select all current results and run a real connection latency test.
4. First exclude timeouts, errors, and servers above 500 ms.
5. Keep 3–5 of the lowest-latency results, then test real websites and download performance.
6. Select a server, enable the system proxy, and verify that the local listening port is working normally.

Use the value shown under “Settings” → “Parameter Settings” as the local port. Some configurations use 10808 for a local mixed or SOCKS listening port, while other versions or custom setups may differ. If the log reports that the port is already in use, close the old process occupying it or change the parameter to an unused port such as 10818, save the settings, and restart the core.

Protocol names should not be treated as speed rankings. VMess, VLESS, and Trojan describe different proxy protocols and combinations; real-world performance also depends on server load, entry-point quality, transport, egress region, and the local network. Compare reachability, latency, and stability within the same region first, then factor in the multiplier. There is no need to split groups simply because the protocol names differ.

Keep routing rules separate from subscription groups

Subscription groups determine which servers exist and where they came from. Routing rules determine whether a connection uses the proxy, connects directly, or is blocked. Confusing the two often leads to repeatedly changing subscriptions without fixing the routing rule that actually controls the access path.

For example, after selecting a VLESS server in the primary group, whether a browser request uses that server still depends on the system proxy, TUN mode, or the application’s own proxy settings, as well as the routing rules currently enabled in v2rayN. Updating a subscription does not change custom routes automatically, and switching groups does not repair rule priorities.

When a server passes latency tests but web traffic does not use the proxy, check these in order: whether the server is the active one, whether the system proxy is enabled, whether the local port is listening, and whether routing rules mark the target for direct connection. Do not keep updating the subscription; updates only refresh the server list.

Common issues: update failures, duplicate servers, and over-filtering

Problems with multiple subscriptions usually occur at one of four stages: URL requests, content parsing, filter rules, or the latency-test scope. Identify the layer first, then change the relevant setting. This preserves the existing group structure better than deleting everything and importing again.

A group-maintenance routine that works long term

Subscription management does not require reorganizing everything every day. Once naming is stable, check update results and abnormal servers once a week. The elements that should change frequently are the active server and temporary filters, not the group structure.

• First import: Create a separate group for each source, update them one at a time, and verify the server count.
• Permanent rules: Exclude only informational entries such as “remaining,” “expiry,” and “plan.”
• Temporary filters: Narrow the current candidates by region, multiplier, or route label.
• Group testing: Test only 10–20 candidates at a time, eliminating timeouts and high latency first.
• Real-world validation: Choose 3–5 low-latency results and test real websites and sustained transfers.
• Regular cleanup: Disable duplicate sources, observe them for 48 hours, and delete them afterward.
• Troubleshooting: Check subscription requests, filters, latency tests, system proxy, and routing rules in that order.

Keep primary, backup, and low-multiplier sources independent so an update failure affects only one group. Keyword filters narrow the view, real connection tests eliminate clearly unusable candidates, and routing rules continue to handle the actual request path. With these responsibilities separated, daily operations remain clear even when the node list grows to hundreds of entries.