Shadowrocket Subscription and Server Management

Identify your information before choosing an option

If you have a subscription URL that returns a server list, look for Subscribe. If you have the Address, Port, and authentication details for a single server, go to Add Server in the next section. The difference is not connection capability, but how the information is maintained: a subscription typically provides multiple server entries from one URL and can be fetched again later; a manually entered record is saved field by field and must be checked field by field when edited. Entering a single server’s share link as a subscription URL—or a subscription webpage as a server Address—will make troubleshooting harder.

After opening Shadowrocket, look for Subscribe under Config or another server management option. The location may vary with screen size and app layout, so follow what the current app displays. Before proceeding, make sure you copied the full URL, including its path, query parameters, and final characters. Here’s a fictional example to illustrate the format; it won’t return usable information. Treat real URLs as sensitive: don’t post them in public discussions, screenshots, or support requests.

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

Check the three results separately after saving

Enter your existing URL in Subscribe, then save or update as prompted by the current interface. First, check whether the subscription appears in the list. Next, check whether updating it creates server entries. Finally, select an entry and see whether it connects. These results are not interchangeable: a subscription name appearing does not mean its contents parsed successfully, and a server name appearing does not mean its parameters are valid. For your first import, compare the entry count and names with what you expect, open one entry to check its Type, Address, and Port, and only then test the connection.

If the list is empty, check the original text for line breaks, leading or trailing spaces, or a URL copied only in part. If the app reports that fetching failed, check whether the device can reach the URL and whether the source that manages your existing information still maintains it. Don’t immediately delete and add it repeatedly; that can leave multiple entries with indistinguishable names. If content was fetched but could not be parsed, record “fetch failed” and “parse failed” as separate clues. The former points to the URL or network reachability; the latter points to the returned content or its format. For more detailed steps, see the subscription update troubleshooting checklist.

How subscription records and server entries relate

A subscription is the entry point for future updates; server entries are the results you can select. A change in an entry’s name, order, or count after an update does not by itself mean that manually entered app settings were changed. First check whether the change came from the same subscription, then confirm that the currently selected server is still listed. The information delivered by a subscription depends on the details you already have; Shadowrocket displays and manages the returned content. Before relying on manual changes long term, find out whether the next subscription update will overwrite them. Don’t assume updated entries are permanent local drafts.

For your first import, start with one subscription you can identify. Note its display name, how the entries change after an update, and one test result. This isn’t a limit on how many subscriptions you can have; it gives you a clear starting point. If you add several subscriptions at once and then find an empty list, it can be hard to tell which URL or update caused the change. If you already have multiple entries, go to Organize multiple subscriptions and establish a clear naming and checking order.

Choose Type based on the information you have

Use Add Server when you have the complete details for a single server. Select the Type that matches your information, then fill in the fields shown for that Type. Don’t choose a protocol based on a guess and try to force parameters for different protocols into the same form. Shadowsocks, VMess, VLESS, and Trojan are protocol types; the available fields vary by Type and in-app options. The most reliable approach is to compare your information with the form side by side, matching each field name, format, and toggle. Don’t guess at missing details.

Understand the core and additional fields

Address identifies the remote server, Port identifies its access port, and Remark helps you recognize the entry in the list. Whether Password, UUID, encryption method, TLS, SNI, and other parameters appear—and how they fit together—depends on the selected Type and the information you already have. Trojan details often require checking Password and TLS-related fields; VMess and VLESS details commonly include UUID and transport settings. Similar field names don’t mean you can copy an entire configuration from one Type to another. For more on these differences, see Trojan field guide and VMess and VLESS field differences.

When entering details manually, start with fields that don’t expose authentication information: check Type, then the characters in Address and the digits in Port, then protocol-specific fields, and finally Remark. Save the entry and open it again to make sure keyboard substitutions, copied whitespace, or switching forms didn’t change anything. The example values example.com, 443, and your-password are fictional and illustrate field formats only; they’re not substitutes for your own details. Don’t include passwords, UUIDs, or private keys in public screenshots.

Saving does not verify the connection

Saving an Add Server entry only confirms that the form accepted what you entered. Next, select it in the list and check its connection status or run a test as needed. If the test fails, first confirm that Type matches the fields, then check for any additional transport or authentication requirements in your information. Don’t change five or six parameters at once. Change one clearly suspect field, save, and test again so you can tell what made a difference. If your existing information still doesn’t resolve the issue, keep a screenshot of the original entry or notes on non-sensitive fields, then ask whoever maintains that information. Don’t turn a guess into a permanent configuration.

Manually entered entries are maintained separately. They can also help you compare details with a server entry in a subscription, but don’t assume they’re the same record. A subscription update may replace its server entries; manually entered entries generally need to be changed by hand. If the list contains subscription and manually entered entries with similar names, distinguish them by source and remark before deciding what to keep. The next section covers QR code and clipboard imports: they change how you enter information, not the need to check fields.

Check what the QR code contains before scanning

Scanning is a way to let the app read information you already have; it isn’t a server protocol. A QR code may contain a single server’s share link or a subscription URL. Check the result using the Add Server or Subscribe steps, as appropriate. When looking for Scan QR Code or another scanning option in Shadowrocket, follow the name and location shown in the current app. Before using the camera, make sure the QR code contains the information you intend to import. Don’t judge its contents only by the server name printed beside it. After scanning, review the recognized Type, address, or subscription record before saving.

A QR code displayed on the same iPhone may not be easy to scan with that device’s camera. Check whether the current app offers an option to recognize an image or read from the clipboard; available options depend on the interface, so don’t assume a particular button location is fixed. If the QR code is on another device, use the camera to scan it. If it’s in an image on this device, make sure the image is clear and complete, then use the recognition option available in the app. If recognition fails, don’t crop into the QR code’s edges. Also check that it contains text the app can process, not just a webpage link.

Avoid extra characters when importing from the clipboard

Clipboard import is useful when you’ve copied a complete share link or subscription URL. Select only the text you need—avoid copying explanations, quotation marks, or bullet points along with it. If the app offers a clipboard recognition option, review its preview. If there’s no matching option, paste the text manually into Subscribe or the appropriate Add Server field, based on its contents. Don’t assume copying alone creates an entry, and don’t connect without checking what you pasted. Some messaging apps shorten the link shown on screen, so verify separately that the clipboard contains the full text.

After recognition, check what was imported. If it’s a server entry, verify Type, Address, Port, authentication fields, and Remark. If it’s a subscription URL, make sure it was saved as a Subscribe entry and check the server list after updating. QR codes and the clipboard are just input methods; they can’t confirm that the information is complete. In particular, if a QR code contains multiple lines of text, the app may recognize only the part it can process. If the result doesn’t match what you expected, go back to the original text rather than guessing how to complete a partial entry.

What to do if import fails

If scanning produces no result, check the image, brightness, and camera permissions, then confirm that the QR code actually contains a subscription URL or server share text you already have. If clipboard import produces no result, paste the copied text into a regular text field on your device. Check its first and last characters and make sure there are no spaces, line breaks, or explanatory text, then try again in the app. Switching import methods can’t restore missing text. If the content is complete but recognition still fails, use the format guide in the next section to determine whether it’s a subscription URL, a single-server link, or a set of details to enter manually.

After importing, don’t immediately scan the same code repeatedly. Duplicate entries may have the same Remark but come from different import attempts, making it hard to tell which one you selected later. Open the new entry, check its source, and confirm whether an entry with the same address and parameters already exists. To update an existing subscription, use its update option instead of scanning the same QR code again. Before removing duplicates, follow the save-and-delete checks in the final section of this page. For an overview of the four import options, see Four ways to add a server.

Check whether the link points to a list or a single entry

A subscription URL is typically a web-style URL the app can request to retrieve a parseable server list. A server share link typically encodes the details for one server in text that the app can read to create an entry. Even if both can be copied and placed in QR codes, they shouldn’t go in the same field. Don’t judge by whether a link starts with https://: it could be a subscription URL or simply a webpage. Better clues are how your information describes the link’s purpose and the import preview in Shadowrocket: does it show a Subscribe entry or a single server’s Type and parameters?

Share links often include a protocol identifier and encoded authentication details. You may see link formats for Shadowsocks, VMess, VLESS, or Trojan, but not all fields will necessarily be readable on screen. A link may also end with a remark used as the display name; don’t mistake it for an authentication field. Don’t change capitalization, punctuation, or percent-encoding just to make the encoded text easier to read—those changes can prevent parsing. If you can view the fields after importing, check them in the app. If you need to change a parameter, use a value explicitly provided in your existing information rather than inferring it from a truncated share link.

Understand subscription URL structure with a readable example

The URL below illustrates its structure only: the hostname, path, and query parameters are all examples. The path is part of the URL, and query parameters may affect the returned content, so keep the full string when copying. A real subscription URL may contain sensitive identifiers. When describing a problem, report the behavior—for example, “the URL opens, but parsing returns an empty list”—without posting the full URL. A fictional example can help you check the format, but it can’t prove that a real URL is reachable or be used to test a connection.

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

If your existing information is a field-by-field list of Address, Port, Password, and other parameters, with no share link or subscription URL, enter it manually with Add Server. Conversely, if you have a complete subscription URL, don’t split it into Address and Port: the host serving the subscription page is not the Address of each server in the list. Keeping these two kinds of address separate matters. Entering the subscription host in a server field can create an entry that looks complete but doesn’t work as expected.

Format compatibility and parsing limits

Your information may use different encodings and combinations of fields. The formats recognized depend on the import result in your current version of Shadowrocket. After the app identifies a Type, check whether required additional fields are present, especially transport, TLS, and authentication settings. Two share links that show the same protocol don’t necessarily use the same transport parameters. If fields are missing after import, first confirm that the original text is complete, then check whether your information includes those fields. Don’t copy fields from another server just to fill gaps. If parsing fails, keep the error message and sanitized format details so you can check whether the text is incomplete, the wrong import option was used, or the format doesn’t support those fields.

Remember that sharing or forwarding your information can expose enough detail to recreate a server entry. Publicly sharing a QR code, clipboard history, or screenshot with a full URL may also reveal authentication details. To compare two entries, check Type, Remark, and fields that don’t contain credentials on your device. When describing the issue to someone else, use obvious examples such as example.com and your-password. You can still explain whether the problem occurs with Subscribe, share link parsing, or manual Add Server entry without exposing the original text.

An update fetches the subscription content again

Updating a Subscribe entry makes the app fetch the information currently returned by that URL. It doesn’t “speed up” every server or automatically fix incorrect parameters. After an update, names, entry counts, and fields may change to match the returned content. If the original subscription is temporarily unreachable, check the app’s message and current list before assuming the servers have permanently stopped working. Note the currently selected entry and subscription name beforehand. Compare the expected changes with the actual results, then test the connection to distinguish a real content change from a change in the local selection state.

If an entry has been working reliably, don’t make repeated refreshes your first response to a connection problem. If only one server fails to connect, check its test result and actual connection status first. If several entries under the same subscription fail at once, check the subscription URL and the content returned by that update. If you’ve received clear notice that your existing information changed, update the relevant Subscribe entry rather than refreshing every subscription. This makes it easier to trace list changes to a specific entry and action.

Separate fetch errors from parsing errors

When fetching fails, check that the subscription URL is complete, that the device’s current network can reach it, and that the original URL is still valid. If parsing fails or an update returns an empty list, check whether the returned content contains server information the app can recognize, whether a webpage was mistaken for a subscription URL, and whether the original text contains extra line breaks or was truncated. If the update reports success but expected entries are missing, check which subscription group you’re viewing, whether duplicate names exist, and whether sorting or filtering moved the results. Follow one line of investigation at a time, and don’t delete the original entry before you know what went wrong.

If the current app offers automatic update options, set them according to your needs. Don’t assume every subscription needs the same update schedule. Frequent updates can make list changes harder to trace; never checking updates can leave you using entries that no longer match your existing information. A more manageable approach is to note which subscriptions you check regularly and which you update manually only when your information changes, then review entry counts, names, and key fields after each update—not just the completion message. Updates require a network connection, so an offline device can’t confirm whether the latest fetch succeeded.

How to confirm an update didn’t mislead you about connectivity

First find the entry you were using before the update. If it’s still in the list, check whether its Type, Address, Port, or required additional fields changed. If the name changed, look it up by subscription and fields rather than relying on Remark alone. Then run an available connection or test operation. If needed, check the selected server and Global Routing status on Home. In Global Routing, Config, Proxy, and Direct mean routing according to configuration, proxying, or direct connection. A different routing mode can change test and everyday results. Be clear whether you’re testing server parameters, a rule path, or reachability of a destination; these aren’t the same as an “update failure.”

If the results after an update differ significantly from what you expected, first save non-sensitive details that describe the change, such as the subscription display name, update message, change in entry count, and a record’s Type. Don’t repeatedly overwrite the current state, and don’t post the original URL publicly. Continue narrowing down the cause with the five-step troubleshooting checklist. For specific URLs or authentication details, contact only the person or service that maintains the information you already have. Before adding the subscription again, check whether your existing information is saved elsewhere using the Deletion and backup section.

Use names to track purpose, not to replace fields

When subscriptions, manually entered servers, and scanned entries are all present, the main challenge isn’t the number of records—it’s knowing how they relate. Give each subscription a recognizable display name, and use different Remarks for manually entered entries. Names can suggest a purpose or source category, but shouldn’t include sensitive details such as Password, UUID, or a full subscription URL. Avoid permanent remarks such as “fast” or “always works,” too: test results change, while Remarks often remain in the list and can lead to outdated assumptions.

When organizing entries, locate the subscription first, review its server results, and then check separately entered servers. If two entries have the same Remark, don’t delete one immediately. Open both and compare Type, Address, Port, and whether each came from a subscription. The same server may appear twice because it was added in different ways, or two entries may simply share a name but have different parameters. List order can change after a subscription update, so assuming “the first entry is the one I used last time” increases the chance of selecting the wrong one. If you regularly sort or filter the list, first understand what determines the order.

Distinguish listed entries from the entry currently in use

A server saved in the list isn’t necessarily selected on Home. When troubleshooting a connection, identify the current selection, determine which subscription it belongs to—or whether it was entered manually—and then check Global Routing. In Config mode, traffic follows the configuration rules; Proxy mode routes traffic through the proxy; Direct mode connects directly. The comparison below is for organizing troubleshooting, and actual traffic depends on the current configuration and app interface. Recording the routing mode helps prevent attributing behavior in Direct mode to a particular server.

If an update adds many similar entries to a subscription, check which subscription they belong to before changing the sort order. Neither latency nor a name uniquely identifies an entry: records with the same name may point to different Addresses, and latency changes with network conditions. Use a consistent manual check, such as “subscription name → server Type and non-sensitive address details → current selection → test result.” That way, you can find the right entry even when the list order changes. Before removing an entry you no longer use, check whether the current configuration still selects it.

Keep configuration files separate from subscription lists

Config may also contain rule configurations, which are different from the server list under Subscribe. In a rule, PROXY and DIRECT are policy keywords, not subscription names. The snippet below illustrates rules matching domains, geographic locations, and remaining traffic. It’s for understanding the syntax only; it contains no usable servers and shouldn’t be pasted into the Subscribe field. If a rule points to a policy that doesn’t match the currently available servers, check the configuration and server selection separately instead of repeatedly updating the subscription.

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

The goal of managing multiple subscriptions is to make each update and test traceable to a specific entry—not to shrink the list as much as possible. Keep names and source information clear enough to identify entries, then remove only what you no longer need. For more on DOMAIN-SUFFIX, GEOIP, and FINAL, see the glossary. For the basic steps to choose Global Routing for your first connection, see Getting Started.

Know what the test measures first

A latency test typically shows how a server responds under current network conditions. For Connectivity Test and similar diagnostic options, check the interface description to understand what’s being tested. A number doesn’t mean every website or rule path has the same response, nor does it verify that the connection works for everyday use. Before testing, make sure the device is online, the server entry was imported correctly, and you know the current network conditions. Otherwise, different results for the same entry at different times may simply reflect changed test conditions—not a change to the subscription.

Start by testing a few entries whose fields you’ve checked. Note whether the app displays a value, an error, or a pending state. Values are useful for comparison under the same conditions at the same time. Interpret errors alongside Type, Address, Port, authentication details, and network reachability. Don’t skip further checks based on one low latency result, and don’t delete an entry based on one timeout. A test may use a different destination or route from everyday traffic. This matters especially with Config rules: confirm whether you’re testing server connectivity or reaching a destination through a particular rule.

Sorting changes the view, not the information

Sorting by latency or another condition can make entries easier to find, but usually changes only their display order—not their permanent order in the underlying information. Entries can move after a subscription update, a change to the sort option, or another test. Identify entries by subscription and fields; don’t use “the third server” as your only clue. If an entry that failed a test moves to the bottom, that doesn’t mean it disappeared from the subscription. Check the current filter and sort settings before deciding the record is missing.

When comparing two servers, test them on the same network at roughly the same time, and check each record’s Type and source. A test can help you choose what to investigate next, but it can’t replace checking the fields. If a record passes the test but everyday access still doesn’t work as expected, return to Home and confirm that it’s selected, then check whether Global Routing is set to Config, Proxy, or Direct. In Config mode, also check which policy the rules match. Conversely, if everyday use works but an individual test shows no value, first understand what that test measures and what its message means. Don’t immediately change a configuration that’s working.

Move from server diagnostics to rule diagnostics

Check the rules only after confirming the server parameters and connection status. The lines below show where common match types appear in a configuration: DOMAIN matches a specific domain, DOMAIN-SUFFIX matches a domain suffix, IP-CIDR applies to an address range, and FINAL handles traffic not matched by earlier rules. The example.com and address range in this example are for illustrating syntax only. Whether PROXY works as expected still depends on the current configuration and server selection. Don’t treat a rule snippet as a list of latency test targets.

[Rule]
DOMAIN,example.com,PROXY
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT
FINAL,PROXY

If the problem affects only one destination, first check which rule it matches, then check the corresponding policy and current server. If several destinations fail, return to server connectivity, subscription updates, and the device’s network status. Working from specific cases to the broader setup makes it easier to identify the cause than switching servers, updating subscriptions, and rewriting rules all at once. Testing and sorting are management tools, not fixes: they help show what to check next but can’t replace the original parameters or rules. Browse Troubleshooting by topic for more symptoms.

Confirm which type of entry you’re deleting

Before cleaning up the list, distinguish subscription records, server entries generated by subscriptions, manually entered servers, and Config rule configurations. Deleting an item may affect future updates or the current selection, so don’t remove entries in bulk based only on similar names. Before deleting a subscription, check whether it’s still the update source for any server entries. Before deleting a single server, check whether it’s selected and whether it may reappear after the next subscription update. Before deleting a Config entry, check whether it contains custom rules you need to keep. Read the deletion target and confirmation prompt shown in the interface carefully.

A safer order is to check the entry’s source and non-sensitive fields, confirm whether the current connection depends on it, and make sure you’ve saved the original information yourself. Subscription URLs, server authentication fields, and rule files serve different purposes. A screenshot of one list may not be enough to rebuild a configuration, but publicly sharing a screenshot with a full sensitive URL isn’t appropriate either. Keep backups somewhere you control. You can use sanitized notes to record names and purposes; protect the complete details needed for recovery according to their sensitivity.

Back up subscriptions, manual entries, and rules separately

To recreate a subscription entry, keep the complete subscription URL you already have and a name that helps you identify it. To recreate a manually entered server, save the required fields and additional options for its Type. Save custom rule configurations separately. Don’t assume that keeping a subscription URL preserves every manually entered server, or that keeping one share link restores your previous rule file. If the current app offers options such as export, sharing, or Import from Cloud JSON, read the interface description first and confirm which kind of information will be exported or imported. Don’t infer the scope from the option’s name alone.

After backing up, verify the saved content without changing existing entries. Check that you can distinguish subscription and manual entries, that text hasn’t been truncated, and that rule snippets retain their line breaks and order. Don’t test whether a file or text containing authentication details was “backed up successfully” by posting it in a public comment or screenshot. If you only need troubleshooting notes, make a separate sanitized list with subscription display names, server Types, non-sensitive remarks, and action dates. It can help you find the right entry, but it can’t replace complete recovery data.

After deletion, decide whether to import again

After deleting an entry, return to the list to confirm it’s gone, check whether the current selection changed, and make sure other subscriptions still update as before. If you deleted a single server entry generated by a subscription but kept the subscription, it may reappear after the next update. If you deleted the subscription itself, confirm how its updates were previously managed. To rebuild an entry, choose the right method in Subscribe or Add Server; don’t recreate the same entry through QR scanning, the clipboard, and manual entry all at once.

When replacing a device or getting the app again, first follow Restore Purchases to check your App Store purchase record, then restore your own subscription and configuration details. Shadowrocket availability and system requirements for iPhone and iPad are as listed on the App Store page. App purchase status and saved server information are separate. A one-time app purchase is not a service plan, and restoring a purchased app doesn’t automatically recreate every server field you saved manually. If something is missing, first identify whether it’s the app, a subscription entry, a server entry, or a rule configuration, then restore the relevant item.