Organize subscriptions by source, then test and sort nodes within each group. Before cleaning up, check for duplicate subscription entries, then review duplicate nodes. This guide is for users who already have subscriptions from their own service providers. Follow these steps: record each source, import subscriptions one at a time, check for updates, remove old entries, and verify connectivity. Shadowrocket is available for iPhone, iPad, Mac, Windows, Android, and Linux. The instructions below use the Home, Config, and Settings labels from the iPhone / iPad interface; menu locations on other platforms may differ.
1. Understand the difference between subscription sources, node lists, and Config
A subscription is a source of node details; nodes are server configurations used to connect; Config primarily contains settings such as rules. These serve different purposes: adding a second subscription does not create a second set of routing rules, and switching rules in Config does not change the subscription source. Before organizing anything, identify which layer you need to manage.
Treat each subscription as a separate source, and keep its display name, purpose, and update history. Record manually added nodes separately so you don't assume they'll be refreshed with a subscription. This site does not provide, sell, or recommend nodes, subscriptions, or service providers. The steps here assume you already have your own subscription; get its URL from your service provider.
Shadowrocket is closed-source commercial software. Buying the app does not include a service plan. The app purchase and the term of an existing subscription are separate. For iPhone / iPad system requirements, see the App Store listing. Mac versions are available for Apple silicon and Intel. See the download page for how to get Shadowrocket on each platform.
2. Import subscriptions one at a time and group them by source
Don't scan several QR codes in a row or paste the same URL repeatedly before organizing your subscriptions. Import one at a time, then confirm the source and its nodes appear in Home before continuing. This makes it easier to identify the cause if a list is empty, an import fails, or source names look alike, instead of guessing among mixed lists.
- Get the subscription URL from your service provider and record its source in a private note. Subscription URLs may contain access tokens; don't share them in public screenshots, forums, or shared spreadsheets.
- In Home, tap the add option to open Add Server. Set Type to Subscribe, then enter the full URL. Available fields vary by platform. Don't enter a subscription URL in the Address field for an individual node.
- Use a name field such as Remarks to identify the source. For example, use “01-Primary” and “02-Backup.” Numbers help distinguish sources; Shadowrocket does not switch between them automatically based on their numbers.
- Save and wait for the nodes from that source to load. Return to Home and check the group heading, node count, and parameters for at least one node to confirm that the expected subscription was imported.
- Import the next subscription. Don't add the same existing URL again as a new source; to get the latest list, update the existing source.
Keep names short and consistent; there's no need to pack every purpose and expiration detail into a node name. Names changed locally for subscription-provided nodes may be overwritten during an update. For labels you need to keep, use the subscription's source notes or your own records. Don't change tokens, parameter order, or encoding in the URL just to preserve a name.
Primary source record
- Source note
- 01-Primary
- Import type
- Subscribe
- Where to manage it
- The corresponding source in Home
- Cleanup goal
- Keep one active subscription entry
Update the existing source first; don't import it again as a substitute for updating.
Backup source record
- Source note
- 02-Backup
- Import type
- Subscribe
- What to check
- Source name and node parameters
- Cleanup rule
- Check each group separately; don't bulk-delete across groups
Two sources containing nodes with the same name does not prove they are duplicates.
3. Use consistent test conditions before sorting by latency
Sorting by latency only changes the order shown in the list. It does not rank stability or automatically change policy references in Config. Different tests measure different things: a successful TCP handshake only shows that a connection could be established along that path; it does not confirm authentication, TLS, or access to the destination website. Use the same test method and network conditions before comparing results.
- Test one subscription on the same Wi-Fi or cellular network. Don't switch networks or transfer large files during the test.
- In Home, use Connectivity Test or the latency test option available in the current interface. If you can choose a test method, use the same setting for the entire round. Don't compare results from different methods as if they were equivalent.
- Wait for the results, then use the list menu's latency sorting option. Menu locations vary by platform; use the test and sorting options available in your interface.
- Wait a little and run another test to see whether timeouts persist. Try accessing a destination through a candidate node, and note whether it completes a TLS connection and opens the target service.
- After selecting a node, check its selected state. Don't assume the first node in the list is the one currently in use.
| What you see | What it tells you | What to do next |
|---|---|---|
| The same node times out in both test rounds | No valid result was obtained under the current test conditions | Check the address, port, and network, then review the protocol settings |
| Low latency, but websites won't load | A successful test doesn't guarantee that requests will work end to end | Check authentication, TLS, DNS, and routing rules |
| Only one source times out across all its nodes | The problem appears to be limited to that source | Check whether the subscription updated successfully and whether the service is active |
| Results change significantly after switching networks | The results depend on the local network path | Record Wi-Fi and cellular results separately; don't combine them in one test round |
Bottom line: confirm connectivity before comparing latency
First rule out nodes that consistently time out or fail during real-world access, then sort the remaining nodes under the same conditions. A single low-latency result isn't a reason to bulk-delete other nodes.
4. Remove duplicate nodes: check their source, then compare connection settings
The same name doesn't mean the same connection configuration. Two nodes named “Backup” may use different addresses or ports; two differently named nodes may connect to the same server. A Trojan and a VLESS configuration at the same address, or configurations at the same address with different authentication details, should not automatically be treated as duplicates.
- The same source was imported twice: Compare the two subscription entries and their update contents first. If the import is confirmed to be a duplicate, keep one active source and remove the other instead of deleting its nodes one by one.
- Different sources contain nodes with the same name: Keep the source boundaries clear, then compare Type, Address, Port, and authentication details. Don't deduplicate based only on display names.
- The parameters appear identical: Also check TLS, SNI, transport, and related path settings. Sharing port 443 is only one matching detail; it doesn't prove the configurations are equivalent.
- A manual node duplicates a subscription node: Check whether the manual entry is intentionally kept as a different configuration. If you decide to remove one, prefer the entry that can continue to update through its original subscription and has been verified to work.
- A deleted node returns after an update: The source is still providing that entry. Deleting it locally again won't change the source content. First check whether the source was imported more than once, then manage the subscription using the method provided by your service provider.
Compare credentials on your own device. Don't share passwords, UUIDs, private keys, or full subscription URLs when asking for help. If you need to record differences, simply note “same authentication details” or “different authentication details”; there's no need to copy the actual values. Before cleanup, keep a recoverable record of the configuration and store any sensitive information in it securely.
Deduplicate by connection configuration and source, not by name alone. Deleting an entry locally in Shadowrocket does not modify the service provider's subscription content; the next update may load the node again from the source.
5. Remove outdated subscriptions and review after updates
A single timed-out update doesn't mean a subscription has expired. First check your local network and make sure the URL is complete, then confirm its status with your service provider. If the URL has changed, edit the existing source or verify the new one before removing the old source. Avoid keeping two entries with similar content indefinitely.
- Check the active connection: In Home, confirm which source the current node belongs to. If it's from the source you plan to remove, switch to another verified working connection first, so you don't discover after deletion that your current selection no longer works.
- Check rule references: In Config, look for references to specific node names or policies. After removing a source or renaming a node, review those references too; don't judge cleanup by how tidy the Home list looks.
- Delete at the right level: To remove an entire subscription, act on the source itself. To remove a single manual configuration, act on that node. Check the object and scope in the confirmation prompt before proceeding.
- Update sources you're keeping: Update subscriptions that are still in use. Check that nodes load correctly, previously removed duplicates haven't returned, and the currently selected node still works.
- Verify real-world access: Confirm Global Routing is set as intended, then test one destination that should use a proxy and one that should connect directly. Keep the conditions the same before and after cleanup to identify any new issues.
Proxy, Direct, Config, and Scene in Global Routing are routing modes, not subscription groups. Proxy and Direct can help with targeted comparison tests. Config routes connections according to the rules in the current configuration. Scene follows its configured conditions. After testing, restore the intended mode; don't leave the app in a temporary troubleshooting mode.
Settings → On Demand manages when connections are established or disconnected based on conditions. It doesn't deduplicate subscriptions or automatically switch nodes based on latency. If the connection state changes during testing, check the On Demand conditions too, so you don't mistake automatic connection behavior for a subscription update issue.
Bottom line: after deleting, update once and verify access
A list without duplicates isn't enough. Cleanup is complete only when the retained source updates successfully, the current selection works, Config references remain valid, and real-world access behaves as expected.
6. Frequently asked questions about managing multiple subscriptions
I added the same subscription twice. Do I need to delete its nodes one by one?
First, compare the two sources and their contents in Home. If the subscription was imported twice, keep the one you've verified can update and remove the other source. Deleting nodes one by one is easy to get wrong, and they may return after an update.
Why am I still using the old node after sorting by latency?
Sorting changes how the list is displayed; it doesn't necessarily change the current selection. Check the selected indicator in Home. If you're using a policy in Config, also check which policy reference is actually being used. A node at the top of the list hasn't necessarily been selected.
A deleted node came back after an update. What went wrong?
First check which source it belongs to. If the subscription still includes the node, it may be loaded again after local deletion. If the same subscription was imported twice, remove the extra entry. Don't try to deduplicate by changing random URL parameters.
My backup subscription has nodes with the same names. Can I delete them all?
Don't delete them outright. Compare the protocol, address, port, authentication, TLS, and other relevant parameters one by one. Nodes with the same name but different settings may be separate configurations. Even when the settings match, check for Config references before deciding which source to keep.
Can I keep using my existing nodes after an update fails?
A failed update alone doesn't tell you whether saved nodes are still usable. Keep the existing entries and test the current node separately from access to the subscription URL. Don't delete all the old sources just to retry an update before confirming that the new content has loaded successfully.