If you already have subscriptions from service providers, organize them by source before changing the list order or removing duplicates. This guide explains the difference between subscriptions, nodes, and rule configurations in Shadowrocket, and covers naming with Remarks, updating one subscription at a time, checking for duplicate nodes, and what to verify before deleting. The key is to confirm the source before making changes; matching names do not necessarily mean matching connection settings.
1. Understand the difference between subscriptions, nodes, and Config
A subscription is a source for retrieving a set of connection configurations; a node is one specific connection configuration within that set. A subscription can contain multiple nodes, and the same node may appear in Home through different subscriptions or as a separate import. So two similar entries in Home do not automatically mean something was imported incorrectly.
Config manages rule configurations, while Settings manages app settings. Organizing subscription names in Home does not change the rules or policy groups in Config. If your rules refer to nodes by name or filter nodes by name, check those references after renaming, updating, or deleting entries.
Here, “grouping” means identifying entries by subscription source, not creating policy groups that rules can select automatically. To route traffic by domain, check the rules and policy settings in Config; subscription Remarks alone cannot do that.
2. Use Remarks to identify sources and check for existing subscriptions before importing
Give each subscription a consistent Remark that identifies its source, and distinguish the subscription’s identity from the nodes’ purpose. For example, use “01-Source A-Daily” and “02-Source B-Backup” as subscription Remarks, while leaving the nodes’ original names unchanged for now. The prefixes help you identify entries; they do not make the app sort them automatically.
- Open Home and review the existing subscription groups. Open the relevant subscription’s edit screen and check whether its URL is already saved.
- If you need to add a subscription, use the add option in Home, set Type to Subscribe, and enter a subscription URL you already have.
- Enter a short, recognizable source name in Remarks. After saving, check that the expected nodes appear under the subscription.
- To rename an existing subscription, edit its Remarks. Don’t import it again just to change how its name appears.
Subscription fields to check
- Type
- Choose Subscribe when adding a subscription; the initial value depends on what the current app displays.
- URL
- Use the complete URL you already have. There is no universal default URL.
- Remarks
- A suggested format is “01-Source A-Daily”; the default content depends on what the current app displays.
- Check after saving
- Make sure the Remark matches the subscription and its nodes, rather than checking only whether a new group appeared.
Field locations depend on the current app interface. Don’t mistake a node edit screen for a subscription edit screen.
Naming recommendations
- Source label
- Use consistent names such as Source A and Source B instead of labels like “New subscription.”
- Purpose label
- Use personal labels such as Daily or Backup; don’t use Remarks to make claims about quality.
- Numeric prefix
- Use a consistent format such as 01, 02, 03 to make the list easier to review manually.
- Original node names
- Keep them when organizing the list for the first time so you can compare them with the content returned by the source.
This is a manual naming convention, not a built-in grouping or sorting rule.
Subscription URLs may contain access tokens. When checking for duplicate sources, you can compare the full URLs on your device, but don’t share the URL, its QR code, or the full edit screen with others. Even if two URLs have the same domain and path, different tokens may grant different access. Don’t merge them based only on how they begin.
3. Sort based on the options available in the current list; numbering is not an automatic rule
When organizing the order, handle subscription group positions and the order of nodes within each group separately. First confirm which level you are working with, then use the sorting or editing options actually available in the interface. Moving a node in the node list does not mean all subscription groups have been reordered.
- Manual positioning: If the current list offers drag handles in edit mode, move frequently used items to a convenient position. If that option isn’t available, don’t assume you can drag items.
- Sort by name: If the current interface offers sorting by name, standardize your names first, then choose that sorting option. Numeric prefixes do not activate a sorting method on their own.
- Latency results: Test results reflect the network conditions at that moment. They do not identify the source or indicate sustained download speed.
- Order after updating: The source may return a different set of nodes. After each update, check the positions of frequently used nodes and the currently selected node.
In short: make source Remarks consistent before organizing node positions
Label your main subscription “01-Source A-Daily” and record the original names of frequently used nodes. If their positions change after an update, you can find them again by subscription source instead of relying on their row numbers.
If Config policies refer directly to node names, avoid adding prefixes to multiple nodes just to change their order. A safer approach is to update the subscription-level Remarks first, then check how policies reference nodes. Change node names only after confirming that nothing depends on them.
4. Update one subscription at a time: record, refresh, and verify
Updating a subscription retrieves the node content provided by its source; it does not simply test whether existing nodes are online. The source may add or remove nodes or change connection settings, so changes in names or node count do not necessarily indicate a local problem. Before updating, note the group’s current node count and the name of the node in use.
- In Home, find the subscription you want to update and use its update option. The option’s name and location depend on what the current app displays.
- Wait for the operation to finish and check for a success or error message. Don’t trigger multiple updates in quick succession.
- Compare the group before and after the update. Check whether frequently used nodes are still there and whether new entries belong to that source.
- Check which node is selected. If the old node was removed, select another valid node, then review any policies that depend on it.
- Finish checking one group before updating the next to keep any issue isolated to a single source.
A timed-out update means only that this retrieval did not finish; it does not prove that all nodes are unavailable. Check the device’s current network, make sure the subscription URL is complete, and see whether the source has reported any access changes. Then review the error message from the app. Existing nodes may connect successfully even when the subscription URL cannot currently be reached.
5. Remove duplicate nodes by comparing connection settings, not just names
Nodes with the same name may use different servers, ports, or transport settings; differently named nodes may use the same connection configuration. Before removing anything, compare the settings in each node’s edit screen and note which subscription each came from. Don’t delete entries just because their names look similar if their protocols or authentication details differ.
| Check | What to compare | How to decide |
|---|---|---|
| Subscription source | Was the same complete subscription URL imported more than once? | Resolve duplicate subscriptions first to avoid deleting nodes individually only for them to reappear after an update. |
| Protocol and address | Do Type, server address, and port match? | For example, ports 443 and 8443 are different; matching names alone don’t prove that entries are duplicates. |
| Authentication details | Compare fields such as passwords, UUIDs, or keys as required by the protocol. | Keep entries with different authentication details separate, and don’t disclose those details while checking them. |
| Transport and TLS | Transport method, path, Host, SNI, and TLS-related settings | The same server and port can still use different connection methods. |
| Rule references | Do rules in Config refer to node names or name-based filters? | Before deleting, make sure no references will point to an item that no longer exists. |
The ports above are examples to illustrate how to compare entries, not a recommendation to change ports to a particular number. Shadowsocks, VMess, VLESS, Trojan, Hysteria2, and WireGuard do not all use the same fields. Check the settings for the node’s actual protocol and keep its existing valid parameters.
If the same source was imported more than once, first keep the group with clear Remarks and confirmed references, then delete the extra subscription. If the entries come from different sources, even identical connection settings may have separate update relationships worth keeping. Deleting a node locally does not stop its source from providing it again.
- Same name, different settings: keep both and identify them by their source Remarks.
- Duplicate imports from the same source: compare the complete subscription URLs, then resolve the issue at the subscription level.
- A separately imported node duplicates one in a subscription: first check whether the separate entry is still needed, then decide which one to remove.
- A deleted node reappears after updating: the subscription is still providing it. Reconsider how you manage the local entry instead of deleting it repeatedly.
6. Before deleting a subscription, check the selected node and policy references
Deleting a node and deleting a subscription are different actions. Before proceeding, confirm whether you have selected a group or an individual entry, and read the confirmation message. If you are using a node from that group, consider switching to another verified node first so the connection target remains clear after deletion.
- In Home, open the edit or management options for the subscription you want to delete. If the interface offers deletion by swiping, first confirm which item you are swiping.
- Check the subscription’s Remarks and source URL to make sure it isn’t the group you intend to keep.
- Read the deletion confirmation and check whether it will also remove the nodes in the group. The exact scope depends on the current app prompt.
- After deleting, return to Home to check the groups and selected node, then open Config to review any related policy references.
- To restore a subscription, re-import the original URL that you have saved securely. Deleting a local entry does not cancel your service with its source.
When checking a connection, also note which option is currently selected under Global Routing: Proxy, Direct, Config, or Scene. These choices determine how requests use an outbound connection; they do not manage subscription sources. If a request isn’t using the expected node, check the routing selection and configuration instead of continuing to delete subscriptions.
7. Frequently asked questions about managing multiple subscriptions
Why didn’t adding 01 or 02 to a Remark change the order?
The number is just part of the name. First check whether you changed the subscription’s Remarks or a node name, then see whether the current list offers sorting by name or manual reordering. If neither option is available, use the numbers to identify entries; they do not configure automatic sorting.
Why did a duplicate node come back after I deleted it and updated?
The node may still be included in the content returned by its source. First check whether the same subscription was imported more than once. Otherwise, keeping a subscription’s update relationship and permanently removing an entry supplied by that source are separate things; deleting it locally cannot change the remote content.
Two subscriptions contain a node with the same name. Can I just delete one?
Compare the source, protocol, server, port, authentication, and transport settings, then check references in Config. Matching names alone are not enough to establish that entries are duplicates. Delete an extra group at the subscription level only after confirming that the same source was imported more than once.
Do I need to delete a subscription if I only want to stop using it temporarily?
Usually, you can keep the subscription and select another node. If you use Config or Scene, also check the relevant policy selection. This preserves the source information so you won’t have to import it again when you want to use it. Delete a subscription when you’ve confirmed that you no longer want to keep the local entry.
After organizing your subscriptions, keep a personal record of their Remarks, source identifiers, original names of frequently used nodes, and policy dependencies. Store complete URLs containing tokens and authentication details securely and separately. Checking only what changed after each update makes issues easier to track than periodically clearing the entire list.