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

Distinguish subscription sources, node names, and policy groups

A subscription is a source for retrieving connection parameters in bulk; each node is one connection entry. Groups shown by source in Home help organize the list. Policy groups in Config determine how rules select an outbound route. Moving a source to the top of the list does not make requests prefer it or change your rules automatically.

Before organizing anything, review your existing subscriptions and notes in Home, then open Config to check the configuration in use. If the configuration directly references a node by name, deleting or renaming it may leave the reference without a matching target. If the configuration collects nodes using filters, check whether a rename changes the filter results.

• Subscription source: Identifies where a batch of parameters is updated from, making it the first place to check for duplicate imports.
• Node name: Identifies an entry in the list; matching names do not mean the parameters are identical.
• Policy reference: Determines which requests use a node and must be checked separately in the active Config.

Group by source: keep one management entry per URL

Give existing subscriptions a consistent way to identify them, such as notes like “Everyday” and “Backup” for your own use. These are organizational examples, not service recommendations. Open the relevant subscription for editing in Home and check its URL and note. Field names may vary by interface; do not replace the original URL just to change the display name.

Adding the same subscription URL twice creates two management entries. Even with different notes, both may retrieve the same content when updated. When cleaning up, compare the full URL, not just the domain: different paths, query parameters, or access credentials may point to different content. Treat the full subscription URL as sensitive information; do not include it in public screenshots or shared records.

If two subscriptions overlap only partially, keep their sources separate for now. This makes it easier to pinpoint a subscription if an update goes wrong and distinguish overlapping source content from duplicate imports. Converting everything into manual entries adds maintenance work when parameters change later.

Sort nodes: choose whether to sort by name or test results

Sorting helps you find and compare nodes; it does not guarantee connection quality. Use the sorting option available for the target group in Home. Sort by name for consistent identification, or run a latency test first if you want to compare response times on your current network. Check the scope before sorting so you don’t mistake a change to the entire list for one affecting only a single source.

1. Expand the source you want to organize, confirm the currently selected node, and note its name and source.
2. If you need to compare latency, run the tests on the same network. Don’t compare results from Wi-Fi with results from a cellular network.
3. Choose an available sorting option and check whether only the node’s position changed or whether the selected node changed too.
4. Check the order again after updating a subscription; changes to the returned content or sorting settings may affect how the list is displayed.

A latency value reflects the test method and network conditions at that time. It is not a measure of sustained download speed, nor does it prove that a particular website is accessible. If an entry times out, first check its protocol parameters and your current network instead of assuming the entire subscription is inactive.

Remove duplicate nodes: compare connection parameters, not just names

Duplicate entries commonly come from three sources: the same subscription added more than once, a node from a subscription imported separately, or overlapping connection parameters across different subscriptions. Check for duplicate subscriptions first, then manual copies, and finally entries from different sources. This helps avoid mistaking overlapping upstream content for an app storage issue.

For example, two entries may both use edge.example.com:443, but that alone is not enough to delete one. They may use different protocols, authentication details, or TLS and transport settings. The domain here illustrates how to compare entries; it is not connection configuration.

• Compare protocols first: Different types, such as Shadowsocks, VMess, VLESS, and Trojan, are not the same entry, even when they share an endpoint.
• Then compare authentication: Check the Password, UUID, key, or other details used by the protocol. Don’t copy credentials into public documents.
• Check transport settings: If the protocol uses TLS or other transport options, compare the server name, path, and related parameters as well.
• Finally, compare sources: Even if the parameters are identical, confirm which update source you want to keep before deleting a duplicate.

Keep distinguishing labels for entries with the same name but different parameters. Entries with different names but identical parameters are candidates for duplicates. Config may also reference node names, so don’t rename entries in bulk before investigating. Record which entries correspond, make a small change, verify it, then continue with the next batch.

Delete an inactive subscription: distinguish a temporary update failure from one you no longer use

One failed update does not prove that a subscription is inactive. Check your network, the full subscription URL, and the status provided by your service provider, then try updating that subscription again. A network timeout, unparseable content, and invalid credentials are different problems. Keep the interface message and address the specific cause instead of repeatedly deleting and re-adding the subscription.

1. Choose which source to keep. Confirm that backup connection parameters work and note which group contains the currently selected node.
2. Save any necessary configuration. Keep the subscription URLs you already have and a necessary backup of the current Config. Backups may contain credentials.
3. Confirm what you’re deleting. Delete the target subscription from Home, read the confirmation prompt, and distinguish the entire source from a single node to avoid removing a group you still use.
4. Check what remains. Return to Home to confirm that the source was removed, then open Config and check for policy references to its old name.
5. Test the connection. Select a node from the source you kept, connect, and test the destination you originally needed to access.

Deleting a local subscription entry does not cancel a service with its provider. If you delete a single node from a subscription but it is still included in the content returned by that subscription, a later update may import it again. To keep the list shorter over time, check whether the current interface offers filtering options that suit your needs, or adjust the returned content through the management interface for a service you already use. Deleting an entry locally does not permanently change the source content.

After organizing subscriptions, check Global Routing and rule references

Organizing the list does not synchronize routing settings. Return to Home and check Global Routing: Proxy, Direct, Config, and Scene represent different routing modes. You do not need to change this setting to organize subscriptions. If you’re testing rule-based routing, confirm that the intended Config is in use rather than treating results in Direct mode as a reflection of a proxy node.

• Check the selected node: Make sure the currently selected node still exists after the deletion.
• Check rule targets: In Config, confirm that the policies referenced by rules such as DOMAIN-SUFFIX, GEOIP, and IP-CIDR are still available, and check the fallback target for FINAL.
• Check update results: Update the subscription you kept once and see whether duplicate entries return or names change.
• Check automatic connections: If you don’t want network changes to trigger a connection while you organize subscriptions, review the existing settings under Settings → On Demand first. Restore the behavior you need when you’re done.

Change one type of setting at a time: remove duplicate sources first, then adjust names and sorting, and finally change policy references. If you change sources, node names, and routing settings all at once, it becomes difficult to tell whether a problem comes from changed parameters, a name mismatch, or a different routing mode.

Common questions about managing multiple subscriptions