Subscribe: Link a subscription to its servers
A subscription is a remote resource address that can be requested again, while a server entry contains parameters the client uses to connect. They are not interchangeable just because they look similar: a subscription update can return multiple servers, while a single share link usually describes one server. Identify what kind of information you have before importing it. This helps prevent entering a subscription URL in a server address field and explains why some entries may reappear after an update.
Identify the resource before opening Subscribe
After getting a subscription from your service provider, keep the original text intact and avoid changing its query parameters. A subscription usually looks like a web address, but whether it opens in a browser is not a reliable test; a login page, help page, and subscription resource may share the same domain. Check the provider's instructions to confirm that the address is for a Shadowrocket subscription, not account management or a general information page.
From the add option on Home, choose the subscription type corresponding to Subscribe. In some interfaces, Subscribe appears under Type in Add Server. Enter the complete address in URL, add a recognizable note, save, and trigger an update. Options may appear in a different order across platforms. Look for the Subscribe and URL functions rather than expecting a button in a particular corner of the screen.
Use notes to record the resource and its purpose, such as “Personal / Daily” or “Personal / Backup.” Do not put the full subscription URL, account password, or access credentials in a note. Notes help you organize the list; they do not replace server-side parameters. Changing a note does not change the server address or make expired credentials valid again.
Check the entries and update results to confirm import
After saving a subscription, check whether server entries appear beneath it and whether the update reports an error. Seeing a subscription name does not mean it contains usable servers. If the list is empty, check in order that the address is complete, the current network can reach the resource, and the server returns content the client can recognize. Record any error before deciding whether to add it again, so you do not create several copies of the same subscription.
Server names in a subscription are usually determined by remote data. A change in names, count, order, or connection parameters after an update does not necessarily mean the client lost data; the remote source may have removed an old entry or changed its configuration. To track changes, record the subscription and entry names before and after updating, then compare their source. The total number of entries alone cannot show whether an update worked as expected.
After importing a subscription, you still need to select an available server and verify the connection. A subscription provides server details; rules in Config determine how traffic is handled. These are separate layers. Server details without an appropriate Global Routing setup may not produce the expected traffic path. A rule file without a connectable server cannot establish a PROXY connection either.
| Resource type | Primary imported item | What to do next |
|---|---|---|
| Subscribe URL | Subscription and its server list | Request an update from the original address |
| Single share link | Standalone server entry | Import again or edit manually |
| Shadowrocket .conf | Config file | Manage rules and configuration |
Treat subscription URLs as credentials
A subscription URL may contain parameters that identify your account, so treat it as sensitive information. Before copying it into a chat, screenshot, or support request, obscure credentials in the full path and query parameters. Hiding only the domain is usually ineffective because the information that grants access may appear later in the URL. When asking for help, share the protocol type, error category, and steps to reproduce the issue; do not expose a subscription URL that grants direct access.
If you think an address has been exposed, ask your service provider whether the subscription credentials can be reset, then replace the saved URL in the client. Editing a local note or deleting a server entry will not invalidate the old address. After replacing it, update the subscription and test one entry before removing the old one. This helps avoid losing a working configuration before the new resource has been verified.
Add Server: Enter server parameters by protocol
Manual entry is useful when you have complete server details or need to check a specific field. Open Add Server, select Type, and fill in the fields for that protocol. Do not enter all your details into the default form and switch protocols afterward. Required fields and available options differ by protocol; after changing Type, review whether the values you entered still apply.
Check the address, port, and credentials separately
Address generally means the server's domain name or IP address, without a web path or protocol prefix. Port must match the port the server listens on; do not use the port for an admin webpage. For IPv6, use the separate address and port fields in the form rather than assembling them like a web URL. If your source only provides a complete link, import the link instead.
Check credentials against the protocol. Shadowsocks commonly uses an encryption method and password; VMess and VLESS use their respective user identifiers; Trojan uses its authentication details. A long string of characters alone does not tell you which field it belongs in. After copying, check for leading or trailing spaces, line breaks, and letter case. In particular, do not mistake automatic line wrapping in the interface for a line break in the original credentials.
Instructions that provide only a “password” and “address” may not include enough information for a complete connection. The server may also require a particular transport, TLS, SNI, path, or other options. Get the complete details from your service provider instead of toggling settings until a combination appears saveable. A form accepting your input only means the values are syntactically accepted; it does not mean the server will accept them.
| Parameter group | What to check | Common mix-up |
|---|---|---|
| Address / Port | Connection target and listening port | Using a web address as the server address |
| Authentication parameters | Password, user identifier, or key | Entering credentials for a different protocol |
| TLS / SNI | Whether it is enabled and the verification name | Using SNI as the Address |
| Transport parameters | Transport, Host, and path | Missing the path or changing letter case |
TLS and transport settings are separate
TLS handles connection encryption and related verification; transport parameters describe how protocol data is carried. Enabling TLS does not mean you can omit the transport path, and entering Host does not mean SNI is correct. If the supplied Address, Host, and SNI differ, enter each in its corresponding field. Do not change all three to the same domain just to make them “match.”
If certificate verification fails, first check the device's time, SNI, server certificate status, and whether the supplied details have changed. Do not treat disabling certificate verification as a general fix. Bypassing verification can hide an incorrect connection target and reduce your ability to confirm the server's identity. If you need to investigate a specific test environment, document the change and restore the original verification setting afterward.
Protocols such as WireGuard use different keys and interface parameters; do not use a standard username-and-password form. A private key is sensitive and should not appear in screenshots or ordinary notes. Check fields for local addresses, peer public keys, and route ranges together. Changing just one value may allow a handshake while preventing traffic from reaching its intended destination.
Save, then run a basic check
Give manually entered entries a clear note identifying them as “Manual” and stating their purpose, so they are easy to distinguish from subscription entries. After saving, select the server and test a connection and access on a fixed network. Avoid changing the rule file, DNS, and several transport options at once. If it fails, compare each field with the original details and troubleshoot incorrect parameters separately from a network that cannot reach the server.
If you need to change a server in a subscription, consider copying it to a standalone entry and testing that copy. Editing an entry managed remotely may not persist: the next update can restore the original parameters. A standalone copy is convenient for experiments, but it will not automatically receive new parameters from the subscription. After testing, record how it will be maintained; do not mistake it for an entry that updates automatically.
Field labels may vary slightly across platforms and interface languages. Match fields to the protocol details by their purpose rather than copying a screenshot for another protocol. For common interface terms, see the English interface glossary. Keeping the original details, changing one parameter at a time, and testing after each change makes issues easier to pinpoint than repeatedly deleting and recreating entries.
QR Code and Clipboard: Identify the content before importing
QR codes, the clipboard, and manual entry are just different ways to provide input; they do not change a server's permissions or capabilities. A QR code may contain a single share link, a subscription URL, or ordinary text. The clipboard can contain anything as well. Before importing, decide whether you expect a server, subscription, or configuration file, then check the result against that expectation.
Scan QR Code: recognition and permissions
When you open Scan QR Code, the system may ask for camera access. Grant the required permission only when you are ready to scan information you already have. If you previously denied access, check the camera permission in the app's system settings. A camera that will not start points to a permission or device issue; it does not mean the server in the QR code is invalid, and there is no need to recreate the subscription.
Before scanning, make sure the entire QR code is visible and leave the recognition margin around it. Avoid glare, obstructions, and heavy blur. QR codes with long parameters have denser patterns and may fail to scan if displayed too small. If the code is on another screen, enlarge it as needed; do not crop the image until only the black-and-white squares remain.
If the QR code is in an image on the current device, use a photo-library import option only if the interface provides one. If there is no such option, return to the original text and import the link by copying it. Do not assume that because an image is visible in your photo library, the app can scan it. Do not repeatedly grant system permissions unrelated to importing.
Keep one complete item on the clipboard
When copying a link from your service provider, use its copy function if available to avoid missing the beginning or end when selecting text manually. Return to Shadowrocket right away and use the appropriate clipboard import option. If the system asks for permission to paste, allow it when you have confirmed that you intend to import. If you deny access and nothing is read, that does not mean the original link is malformed.
Chat apps, email, and documents may add quotation marks, bullets, or explanatory text around a link. Before importing, keep only the actual link; do not copy a heading such as “click here” along with it. A long address that wraps across lines on screen may still be a single line when copied. If the original text really contains spaces or line breaks, copy it again from the source rather than deleting characters at random.
Import one clearly identifiable item at a time, especially when troubleshooting. Pasting a mix of subscription URLs, individual links, and explanatory text may import only part of it or produce an unexpected item. Before importing in bulk, verify the format with one entry, then check the number and source of the imported entries. A success message alone is not enough.
Check three things after import
First, check that the right kind of item was imported: if you expected a subscription, you should see an updateable subscription, not just a server with a similar-looking address. Second, check that the parameters are complete by opening the entry and reviewing Type, Address, Port, and any required transport settings. Third, check the connection: select the entry, run a test, and access a service you are already authorized to use.
If manual entry works but importing the same information from a QR code fails, compare the fields before deciding the QR code is “invalid.” It may omit transport parameters, or its sharing format may include details the current importer does not support. Keep both entries for comparison, but label them differently so you do not select the wrong one during later tests.
Conversely, if a QR code imports successfully but manual entry does not work, first check for fields or special characters missed during manual entry. A share link may include less obvious TLS or path options even when it only displays a server name. Do not assume two configurations are identical based only on their names and ports. Expand the full settings and compare each field before removing duplicates.
After importing, clear clipboard content you no longer need and delete temporary screenshots of credentials. If the information has synced to another device or the cloud, cleaning up this device does not remove every copy. To describe an import issue, provide the error, item type, and steps taken; do not send a QR code or complete link that is still valid.
Update Policy: Choose when to update and keep a rollback option
A subscription update requests the remote resource again; it does not simply check whether the local list is still there. When remote content changes, an update may add, remove, or modify servers, or change their notes and order. A sensible update policy considers how often the source changes, whether the current network can reach it, and whether local edits need to be preserved. More frequent updates do not automatically make a subscription more reliable.
Make the first update manually so you can observe it
After creating a subscription, update it manually first. Check whether the request succeeds, the response can be parsed, and the entries match your expectations. Once this works, configure automatic updates using the options actually available in the interface. Do not enable several automatic behaviors before the first import is complete, or it will be difficult to tell whether a list change came from your actions or a background update.
Before updating, note the names of currently usable servers, their subscriptions, and the Config file in use. Save a separate copy or local backup of important manual changes. Entries in a subscription are managed by remote data, so local edits may not survive a refresh. If a parameter must remain different from the subscription's original value, maintain it as a standalone entry rather than relying on it not being overwritten.
Set the automatic update interval according to your needs. If the information is stable, there is no need to make repeated requests at short intervals. When a server-side change is underway, update manually once the provider confirms the details have changed. Frequent retries may trigger remote rate limits and fill your logs with repeated errors, but they cannot fix an invalid address, failed authentication, or an unexpected response format.
Separate network errors from content errors
For a request timeout, check the current network and whether the subscription URL is reachable. If content is returned but cannot be parsed, check whether the resource has become a login page, error page, or a different format. If the interface reports an authentication error, ask your service provider whether the URL and credentials are still valid. Changing a local server note usually has no effect on the subscription request.
The route used to reach a subscription resource may differ from the route used to connect to a server. A working server does not guarantee that the subscription URL is reachable, and a subscription that updates successfully does not guarantee that every server in it can connect. Record update results and connection test results separately. One success does not rule out a problem at the other level.
When troubleshooting, change one condition at a time. For example, keep the same subscription URL and retry over a different network you can use. Do not change the URL, DNS, Global Routing, and several server parameters at once; even if the issue clears, you will not know why. If an update may replace the existing list, back up the old information before making a change that could affect many entries.
| Symptom | Check first | Hold off on |
|---|---|---|
| Request timed out | Current network and resource reachability | Repeatedly deleting the subscription |
| Content could not be parsed | Response format and whether it is an error page | Editing the encoded content |
| Fewer entries after an update | Remote changes and subscription ownership | Immediately clearing the remaining list |
| Local parameters reverted | Whether subscription data overwrote them | Continuing to edit the same remotely managed entry |
Do a quick check after updating
After a success message, check at least one frequently used entry and one backup entry for unexpected protocol, address, or connection changes. If server names changed, also check whether any rules or selection records depend on those names. A visible list does not guarantee that the item you used before is still there, especially after the remote source renames or merges entries.
If an update fails but the old entries still connect, keep the current state for now and troubleshoot the subscription request first. Do not clear the entire list just to remove an error message. If an update succeeds but connections then fail, compare the actual parameters before and after, and ask your service provider what changed. Restoring an old name will not restore changed server credentials.
Finally, distinguish app updates from subscription updates: the former changes Shadowrocket, while the latter changes remote server details. See the download page for app acquisition and installation instructions. Updating a subscription does not upgrade the client, and reinstalling the client does not automatically fix an invalid subscription URL. Maintain and verify these two separately.
Organize Multiple Subscriptions: Use names and ownership to avoid duplicates
The goal of managing multiple subscriptions is not to merge every server into one longer list. You should be able to tell where each entry came from, when it will update, and whether a standalone copy also exists. Establish ownership first, then sort or delete. Deduplicating by name alone can remove servers with different purposes, while judging by list size can lead you to delete standalone configurations that are still in use.
Use a two-level naming system for subscriptions and standalone entries
Use subscription names to identify the source and purpose, and server notes to distinguish individual connections. The two levels should complement each other: renaming every server to the subscription name erases the differences between entries; keeping only remote server names without recording subscription ownership makes it hard to tell which group to update or delete when names repeat.
Use short subscription names such as “Daily / Personal” or “Test / Personal” to show purpose and resource group. Mark standalone copies as “Manual” and note the original subscription name. You do not need a full date or long explanation in every entry, and never include passwords or subscription credentials in a name. Names should help you identify items, not become another list of sensitive information.
Finish updating and verifying one subscription before handling the next. Each time you add a subscription, check whether the same URL is already present and whether you previously imported one of its servers as a standalone link. Duplicate sources may have different names if the same subscription was added more than once with different notes. Compare the subscription objects themselves, including their ownership and URLs.
Do not identify duplicates by server name alone
Two entries with the same name may use different addresses, ports, credentials, or transport parameters. Two entries with different names may use the same connection parameters. To deduplicate, compare the protocol and destination address first, then check the port, credentials, and key transport settings. Compare credentials locally; do not upload them to a public spreadsheet or web tool.
Even when the connection parameters match, consider whether the entries are maintained differently. One may come from a subscription and update remotely, while the other is a standalone manual copy. Decide which maintenance method to keep before deleting either. If the manual copy has necessary local changes, do not delete it just because the address matches. If it is only an old test entry, you can remove it after verifying the subscription entry.
If you delete a server from a subscription, it may reappear at the next update because the remote list still contains it. That is not a deduplication failure; local deletion and remote management are separate. If the interface offers filtering or subscription management options, use them as appropriate. Otherwise, expect the remote entry to return after an update rather than repeatedly deleting it to change how the list looks.
Group by how you use entries, not by one test result
Daily use, backup, and testing are more stable ways to organize entries. A latency result reflects network conditions at a particular time; it is not a permanent classification. If you remove every slower entry from the regular list after one test, you may have to reorganize everything when the network changes. Keeping a small number of verified backups is easier to maintain than rebuilding the entire list frequently.
If the interface supports sorting or moving entries, put frequently used subscriptions and servers where they are easy to access. If custom ordering is not available, use clear notes and groups instead of expecting every platform to display entries in exactly the same order. Remote updates may also change the original order, so “the third row” is not a reliable way to identify a server.
When cleaning up, handle confirmed duplicate subscriptions first, temporary copies next, and lastly information that is rarely used but may be needed for recovery. Process one type of item at a time and check whether the currently selected server is affected. Do not delete an entire group while a connection still depends on it. Switch to a verified entry you intend to keep before removing anything.
After organizing, check that each retained subscription can update and each frequently used group has at least one usable entry, then save the new management state. For examples of grouping and duplicate entries, see the multiple subscription management guide. Long-term maintenance is about clear ownership and traceable changes, not making the list as short as possible.
Latency Testing and Sorting: Interpret results in context
A latency test measures response under a particular test method; it does not reflect the full experience of using an app. An entry with a low result may still be affected by bandwidth, packet loss, authentication, TLS, or the destination service. A timeout also needs to be considered in light of the test target and method. First understand what was measured, then decide whether the result should affect your server choice.
Keep the network, test method, and comparison set consistent
When you use Connectivity Test on Home or in a related test screen, check which methods the interface actually offers. Some methods check only part of the route to the server; others send a request through the proxy to a specific target. Compare results directly only when they use the same method and network and were run at roughly the same time. Do not mix old results from different conditions into one ranking.
Start by testing a few frequently used servers and confirming that the test target works, then expand the selection. Testing a long list all at once may be affected by the local network and concurrent connections. If nearly every entry times out at the same time, check the device's network, test target, and current settings before assuming every server is down. Start with a known working entry as a baseline.
A single result can be affected by temporary fluctuations. Test candidate entries several times and look for consistency and repeated timeouts rather than choosing only the lowest value. Results from one Wi-Fi or mobile network may not apply on another. Test again in the environment you actually use; do not treat a single result as a permanent property of a server.
Distinguish reaching the server from reaching the destination
A connection to a server does not prove that proxy protocol authentication succeeded. Successful protocol authentication does not guarantee that the destination website will respond. When troubleshooting, record three stages: network reachability, protocol handshake, and destination request. If one stage fails, focus on its related parameters instead of attributing every issue to “high latency.”
For real-world access tests, also check Global Routing. Config applies policies based on its active rules; Proxy makes it more direct to test proxy traffic; Direct cannot demonstrate that a proxy server works. These posture names correspond to the interface terms Config, Proxy, and Direct. After testing, restore your usual posture so a temporary setting is not left in place.
| Global Routing | What you are testing | Keep in mind |
|---|---|---|
| Config | Verify actual rule-based routing | The destination may match DIRECT or REJECT |
| Proxy | Focus on the proxy connection path | System and configuration exceptions may still apply |
| Direct | Check behavior without the proxy | Does not prove that the selected server works |
Under Config, a successful visit to a destination that matches DIRECT does not prove the selected server is working. A failure caused by REJECT does not show that the server itself is unreachable either. Check the active rules, connection logs, and destination domain to identify the policy actually applied. See the glossary for rule keywords; do not replace an entire subscription just because of one test result.
Use sorting to narrow down the candidates
After sorting by test results, choose from the entries that perform consistently and verify them with the services you need. Interactive requests, long transfers, and persistent connections have different network requirements; one short request cannot represent every use case. Do not treat speed or purpose written in a server note as a result measured and verified by the client.
For many everyday setups, one reliable candidate and one verified backup are enough. When switching to the backup, keep the same Config and destination service if possible so you can compare them. Changing the rules, network, and server at the same time may restore access, but it will leave the cause unclear and force you to troubleshoot again if the same issue returns.
If tests look normal but some apps fail after connecting, continue checking DNS, rule matches, existing app connections, and destination service restrictions instead of repeatedly re-sorting. Some apps reuse connections established earlier; after changing settings, make a new request to check the new route. Close old requests to the test destination before comparing results so cached behavior is not mistaken for the current configuration.
Record the network, test method, selected entry, and final access result; there is no need to save every number. The useful record is what works and what fails under particular conditions. For common points where a first connection can stall, see the beginner FAQ, then continue troubleshooting with the layered approach in this section.
Delete and Back Up: Confirm what you can restore before cleaning up
Delete the smallest relevant item first, and confirm the backup's scope before relying on it. A server, a subscription, and a Config file are separate items; deleting one does not manage the others. Before cleanup, decide whether you want to remove a displayed entry, a whole set of remote data, or unused rules. Do not use “start over” to fix a problem that affects only one item.
Check what the current connection depends on before deleting
Before deleting the currently selected server, switch to a verified entry you plan to keep and confirm that it connects. Before deleting a whole subscription, check whether it contains backup entries still in use and whether any rules or selection records depend on specific names. Deleting can do more than shorten the list; it can remove connection options you need later. Resolve dependencies before cleanup.
After deleting a single server from a subscription, it may return at the next update. Deleting a subscription may also remove its servers; check the confirmation screen to see the exact scope. Read the prompt carefully instead of inferring the impact from the button text. If you only want to stop using something temporarily, change your selection or use an available disable option rather than deleting all the data.
Deleting a Config file is separate from deleting a server. The active rules may determine how DIRECT, PROXY, and REJECT are matched; deleting or replacing the file can change access behavior even if server parameters remain the same. Before removing a rule file, decide which configuration to keep for daily use and note any local network or domain rules you added.
A backup checklist matters more than simply having a file
A backup should account for subscription URLs, standalone servers, the current Config, important local changes, and connection options that need to be set again. Different export options may cover different items: sharing one server does not back up a full configuration, and a .conf containing only rules cannot restore all servers. Check the type of exported file or content rather than assuming everything is recoverable because something was saved.
In Settings or the management options for an item, use only the export, backup, or sharing functions actually provided by the interface. If there is no full backup option, save the items you need separately and make a short inventory. Record each item's purpose and restore order; avoid repeatedly saving every password in plain text in ordinary notes and increasing the risk of exposure.
Backups may contain subscription credentials, server passwords, user identifiers, or private keys. Store them somewhere you control with access protection. If you sync them through system cloud storage, consider the security of your account and other signed-in devices. Do not leave backups scattered in chats as ordinary attachments, or send a complete working configuration for someone to inspect its format.
Restore in order, then verify the connection
When restoring, first confirm that the client came from the correct source. Import subscriptions and standalone servers, restore Config next, then set Global Routing and other connection options. To verify the genuine iPhone and iPad app, check the developer name Shadow Launch Technology Limited, the official icon, and app ID 932747118. For acquisition instructions and the installer links on this site for other platforms, see the Verifying the App section.
After restoring a subscription URL, update it once and check whether the remote data has changed. A server from an old backup may still import even if its credentials or destination address are no longer valid. Seeing the old entry does not mean the restore is complete. Check standalone servers individually; do not expect subscription updates to fix copies that are no longer managed by a subscription.
After restoring, check frequently used entries, backup entries, current rules, and access to actual destinations in order. If you use On Demand, also verify that automatic connection behavior is as expected, but do not enable automatic behavior before the basic connection works. If you find a problem, keep the original backup and make small changes to the restored data so you do not overwrite your last reference copy.
You do not have to keep all historical data indefinitely after moving to a new device. Once the new device can update, connect, and use its everyday rules, remove credentials and temporary exports from the old device. If you no longer control the old device, ask your service provider to revoke or update credentials as needed. Deleting the app locally does not invalidate URLs and backups that were copied elsewhere.
A practical maintenance cycle is simple: back up before a change, adjust one type of item at a time, test afterward, and clean up only once things are stable. To revisit the full connection workflow, return to the quick-start guide; to organize several resources, return to the multiple subscriptions section. A clear recovery path keeps future updates and troubleshooting manageable.