Shadowrocket Subscription Management: Grouping, Sorting, Removing Expired Sources, and Deduplicating Servers

Separate subscription sources, server entries, and the active connection

Multiple-subscription management becomes confusing when three different layers are treated as one. A subscription source is a URL provided by a service the user already has; a server entry is a specific record written to the Home list after an update; and the active connection is the entry selected in Home and handed to the system VPN configuration. Deleting one layer does not necessarily change the other two.

For example, one subscription may generate more than a dozen server records, with only one selected. Deleting a single server record does not delete the subscription source; if the source remains, that record may return during the next update. Conversely, after removing a subscription source, check whether local entries associated with it are still retained.

Create groups by source and name each subscription clearly

Open Settings → Subscribe and review each saved subscription. Names should identify the source and purpose; avoid vague labels such as “Subscription 1” or “Backup.” When multiple sources contain servers with the same name, the source name is the first clue for determining ownership.

When adding a new source, use only a subscription URL you already have. A placeholder used to illustrate the format can be written as https://example.com/sub?token=xxxx. Query parameters in a URL often carry identity or authorization information. Preserve the complete string when copying it; do not manually remove ?token=xxxx.

1. Open Settings, go to Subscribe, and record every existing source and its name.
2. Trigger updates one source at a time. After each update, check whether the corresponding group or entry count in Home changes.
3. If a source name is unclear, rename it before deleting or deduplicating anything. This prevents two different sources from being mixed together.
4. After the update finishes, return to Home and check that the selected server still belongs to a source you intend to keep.

Run the same Connectivity Test before sorting by latency

Latency sorting is meaningful only when test conditions are consistent. Keep the same network connection method, run a latency test or Connectivity Test in Home for the servers you want to compare, and sort by the results from that run. Do not mix values measured on Wi-Fi yesterday with values measured on cellular today.

Test results generally fall into three categories: a specific millisecond value means the target responded during this run; timeout means no valid response arrived within the test window; no result or a test that remains in progress calls for checking the current network, subscription parameters, and app permissions. A single timeout is not enough to declare a server permanently unavailable; wait a while and test it twice more.

• Low latency and reachable: Keep it in the frequently used group and open the target service to verify the connection in practice.
• Higher latency but stable responses: Move it to the backup group rather than deleting it based on the millisecond value alone.
• Repeated timeouts: Check the protocol, host, port, TLS, and authentication fields before deciding whether to remove it.
• Same name but different latency: Check the host and port; identical display names do not mean identical server parameters.

Also check Global Routing during testing. Proxy sends traffic through the active proxy server, Direct connects directly, Config follows the rules in the current configuration file, and Scene operates according to the scene settings. If the mode is Direct, a page loading successfully does not prove that the selected server is active. With Config, check the matching order of DOMAIN-SUFFIX, GEOIP, IP-CIDR, and FINAL.

DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY

When removing an expired subscription, use the source as the bulk-cleanup boundary

When processing expired entries in bulk, the clearest boundary is the subscription source, not the server display name. In Settings → Subscribe, first confirm that the source has stopped updating, returns empty content, or is no longer needed, then remove it. Before deleting, record any manual servers that must remain so source-generated entries are not confused with manually added ones.

Button labels may change as the app interface shown on the current App Store page changes, but the review order remains the same: open the subscription record, verify the URL and name, confirm the source to remove, read the deletion confirmation, then return to Home and check associated entries. If the confirmation asks whether to process local servers as well, decide based on whether those entries are still needed rather than confirming rapidly.

1. In Home, note the protocol, host, and port of the currently selected server. If necessary, switch first to a server you intend to keep.
2. Go to Settings → Subscribe, open the target source, and run one update to confirm the failure is not a temporary network issue.
3. Verify the subscription name and complete URL to ensure the item being deleted matches the recorded expired source.
4. Delete the source, then follow the confirmation dialog to decide whether to process local entries generated by that source as well.
5. Return to Home, run Connectivity Test again, and check whether entries from the original source remain in the list.

Remove duplicate servers by comparing connection parameters, not names

The most common sign of duplicate servers is two subscriptions producing the same display name, but the name alone is not enough. One name may point to different hosts or to different ports on the same host. A true duplicate should be compared by protocol, server host, port, and authentication parameters at minimum. For protocols using TLS, also compare fields such as SNI and ALPN; when transport settings are used, check path, host, and other corresponding values.

For Shadowsocks, compare the host, port, encryption method, and password. VMess and VLESS also require checking the UUID, transport method, and TLS settings. For Trojan, compare the password and SNI. For Hysteria2, verify the host, port, authentication details, and relevant TLS fields. For WireGuard, compare the public key, Endpoint, Allowed IPs, and local address. Records with different parameters should not be deleted as duplicates even when their names match.

Example deduplication key:
Protocol | Host | Port | Authentication parameters | Transport method | TLS/SNI

Trojan | edge.example.com | 443 | password-A | TCP | edge.example.com
VLESS  | edge.example.com | 443 | uuid-B     | WS  | cdn.example.com

If two sources genuinely contain the same server, keep the record with successful updates, a clear source label, and complete parameters. After deleting the other record, immediately update its original subscription to verify the result. If the duplicate returns, that source still maintains it. You can keep the source and accept the duplicate display, or adjust the content within the service provider’s subscription management options; do not create a superficial difference by arbitrarily changing the password, port, or UUID.

After updating subscriptions, check On Demand and rule status

After organizing subscriptions, run a complete verification cycle. Select the server you are keeping in Home, run Connectivity Test, and then confirm the current Global Routing mode. If you normally use Config, open the current configuration and verify that rules are matched from top to bottom, with FINAL handling requests that match nothing.

If On Demand is enabled, find it under Settings → On Demand. This setting can trigger connections or disconnections based on network conditions, so testing multiple subscriptions may cause the connection state to change automatically. During troubleshooting, record the current On Demand conditions, including the actions used on Wi-Fi and cellular networks, so automatic switching is not mistaken for server failure.

• Confirm that Settings → Subscribe contains only sources you still need and can identify.
• Confirm that the currently selected server in Home belongs to a retained source and complete an actual connection test.
• Confirm that duplicates were checked against all relevant parameters rather than using the display name as the sole deletion criterion.
• Confirm that Global Routing, Config rules, and On Demand conditions still match your established workflow.
• For every new subscription, name the source first, then update, test, and deduplicate it so the list keeps clear boundaries.