How to Manage Multiple Shadowrocket Subscriptions: Groups, Sorting, and Duplicate Nodes

1. Understand subscriptions, nodes, and policy groups

A subscription URL is used to retrieve node settings; a node is a server entry used to connect after import. One subscription can contain multiple nodes, and the same node may appear in two subscriptions. Duplicate-looking entries do not necessarily mean something went wrong during import—the two sources may actually return identical connection settings.

Groups shown by subscription source in Home help you manage which source an entry belongs to. Policy groups in Config, by contrast, determine the outbound connection used by rules. These are separate settings. Renaming a subscription does not create a policy group or change the policy referenced by DOMAIN-SUFFIX or FINAL.

When managing subscriptions, keep your working Config and current node selection unchanged. Don’t change rules, adjust DNS, and delete subscriptions all at once; if the connection fails, it will be difficult to identify the cause. Proxy, Direct, Config, and Scene under Global Routing do not deduplicate subscriptions, either. Changing the routing mode will not resolve duplicate sources.

2. Group subscriptions by source and import them one at a time

Name groups by source and purpose—for example, “Source A · Primary” and “Source B · Backup.” Avoid names based only on regions such as “Hong Kong” or “Japan,” since multiple subscriptions may cover the same region. A region alone won’t tell you which subscription to update or delete later. A and B are simply labels for managing your own sources.

1. In Home, review existing subscriptions and manually added nodes. Note which source each currently used entry belongs to. If the same link is already there, update the existing subscription instead of importing it again.
2. Get the complete subscription URL from your own provider. Use the add option in Home to import it as a subscription, and make sure its type is Subscribe. Don’t paste the full subscription URL into a single node’s server address field.
3. In the subscription editor, enter a recognizable name or note. If the interface has a Remarks field, use it to record the source label. Controls may be arranged differently across platforms; use the fields shown in your version.
4. Import one subscription at a time. Confirm that its nodes appear under the source before importing the next one. If you paste in multiple sources at once and check afterward, it will be harder to tell which source each duplicate belongs to.
5. Return to Home and check the node count and names under each source. A subscription URL might look like https://example.com/sub?token=xxxx; this is a dummy value and cannot be used to connect.

3. Treat list sorting and connection selection separately

Sorting changes the order in which entries appear; it does not switch the active node. Sorting by name works well for consistent region and purpose labels. Sorting by latency can help compare test results on your current network. Results vary with the test time, network, and destination, so a single low-latency result is not proof of consistently faster performance.

If your current platform or interface doesn’t offer manual subscription reordering, there’s no need to keep deleting and reimporting subscriptions just to arrange them. Use consistent source names to narrow your search, and choose from the sorting options available in the current interface. With many nodes, collapsing sources you aren’t using is easier to manage than merging everything into one long list.

4. Compare settings to find duplicates—don’t rely on node names

To identify a duplicate, compare at least the protocol, server address, port, and authentication details, then check protocol-specific fields. For example, with Trojan, compare SNI and TLS settings too. Two nodes with the same server address and port may still differ in password or SNI, so they cannot be assumed interchangeable. Conversely, entries with identical connection settings may be duplicates even if their display names differ.

1. First, check whether the same subscription was imported twice. If two sources have the same link and return the same set of nodes, you usually only need to keep one. Before deleting either, confirm that the one you keep updates successfully.
2. If two different subscriptions contain some of the same nodes, keep track of which source each belongs to. To reduce clutter in your everyday searches, collapse the backup source rather than immediately deleting every entry with a matching name.
3. Compare the connection settings of each suspected duplicate. Resolving two domains to the same IP does not prove they are duplicates; shared endpoints or different TLS settings can make that comparison misleading.
4. Check whether any Config policies reference a node by name. Before deleting a referenced entry, update the relevant policy to use the entry you’re keeping, then verify the connection.

Updating a subscription retrieves the content returned by its source. A node deleted individually from a subscription may reappear after the next update, and local name changes may also be overwritten. To avoid persistent duplicates, prioritize removing a duplicate subscription entry or check the returned content with your provider. Don’t rely on deleting nodes one by one as a permanent filter.

5. Safely update or remove an inactive subscription

A single failed update does not mean a subscription is inactive. The current network may be unable to reach the subscription URL, its token may have changed, or the provider may be returning an error. Fetching a subscription and connecting to a node are separate operations: an old node may still work even when the subscription URL is invalid, and a successful update doesn’t mean every returned node will connect.

1. In Home, update the affected subscription on its own. Note the error message and check whether other sources are failing too. Don’t start by clearing all subscriptions.
2. Check that the original URL is complete, especially that query parameters haven’t been cut off by a messaging app. For links containing a token, verify them only with your own provider.
3. Check Settings → Subscribe → Update via Proxy only if the subscription URL needs to be accessed through a proxy. Before enabling it, make sure a working proxy connection is available; don’t create a circular dependency on the source that is already failing.
4. If the update succeeds but returns no nodes, first check the content returned by your provider, your account status, and the subscription type. Keep details of any old entries that still work. Don’t repeatedly delete and reimport before you know the cause.
5. Once you’ve confirmed that a source has been discontinued or replaced by a new link, verify the replacement subscription first, then delete the old one. Afterward, check the current node in Home and policy references in Config.

Before deleting, read the confirmation dialog carefully. Deleting a node, removing a subscription entry, and removing the nodes associated with that source may be separate actions. Follow the prompt on your current screen; don’t assume that removing an entry will handle all related content the same way.

6. Common questions about managing multiple subscriptions

After organizing your subscriptions, keep a management note without full tokens or passwords. Record each source label, its purpose, whether it’s still in use, and which policies depend on it. For future maintenance, update one source at a time, verify the connection, and only then remove anything. This keeps subscription content, list sorting, and routing policy issues separate. For rules and policy fields, see Configuration Field Reference; for routing modes, see Proxy Mode Guide.