Subscriptions and Server Management

What a Subscription Stores

Subscribe stores an endpoint that can be requested again. Shadowrocket fetches the address, retrieves a server list, and displays the content it can parse. Each server in the list has an address, port, protocol, and authentication details; the subscription URL links those entries together. They are different things: a server may still connect even if the subscription URL has expired, and a subscription may update even if some listed servers are currently unavailable.

Before importing, make sure you have your own subscription URL—not an account-management webpage, a single share link, or a rules-file URL. A page loading in a browser does not prove it can be used as a subscription; the client needs a parseable list, not a login form, error message, or formatted webpage. Do not post URLs containing authentication details in public forums. Check them on your own device.

Add a Subscription Step by Step

1. Look for Subscribe in the add menu on Home. If the interface opens Add Server first, check whether Subscribe is available among the type options. Menu locations vary; use the interface on your device as a guide.
2. Paste the complete subscription URL into the address field and check that its beginning, ending, and query parameters are intact. Give the entry a descriptive name, such as “Daily use,” rather than using only a date.
3. Save the entry and fetch it for the first time. Once the list appears, check its subscription group and server labels. Don’t immediately add the same URL again.
4. Choose an entry you’re authorized to use and test the connection. For first-time connections and system permissions, see the quick-start guide.

This example is for identifying the URL structure only; it cannot be used to connect. The domain, path, and parameters below are fictional. A real URL may have no query parameters or use a different path. Preserve the original content when copying; do not add fields to your own URL based on this example.

https://example.com/sub?token=xxxx

Saving Does Not Mean the Fetch Succeeded

Saving an entry only means the app accepted the input locally. The first request can still fail because of network issues, an expired URL, failed authentication, or an unsupported response format. If you see a subscription name but no servers, read the error and determine whether the request failed or completed with content the app couldn’t parse. For a failed request, check the device’s network connection and whether the URL is reachable. For a parsing failure, check whether the response is a webpage, an empty list, or a configuration format that doesn’t match this entry point.

For an authentication error, return to the management page for your existing subscription and check your access and the complete URL. Don’t randomly remove or change parameters. For a certificate error, check the device’s date and the URL spelling; disabling certificate verification should not be a default fix. If the network requires a browser sign-in, complete its normal sign-in process first, then retry Subscribe once. Don’t mistake a public Wi-Fi login page for subscription content.

Three Checks After Import

First, check that the servers belong to the expected subscription so they aren’t confused with manually added entries. Second, open an entry to verify its protocol and address, without showing anyone its authentication details. Third, confirm that the active Config wasn’t unexpectedly replaced by the import. The subscription list determines which servers you can select; Config determines how destinations are handled. Check them separately—a populated list does not mean the rules are configured correctly.

Importing the same URL on different devices does not keep local labels, selections, or manual changes in sync. Treat each device as a separate copy to manage, and check the initial fetch and connection on each one. If you only have details for a single server, go straight to the next section; there’s no need to turn them into a subscription first.

Choose Type Before Entering Connection Details

Use Add Server to create a standalone server entry. Before you begin, have the complete details for a server you already have. Choose Type first, then fill in the fields for that type. Authentication and transport options vary by type. If you enter an address and then switch Type at random, some fields may reset or retain values that don’t match the new type. If information is missing, check your own server details instead of guessing from another entry’s appearance.

The address field usually takes a hostname or IP address, not a complete webpage URL. Enter the port in its separate numeric field; don’t put a path, query parameters, or notes there. If your details specify a domain, keep it rather than substituting its resolved IP: TLS identity checks and server routing may depend on the domain. With IPv6, take particular care to distinguish the separate address field in the interface from the bracket syntax used in share links.

Authentication, TLS, and Transport: What Each Does

Shadowsocks requires the encryption method and password configured on the server. A similarly named method is not necessarily equivalent. VMess and VLESS commonly use a UUID for identity, but that doesn’t make the two types interchangeable. Trojan typically uses a password and TLS settings. Whether HTTP or SOCKS5 requires a username and password depends on the server’s configuration. Enter each value in its intended field rather than putting all authentication details in Password.

TLS encrypts the connection and verifies identity; SNI supplies the server name during the handshake. The connection address, SNI, and transport-layer Host may be the same or different—use the values required by the server. Path belongs to a specific transport method; it is not the subscription URL’s path. For a handshake failure, check that these values match instead of repeatedly changing the port. Keep certificate verification settings consistent with the actual certificate requirements.

WireGuard, Hysteria2, and other types have their own parameters; don’t treat them as ordinary username-and-password setups. Fill in only the fields required for the selected type, and leave unspecified advanced options at their defaults. If your details specify a value but you can’t find a matching field, first confirm that Type and the entry point are correct, then consult the glossary for the field’s meaning. Don’t put the value in a similarly named field with a different purpose.

Find Errors with Minimal Changes

Check for spaces and line breaks before saving. Passwords may be case-sensitive, and copying can introduce invisible characters. Preserve the UUID’s hyphens and character order exactly. You can rename the entry to make it easier to identify, but don’t try to “clean up” authentication values manually. After saving, select the entry and test it, then try to access a normal HTTPS page you’re authorized to use. Check the connection and the actual request result separately.

When troubleshooting, change one category of fields at a time. For example, correct the address and port, then test again; next check authentication; finally check TLS and transport. If you change several things at once, even a successful result won’t tell you what fixed it, making the same problem more likely after a future update. If the original entry still works, create a separate copy labelled “Checking” and test it before deciding which entry to keep. This avoids overwriting parameters in use.

Manual entry sets up a single server’s parameters; it does not create rule-based traffic routing. Once the entry works, check Global Routing and the active Config as well. If only some websites fail, troubleshoot rules and DNS rather than changing authentication details that have already been verified.

A QR Code Is Just a Container

A QR code can contain a single share link, a subscription URL, or an ordinary webpage URL. Successfully scanning it with Scan QR Code does not mean it contains server details. Before scanning, make sure the code comes from a management source for a server or subscription you already have. Don’t save unknown content without checking it. If the result is a webpage URL, confirm it’s actually a subscription endpoint rather than assuming it’s valid because it scanned successfully.

When displaying a QR code on another screen, keep the entire code sharp and unobstructed, with a clear border. Avoid glare and don’t crop the corners. If the camera is too close, it may not capture all four edges; if it’s too far away, small modules may blur. Adjust the distance and brightness before trying again. Don’t post a QR code publicly to ask someone else to scan it: its authentication details may grant the same access as a plain-text share link.

Camera Permission and Image Scanning

When you use Scan QR Code, allow camera access if the system prompts you; real-time scanning requires it. If you previously denied access, change Shadowrocket’s camera permission in system settings. If the current scanning interface offers an option to scan from an image, select an original image you saved yourself. If it doesn’t, don’t look for a button based on screenshots from another platform; import the original text instead.

After scanning, check the recognized type, name, and address before saving. If the result is a single server but you expected a full subscription, the QR code may contain a single share link. Conversely, a subscription QR code may not immediately display every server; save the subscription and complete its first fetch. Check the item type instead of scanning repeatedly and creating duplicates.

Clipboard Import, Step by Step

1. Copy the complete original text from your own records. Use an option such as “Copy link” to get the raw content, and avoid copying explanatory text, list markers, or quotation marks along with it.
2. Return to Shadowrocket and use the clipboard import option shown in the interface. If the system asks whether to allow pasting, confirm only when you’re ready to import.
3. Check the detected result. A single share link should create a standalone server; a subscription URL should create a subscription. If the content isn’t recognized, keep the original text and don’t save it repeatedly without checking.
4. After saving, check where the entry was added, then test the connection or fetch the subscription. When you’re done, you can replace the clipboard contents with ordinary text that contains no sensitive information.

An empty clipboard, denied paste permission, or copied content wrapped in rich text can all cause an import to fail. The simplest check is to inspect the beginning and end of the text in a private text editor on your device. Make sure the protocol prefix and ending are intact, with no extra explanatory text, full-width punctuation, or unwanted line breaks. Never paste a real password into a web search box or public online parser.

Handling Bulk Imports and Duplicates

Multiple share links generally need one link per line. Whether the current entry point supports importing several at once depends on what it recognizes. Test one link first, then process the rest to narrow down any issue. If the whole block becomes one malformed name or only one item appears, don’t assume a successful save means the batch was imported. Check the separators in the original text and verify each result individually.

Importing the same server once by QR code and once from the clipboard usually creates two local entries rather than merging them. Matching names don’t prove the parameters match; one entry may have an updated port or transport setting. Before removing either, compare Type, address, port, and source, and keep the entry that currently works. Check authentication only on your own device. For convenience, don’t send both sets of complete details in a chat.

If recognition succeeds but the connection fails, go to Section 2 and check the parameters. If a subscription saves but shows no servers, return to Section 1 and check the first fetch. Treat recognition, saving, fetching, and connecting as four separate stages; this makes issues easier to pinpoint than repeatedly changing the import method. For more permission issues, see the installation and first-launch topics in the FAQ.

A Single Share Link Does Not Update Automatically

A single share link usually describes one server, including its protocol, authentication details, address, port, and optional transport parameters. Importing it creates a snapshot of the settings at that time. If the server’s password or port changes later, the entry won’t update just because it came from a share link. A subscription URL typically points to a list that can be fetched again; updates apply to that list and its entries. The two have different lifecycles.

Common prefixes include ss://, vmess://, vless://, and trojan://. The prefix tells the parser how to interpret the rest; it isn’t a label you can freely replace. Changing it to another protocol won’t convert the link, because authentication, data structure, and transport semantics may be completely different. If a format isn’t supported, check the original export format.

Encoding, query parameters, and labels

Some formats encode authentication details or the entire structure in the link. Encoding changes how data is represented; it doesn’t encrypt or protect it, and it doesn’t make it safe to share publicly. A seemingly random string may still decode to a password, UUID, and server address. Don’t remove equals signs, hyphens, or underscores to make the link look “tidier”; they may be part of the encoding.

Query parameters usually start with a question mark and are separated by ampersands. They may contain transport type, TLS, Host, Path, and other settings. The fragment after a hash at the end of the link is often a label. Non-ASCII text, spaces, and special characters in the label may be percent-encoded; let the client parse them rather than encoding already-decoded text again. Changing a label usually won’t affect the connection, but removing parameters before the hash may change how it works.

When copying from webpage source or email, ampersands may be converted to HTML entities, and standard characters may be replaced by typographic ones. The link can look almost right but parse with missing fields. Get the original text again if possible instead of guessing how to restore it character by character. A long link wrapping on screen doesn’t necessarily contain line breaks; check the actual characters locally.

Verify Parsed Fields Instead of Editing Encoded Text

After importing, check Type, address, port, authentication, and transport fields. This is more reliable than checking only whether a name appeared. Optional parameters can vary between implementations of the same format; a recognizable prefix doesn’t guarantee that this entry point uses every field. If the source specifies a value that’s missing after parsing, use Section 2 to check and add it in a standalone entry, keeping the original details so you can revert.

The example below shows a structure for reference only. The domain and password are fictional, and the link cannot be used to connect. It illustrates the relative positions of authentication, host, port, query parameters, and label. Not every protocol uses the same layout, and not every advanced option belongs here.

trojan://[email protected]:443?security=tls&sni=example.com#Manual-Example

If an HTTPS URL returns a complete configuration rather than a server list, use the import option intended for that content. Don’t force it into Subscribe and expect it to work. A full configuration may also change rules, DNS, and server definitions, affecting much more than a single share link. Back up your current configuration and inspect the content before importing; don’t wait until it has been overwritten to look for the original file.

For more on field layouts, see Share-Link Formats vs. Subscription Links. Treat any original link as sensitive, whatever its format. When asking for help, describe the protocol and the stage where the error occurs, but hide authentication details, complete URL parameters, and QR codes that could reveal them.

What an Update Can Change

A subscription update requests the remote content again and adjusts the associated local servers based on the response. Names, addresses, ports, authentication details, and list membership may all change, so an update is more than a display refresh. Before updating, note the name and purpose of the server you’re using. Back up first if you rely on local changes. If an entry is removed from the remote list, it may disappear from your device on update; seeing an old entry now is no guarantee it will remain.

An existing connection and the next new connection are separate things, too. Finishing a list update doesn’t necessarily make all existing connections use the new parameters immediately. Once you’ve confirmed the changes were saved, reconnect if needed and verify access. Avoid repeatedly updating and switching servers during important uploads, calls, or remote work, as rebuilding a connection may disrupt the task. Choose a time when a brief interruption is acceptable.

Choosing Between Manual and Automatic Updates

Manual updates are useful when you want to review changes and check entries one by one: back up first, fetch once, compare the lists, then test the server for your current needs. If the interface offers automatic updates and interval settings, choose a frequency that suits your usage. A short interval doesn’t guarantee reliability. Frequent updates generate more requests and may trigger rate limits; background updates also depend on system scheduling and network conditions.

Even with automatic updates enabled, check the results occasionally. A device that’s been offline, system restrictions on background activity, or changes to subscription access can leave the list out of date. Look for a clearly completed request and inspect the list; the automatic-update switch alone isn’t proof. Scheduling can differ by platform, so don’t assume multiple devices will fetch the exact same list at the same time.

Choose Troubleshooting Steps by Failure Stage

For a timed-out request, check the local network, DNS resolution, and reachability of the destination. For an authentication error, check your access and the original URL. For a parsing error, check whether the response has changed to a webpage, message, or different format. If the list updates successfully but a server won’t connect, check the selected entry and its protocol settings instead of repeatedly requesting the subscription URL. The right next step depends on where the failure occurred.

If the update URL can’t be reached on your current network, compare the result on another network you’re authorized to use. This can help distinguish a local network problem from a remote one. If you already have a working connection, identify which network path the request actually takes. Don’t change routing, DNS, and the subscription URL all at once. After repeated failures, pause, note the error text and the conditions when it appears, then check the relevant details.

A Subscription Update Does Not Update Config

Server subscriptions and rules configurations may have separate update options. If servers work but some destinations don’t, check Global Routing and Config rather than blaming the servers for every issue. The snippet below illustrates rule order: first match a specified domain, then a specified region’s IP, and finally apply a fallback. It’s not a complete configuration and shouldn’t replace your existing file.

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY

Rules are evaluated from top to bottom; the first match determines how traffic is handled. FINAL applies when none of the preceding rules match. In this example, PROXY represents the corresponding proxy action; before using it, confirm how the policy maps to your selected server. DNS results, rule order, and the current mode all affect the route. The presence of an entry in the list doesn’t mean every request uses it.

If an update changes both servers and configuration, validate them separately: first check the server connection, then check the rules. Note what you change, but don’t put credentials in troubleshooting notes. If you can’t get online only after turning the switch on, follow the step-by-step checklist for servers, Global Routing, DNS, and rules. Change one variable at a time.

Use Names You Can Recognize

When managing multiple subscriptions, first distinguish the subscription name from the server name. The subscription name helps you identify the update source; the server name helps you choose a specific connection. Name a subscription by a purpose or environment you’ll recognize, such as “Daily use” or “Test environment.” Add the server’s purpose and source to its label if useful. Avoid context-free names like “New” or “Backup”; over time, it’s hard to tell which entry to keep.

Don’t put passwords, complete subscription tokens, or other authentication details in names. Even if a list is visible only on your device, names can appear in screenshots, screen sharing, and backup filenames. Expect server names generated remotely to revert on the next update. If you need a persistent local label, first check how the current interface handles renaming; one successful save doesn’t guarantee the name will never change.

Check the Source Before Removing Duplicates

Entries with the same name may belong to different subscriptions or use different protocols, ports, and transport settings. The same address doesn’t necessarily mean they’re duplicates either. Before removing one, check its subscription, Type, address, and port, then compare authentication and transport settings locally. Don’t delete half the list based on names alone. If you’re unsure, label the entries and stop using the one in question until you’ve checked it.

If the same URL was added as two subscriptions, the lists may update at different times and end up looking different. Choose the subscription you plan to keep, complete one confirmed update, and test the server you currently use. Only consider removing the other after confirming the retained subscription has what you need. Before deleting, check which servers and configurations refer to each group so you don’t mistake an active group for a duplicate.

Manage Servers, Policies, and Modes Separately

Organizing a list does not automatically change how all traffic is handled. In Global Routing, Config, Proxy, and Direct are the basic modes for following the configuration, using a proxy, or connecting directly. If the interface also offers Scene, use it according to the actual scenario settings. Choosing a server and choosing a mode are separate actions: selecting a server while the mode is Direct does not mean traffic is going through that server.

If a Config refers to servers or policies by name, renaming or deleting them may break those references. Before organizing entries, check whether the active configuration depends on them. Afterwards, check policy selection and rule matches. Don’t stop just because the names look tidy; make a real request that reflects your everyday use and confirm it’s handled as expected.

Organize in Small, Reversible Batches

Handle one subscription at a time: back up the current state, check for duplicates, update the names, fetch and test, then move on to the next group. If something goes wrong, you can tie it to the most recent changes. Updating everything, renaming everything, deleting old entries, and replacing Config all at once makes issues difficult to untangle. Even with a backup, it may be hard to know which part to restore.

Check each device separately, too. Deleting an entry on your phone doesn’t necessarily remove its separate copy from your computer. If you stop using a subscription, check each device where it was saved. Conversely, revoking access on the server doesn’t automatically remove the local entry; an expired entry may remain in the list until you clean it up.

Keep a management note without authentication details. Record each subscription’s purpose, standalone local entries, dependent Config, and the most recent check. Store real credentials in a protected backup, separate from public troubleshooting notes. See Section 8 for deletion and export limits, and the next section for testing and sorting.

What Connectivity Test Tells You

Connectivity Test checks connectivity under specific conditions. Depending on the method, it may test only connection establishment or include a request through the proxy. Before testing, check the method and target selected in Settings. A shorter time doesn’t mean higher throughput or guarantee a stable long-lived connection. One timeout doesn’t prove a server is permanently unavailable. Interpret results alongside the conditions under which they were measured.

Measurements are affected by your local Wi-Fi or cellular network, DNS, device load, server status, and the test target’s response. Rankings may no longer apply after switching networks. Don’t compare results from different networks, times, or test methods as if they were equivalent. A test target unrelated to your actual use also can’t predict how every destination will perform.

Run Comparable Tests

1. Make sure the device itself is online, pause bandwidth-heavy tasks, and use the same network and similar conditions for each test.
2. In Settings, check the current test method and target. Use the same settings for every entry you want to compare.
3. Run one test and wait for it to finish before checking failures. Don’t start several rounds while the first is still running.
4. Retest promising entries a few times, then select one and try a real connection. Note any authentication, TLS, or destination-response errors.

Testing every entry in a long list can generate many connection requests, and competition over a short period can skew results. Start with a group relevant to your current needs and narrow the field. If every entry fails, check shared conditions such as the local network and test target first. If one entry keeps failing, check its settings. Investigating common causes is more effective than changing passwords one by one.

Sorting Is Not Automatic Selection

Sorting by latency usually changes only the order in which entries are displayed. Don’t assume it automatically replaces the current server or that the first entry becomes active. After sorting, check the selected indicator and review the policy selection in Global Routing and Config. If the configuration has its own selection logic, list order may not match the entry being used.

Sort by name to find a known entry, group by source to manage updates, and sort by latency to compare candidates under consistent test conditions. Each method serves a different purpose; no single order has to solve everything. If the current interface doesn’t offer a particular sort option, don’t rename every server to imitate it. Traceable names are usually more useful than an artificial order.

When Low Latency Doesn’t Mean You Can Connect

If a basic test succeeds but a webpage won’t load, check each layer: confirm that the request is going through the selected server, then check Global Routing, rules, and DNS, and finally check the destination’s response. Establishing a connection to a port only confirms that one stage completed; the destination may still reject the request, or TLS may fail later. Don’t attribute every error to latency being “too high.”

If only some domains fail, check whether they match REJECT, DIRECT, or an unsuitable policy. If every domain has DNS errors, check DNS and basic connectivity first. If one entry starts failing after an update, return to Section 2 and verify its authentication and transport. The error stage in the logs is more useful for diagnosis than a single number beside an entry. When reporting an issue, include only the necessary error text and hide addresses and credentials.

Choose an entry for everyday use only after testing it in practice, and keep in mind that switching may require existing connections to be rebuilt. For ongoing issues, follow the checklist for when the switch is on but there’s no internet. For system authorization issues, see the VPN configuration prompt guide. The aim is to narrow down the problem, not to chase a minimum number detached from real-world conditions.

Identify the Item Before Deleting It

Deleting one server, deleting an entire subscription, deleting a Config, and removing the system VPN configuration are different operations. Removing a server entry doesn’t delete its subscription; an update may add it back. Deleting a subscription may remove its whole group. Read the confirmation dialog and check the item name and scope. Don’t rely on its position in the list to tell you what you’re deleting.

First, check which server and configuration are currently in use. If you’re deleting the active server, switch to another verified entry or disconnect at a time when an interruption is acceptable. Removing an item referenced by name in a configuration may change how traffic is handled. Afterwards, check more than whether the list looks clean: verify the current selection, policies, and actual access.

A Backup Is More Than a Rules File

A Config export may not include every subscription URL, standalone server, authentication detail, or local setting. A screenshot of the list can’t restore connection parameters either. Before backing up, read the description of the current export option to see what it actually includes. Consider the information needed for recovery in four groups: existing subscription URLs, manually added or independently imported servers, rules and DNS configuration, and local management settings. Know where to get each one when you need to restore it.

If the interface offers Data or another export option, check which items it includes. If it only offers a single share link, treat that as an export of that entry—not a full device backup. Don’t assume data formats are fully compatible across platforms. Before cleaning anything up, make sure the export is recognized by the intended import option and check that it contains the items you need.

Storing and Restoring Sensitive Backups

Subscription URLs, share links, and data files may contain credentials. Store them somewhere you control and protect access to. Name files by purpose and device, not by token or password. After transferring a file through personal storage, check its history and sharing permissions. When helping someone troubleshoot, share only structural details with sensitive information removed; don’t send a full backup as an ordinary attachment.

Restore from the smallest scope upward: first restore or re-add the subscription and fetch it; then restore standalone servers and verify them; next import the Config you need; finally check Global Routing, local selections, and system permissions. Confirm each step before moving on. Importing every old file at once can create duplicates or let an old configuration overwrite new settings, making problems harder to diagnose.

After moving to a new device, you may need to grant system VPN permission again; don’t assume authorization transfers from the old device. If a prompt appears to add a VPN configuration, follow the system interface to authorize it. If you declined, trigger the prompt from the app when you’re ready to connect, then check system settings. Restoring server data and restoring system permissions are separate processes; repeatedly importing a subscription won’t fix a permissions issue.

Accidental Deletion, Expired Entries, and Revoked Access

If you accidentally delete a subscription but still have a valid URL, you can add it again and fetch the current remote list. This may not restore your previous local labels or entries that have since been removed remotely. A standalone server you entered manually can’t be recovered from a subscription update if you no longer have its original details or an exported copy. Check what your backups contain before choosing a recovery method; clearing the app’s data should not be your first troubleshooting step.

Deleting a local entry only changes data on that device; it does not revoke server access. If you think a subscription URL, password, or QR code was exposed, update or revoke the relevant credentials through a service-management interface you’re authorized to use, then import them again on each device. Removing the old entry from your list won’t stop other copies with those credentials from trying to connect.

After following this page, return to the quick-start guide to review the connection steps, or visit the FAQ to find guidance by symptom. Use the glossary for rules and interface field definitions, and the download page for app downloads and system installation prompts. Keep server details, rules configuration, and system permissions separate so you have a clear checklist for future updates and device changes.