v2rayN Subscription Setup: How to Add Groups Step by Step

Adding a subscription to v2rayN is more than pasting a URL and waiting for a list of servers to appear. The subscription URL is usually managed as a subscription group, while each imported server becomes an individual profile inside that group. Understanding this relationship makes it easier to update nodes, separate providers, rename groups, remove expired entries, and select the correct profile when you are ready to connect.

This Windows walkthrough uses the v2rayN 7.x interface as the reference. Menu names can differ slightly between minor releases, and a provider may use a subscription format that contains VMess, VLESS, Trojan, or other supported profiles. The subscription itself supplies server data; it does not automatically guarantee that every imported node is available or that the system proxy is already enabled.

Understand subscription groups and node profiles

In v2rayN, a subscription group is a container for a remote subscription URL and the profiles downloaded from that URL. The group normally has a name such as “Provider A” or “Monthly Plan.” After an update, the individual VMess, VLESS, Trojan, or other server entries appear under that group in the main node list. Selecting a node does not change the subscription URL; it only chooses which imported profile the core will use for the next connection.

This distinction is useful when several nodes look similar. The group identifies where the configuration came from, while the node name usually identifies a location, route, bandwidth tier, or server label. If a provider publishes twenty profiles, you do not need to create twenty subscription entries. Add the URL once, update the group, and choose among the resulting profiles.

• Subscription group: Stores a provider label and one or more remote subscription addresses.
• Imported node: A usable-looking server profile generated from the subscription response.
• Selected node: The profile currently chosen for the next core start or connection attempt.
• Local proxy: The HTTP or SOCKS listener on your Windows computer, often using ports 10809 and 10808.

A successful subscription update only proves that v2rayN received and parsed a response. It does not prove that every node can complete a TLS handshake, authenticate successfully, or reach the destination network. Treat updating and connecting as two separate checks. First confirm that the group contains fresh entries; then test one or more nodes from that group.

Add a subscription group in v2rayN

Before opening v2rayN, copy the subscription URL into a temporary plain-text location and check that there are no leading spaces, missing characters, or line breaks. Subscription links often contain long tokens, symbols, and URL parameters. A single omitted character can produce a server error or an apparently empty group. Keep the address private: anyone who obtains it may be able to download the same node configuration or consume the provider’s subscription quota.

1. Open subscription settings

   Start v2rayN, then open “Subscription Group” from the main window or its related menu. In some 7.x builds, the command appears as “Subscription Group Settings” or under a group-management entry.

2. Create a new group

   Choose the add or plus command, enter a short group name such as “Work Provider,” and select the subscription type if the interface asks for one. Use a name that will remain understandable after several updates.

3. Paste the URL

   Paste the complete subscription address into the URL field. If the provider gives a subscription user-agent or a special conversion format, enter it only where the provider’s instructions specify.

4. Save the entry

   Click “Confirm,” “Add,” or the equivalent save button. The group should now be visible in the subscription list even if its nodes have not yet been downloaded.

5. Update the group

   Return to the main window, select the new group, and choose “Update Subscription” or “Update All Subscriptions.” Wait for the completion message before selecting a node.

The group name is local metadata, so changing it later does not change the provider’s URL. A practical naming pattern is “Provider – purpose – renewal,” for example “Office – backup” or “Travel – main.” Avoid names such as “New Group 1,” because they make it difficult to identify the correct source when two groups contain similar locations.

Update the list and organize multiple providers

After adding the group, perform a manual update once so you can verify the address before relying on scheduled updates. In the subscription management window, select the target group and use the command that updates the selected entry. “Update All Subscriptions” is convenient when several providers are configured, but it can make troubleshooting less precise because one failed request may be mixed with several successful ones.

When the update finishes, inspect the main list rather than assuming that every displayed profile is new. Compare the number of nodes, the group label, and any provider timestamp or expiration notice. If the list is duplicated after an update, check whether the same URL was added twice under different group names. Removing the duplicate group is safer than repeatedly deleting individual nodes that will be recreated during the next update.

• One provider, one group: Use this as the default arrangement so updates and expiration checks remain clear.
• Separate purposes: Keep work, travel, backup, or testing subscriptions in different groups when their routing requirements differ.
• Do not edit imported nodes unnecessarily: A manual change may be overwritten during the next subscription update.
• Keep a backup only when appropriate: Exported configuration files can contain credentials, UUIDs, passwords, or private keys, so protect them like the original subscription.
• Remove expired groups: An old group can leave unusable profiles in the list and make automatic selection less reliable.

Some providers return a base64-encoded subscription body, while others return a structured response that v2rayN parses directly. You generally do not need to decode or modify the response manually. If an update says that the content cannot be parsed, first confirm that the provider intended the URL for v2rayN or Xray-compatible clients. A normal webpage, login page, JSON error response, or HTML payment notice is not a usable node list.

Choose the right profile before connecting

Once the nodes appear, select a profile from the intended subscription group. Start with a nearby or clearly labeled server instead of testing a random entry from the entire list. Location names alone are not a performance guarantee, but they give you a consistent baseline. If the provider includes latency, load, or region labels, use them as hints rather than as proof of actual browsing performance.

The protocol and transport shown in the node details can explain compatibility problems. A VLESS profile may depend on a specific server name, Reality public key, short identifier, fingerprint, or flow setting. A VMess profile may depend on its UUID, alter ID behavior, network type, path, host, and TLS settings. These values normally arrive from the subscription and should not be casually changed. If one imported profile fails while another works, compare the profiles and ask the provider whether the failing entry is still active.

After selecting a node, start the core or use the connection command provided by your v2rayN build. Confirm that the client reports a running core and that the local HTTP or SOCKS listener is available. If system proxy mode is enabled, applications that respect Windows proxy settings should use the local listener. A browser or tool configured with a different proxy address may continue to connect directly or fail altogether.

Test in a controlled order: first check the v2rayN log for a successful outbound connection, then open a simple HTTPS page, and finally test the applications that matter to you. A latency test is useful for comparing nodes, but it is not the same as a complete web request. A node can show a low delay while suffering from packet loss, DNS problems, TLS failures, or unstable throughput.

Troubleshoot failed updates and empty groups

When no nodes appear, do not immediately delete the group and start again. Open the update result or v2rayN log and classify the failure. A timeout usually points to reachability or routing; an HTTP 401 or 403 usually indicates an expired token, account restriction, or required authorization; a successful HTTP response with zero nodes may indicate an incompatible format or an expired subscription. The exact status and response type are more useful than the generic phrase “update failed.”

• Timeout while fetching: Test the subscription address in a browser only to confirm basic reachability, then try updating through an existing working proxy if available.
• HTTP 403 or 401: Check account expiration, access limits, copied tokens, and whether the provider requires a particular user-agent or client format.
• Invalid content or parse error: Confirm that the response is a supported subscription format rather than an HTML login page or an error message.
• Nodes appear but cannot connect: Check the selected profile’s address, port, TLS or Reality fields, local clock, core version, and the provider’s service status.
• Connection works but applications stay offline: Confirm that system proxy mode is enabled and that the application is not using a separate manual proxy configuration.

It is also useful to test one known-good profile after every major change. If you update all groups, switch cores, alter routing, and change local ports at the same time, the resulting failure becomes difficult to isolate. Keep the first successful setup simple: one subscription group, one selected node, the default local ports, and ordinary system proxy mode. Add TUN mode, custom routing, or multiple providers only after this baseline works.

Maintain groups without losing the working setup

A subscription list is dynamic. Providers may add, rename, relocate, or remove servers, and a node that worked last week may no longer be available. Set a routine that matches your usage: update manually when troubleshooting, update on a reasonable schedule for everyday use, and avoid refreshing repeatedly when the provider has rate limits. Excessive requests can trigger temporary restrictions without improving the node list.

Before changing the client core or importing a large new subscription, record the group name, the selected node, the local HTTP and SOCKS ports, and whether system proxy mode is enabled. Do not publish screenshots that reveal the complete subscription URL, UUID, password, or private key. If a URL is accidentally exposed, ask the provider to issue a replacement rather than assuming that renaming the local group protects it.

1. Update the intended subscription group and confirm the result.
2. Remove duplicate or expired groups from the local list.
3. Select a clearly identified node and check its imported parameters.
4. Start the core and confirm that the local listener uses the expected port.
5. Test one website and one important application before changing advanced routing.

For a fresh installation, the simplest reliable path is to add one valid subscription, update it, select one node, and verify a normal system-proxy connection. Once that baseline is stable, you can add a backup provider, use group names for clearer organization, compare protocols, or configure TUN and rule-based routing. Subscription management then becomes a repeatable maintenance task rather than a cycle of deleting profiles and pasting the same URL again.