Adding a subscription group in v2rayN is a small task, but the order of the actions matters. A subscription URL is not the same thing as a server configuration: the URL is the source, the subscription group is the container, and the imported server rows are the configurations that v2rayN passes to the selected core. If one of these layers is misunderstood, users may save a link successfully but still see an empty group, outdated nodes, or no active proxy connection.
This guide explains the complete workflow in v2rayN: where to enter a subscription URL, how to name and save the group, how to update its servers, how to select an active node, and how to manage several providers without accidentally editing the wrong group. The menu wording can vary slightly between v2rayN 7.x builds and desktop layouts, but the underlying process remains the same.
Follow one repeatable workflow: open the subscription-group manager, paste the complete URL, assign a clear group name, save it, update the group, select a server, and verify the local proxy status. The guide also covers update modes, duplicate groups, protocol compatibility, local ports, and the checks to perform when imported servers do not appear.
Understand what a subscription group stores
A subscription group is a named record that stores a provider’s subscription address and the server configurations obtained from that address. It normally contains a group name, the subscription URL, an update schedule or update behavior, and optional settings such as whether the request should use the proxy. The group itself is not a proxy node. It is the source from which v2rayN downloads and refreshes nodes.
The three layers are easy to separate:
- Subscription source: the URL supplied by the provider. It may return Base64 text, YAML, JSON, or another supported subscription format.
- Subscription group: the local v2rayN record that stores the URL and its management options.
- Imported server rows: the VMess, VLESS, Trojan, Shadowsocks, or other configurations generated from the latest response.
When you click a server row, you normally select a configuration for testing or activation. That action does not update the subscription and does not necessarily enable the system proxy. Updating the group retrieves fresh data; setting a server as active chooses the outbound configuration; enabling the system proxy determines whether ordinary applications send traffic into v2rayN.
Practical rule: manage the source, not every node
If a node came from a subscription group, treat the group URL as the source of truth. Manual changes to an imported row may be overwritten during the next update, so permanent corrections should be made by the provider or maintained as a separate manual server.
Prepare the URL and choose a clear naming scheme
Before opening v2rayN, copy the complete subscription URL from the provider’s account or service panel. Make sure the selection is a subscription link rather than a single-node share link. A single VMess or VLESS link usually imports one server; a subscription URL normally returns a list and can be refreshed later.
Do not remove the path, query string, or token from the address. Some providers use parameters such as an access token, user identifier, or format selector. A URL that looks unusually long may still be correct. If your provider supplies separate links for different clients, use the link intended for a generic V2Ray/Xray client rather than a configuration designed only for another application.
A useful group name identifies both the provider and its purpose. For example, use Provider-A Main, Provider-A Backup, or Travel Nodes instead of creating several groups called New Group. Names become especially important when two providers contain similarly named servers or when a provider offers separate regional plans.
| Group name | Purpose | Update behavior |
|---|---|---|
| Provider-A Main | Daily primary nodes | Regular scheduled update |
| Provider-A Backup | Alternative plan or region | Manual update before use |
| Provider-B Test | Short-term comparison | Update only when testing |
Check the URL in a plain text editor before pasting it into v2rayN. Look for accidental spaces, line breaks, quotation marks, or punctuation copied from surrounding instructions. Do not “repair” the address by deleting characters that seem unnecessary. If the provider displays the URL over several visual lines, copy the actual link field or use its dedicated copy button.
Add and save the subscription group in v2rayN
Open v2rayN and locate the subscription management command. Depending on the window layout, it may appear in the top toolbar or under a menu named Subscription Group. The common path is Subscription Group → Subscription Group Settings. Some builds expose a plus button directly beside the group selector; that button opens the same type of record.
Open group settings
In the v2rayN main window, choose Subscription Group → Subscription Group Settings, then select the command for adding a new subscription record.
Enter the URL
Paste the complete provider URL into the subscription-address field. Do not paste a single server share link if the goal is to maintain a whole provider list.
Name the group
Enter a unique name such as
Provider-A Main. Avoid names that differ only by a trailing number, because they are easy to confuse during updates.Save the record
Click Add, OK, or the equivalent save command. Confirm that the new group appears in the group list before closing the dialog.
Update the group
Return to the main window, select the new group, then use Subscription Group → Update Subscription or the toolbar update command.
Saving the group and downloading its servers are separate operations. After the record is saved, the server table may remain empty until an update is triggered. Watch the log pane while the update runs. A successful response normally produces one or more imported rows and reports an HTTP success status or a completed update message. The exact wording depends on the v2rayN build and the selected core.
If the update dialog provides an option such as Update subscription through proxy, leave it disabled when the provider URL is directly reachable from your current network. Enable it only when direct access consistently fails and an already working v2rayN node is available. Otherwise, v2rayN may attempt to use the very subscription that it is still trying to download, creating a circular dependency.
Refresh the list, test a node, and activate it
After the first update, select the new group in the main window and inspect the imported rows. Check the server name, protocol, address, port, and any provider-specific label. A node may appear in the list even when its access period has ended, its server address has changed, or its transport parameters are no longer accepted. The presence of a row is not proof that the node is usable.
Subscription group
- Name
- Provider-A Main
- Source
- Complete provider URL
- Update
- Manual or scheduled
Use this record to refresh the imported list.
Local proxy
- SOCKS5
- 127.0.0.1:10808
- HTTP
- 127.0.0.1:10809
- Core
- Xray or selected core
Verify actual ports under Settings before configuring applications.
Run a latency test or connectivity test on one or several rows. A latency value measures a particular request and does not guarantee that every website or application will work. For a fair comparison, test nodes under the same network conditions and avoid launching several high-load tests simultaneously. If all rows fail, investigate the subscription response, local time, network access, and core startup before deleting the group.
To use a node, select the row and choose the command equivalent to Set as active server. Then enable the intended traffic mode, such as the system proxy. In Settings → Parameter Settings, confirm the local listening ports. A common arrangement is SOCKS5 on 127.0.0.1:10808 and HTTP on 127.0.0.1:10809, but your build may use different values. Applications configured manually must use the actual values shown in v2rayN.
Use a layered verification routine:
- Confirm the correct group is selected.
- Confirm the intended server row has the active marker.
- Confirm the Xray or selected core is running without a startup error.
- Confirm the system proxy or TUN mode is enabled according to your intended setup.
- Open a test website or application and check the v2rayN log for a new connection entry.
Manage multiple providers without mixing their nodes
Multiple subscription groups are useful when providers serve different regions, when one plan is a backup, or when you need to compare reliability. Keep each provider in its own group instead of combining URLs into one record. A group should have one clear source and one understandable update history. This makes it easier to determine whether a failure came from the provider, the local network, or the selected node.
Use a consistent naming convention. A practical format is Provider - Plan - Role, such as Provider-A - Standard - Main and Provider-B - Premium - Backup. Avoid renaming groups repeatedly after importing them, because screenshots, logs, and scheduled update decisions become harder to interpret. If two providers return identical server names, the group label is the most reliable way to identify the source.
Update groups one at a time when diagnosing a problem. First select Provider-A Main, update it, and record the result. Then repeat for the backup group. Updating everything at once is convenient for routine maintenance, but it makes a failed request harder to associate with one provider. Keep the active server unchanged while updating unless the provider has removed that server; this lets you distinguish “the list refreshed” from “the active connection changed.”
Why is the group saved but the server list empty?
Saving only creates the local group record. Select the group and run Update Subscription; then inspect the log for an HTTP error, an empty response, or an unsupported format.
Should I create a new group every time the provider changes the URL?
Usually no. Edit the existing group and replace its URL if the provider confirms that the new address belongs to the same plan. Create a separate group when the plan, region, or provider is genuinely different.
Why does an update fail unless a node is already connected?
The provider endpoint may be unreachable directly. Select an already working node, enable the update-through-proxy option if available, and retry. Disable that option again if direct updates work normally.
Can I edit an imported VLESS or VMess row permanently?
You can edit it for a temporary test, but a later subscription refresh may overwrite the change. Keep a permanent custom configuration as a separate manual server instead.
Troubleshoot common subscription update problems
Start with the log rather than repeatedly pasting the URL. The first meaningful error usually identifies the layer that failed. A timeout may indicate that the provider endpoint is blocked or slow; an HTTP 401 or 403 commonly indicates an invalid, expired, or unauthorized subscription token; a successful HTTP response with zero servers may indicate an empty plan, an incorrect format, or a provider-side generation problem.
HTTP 401 Unauthorized
HTTP 403 Forbidden
request timeout
empty subscription response
failed to parse subscription
no available server
For a timeout, test whether the provider page or subscription endpoint is reachable in the same network environment, then check whether the URL was copied completely. Do not infer that every imported node is broken when the update request itself never returned. For an authorization error, sign in to the provider account and verify that the subscription has not expired or reached its device limit. For a parsing error, ask the provider for a V2Ray/Xray-compatible subscription format rather than changing random core settings.
When an update succeeds but old rows remain, check whether the interface is displaying another group or a combined server view. Some builds retain old configurations until the group is refreshed or removed according to the selected update behavior. Compare the group name, update timestamp, and server count. Do not delete all groups as a first response; doing so removes useful evidence about which source was working previously.
Protocol compatibility is a separate issue from subscription management. An imported VLESS row can still fail if its address, port, UUID, transport, SNI, fingerprint, security mode, or flow does not match the server. VMess and VLESS are different protocols, and changing one protocol label to another will not repair an invalid configuration. If only one node fails while other nodes from the same update work, inspect that node’s parameters or report it to the provider.
Finally, remember that a successful subscription update does not guarantee application traffic is using the new node. Confirm the active marker, local port, system proxy state, and core log together. Once the group, server, core, and local traffic path are all verified, future maintenance becomes simple: update the relevant group, test a suitable row, activate it, and record any change that affects connectivity.