Shadowrocket
Subscriptions and Server Management

Subscribe and subscription types

A subscription URL is not the address of a single server. It provides access to a set of connection details. After import, the app usually keeps both the subscription source and the server entries parsed from it. The source determines where the app requests updates; the entries provide the settings used for connections. Editing a server does not change its subscription source. Likewise, changing the subscription URL does not necessarily replace all existing entries immediately. Keep these two layers distinct so you can tell whether a problem occurs during the request, parsing, or connection stage.

Identify the source from the existing link

First, check whether your existing details are for a server subscription or a configuration file that includes rules. An HTTPS address alone won’t tell you which: a web page, subscription response, and configuration file can all use HTTPS. Check the stated purpose of the details you have instead of guessing from the filename. In Home, use Add Server and choose Subscribe to add a server subscription. In Config, Subscribe is for configuration subscriptions. Follow the labels shown in your version of the app: the names are similar, but server lists and rule configurations are different things.

1. Copy the full subscription URL you already have. Check that the beginning, end, and query parameters are intact, and leave out any quotation marks or line breaks from the message.
2. In Home, open Add Server and choose Subscribe under Type. Enter the URL in the appropriate field and add a name that’s easy to recognize.
3. After saving, return to Home and check for the subscription group and its server entries. Review the details, then choose an entry to test the connection.
4. If your existing details are specifically for a rule configuration subscription, open Config and use Subscribe. Afterward, make sure the intended configuration file is selected.

Check that saving and fetching both succeeded

A form that saves successfully only confirms that the app accepted your input. It does not mean the remote source returned content the app could parse. If no server entries appear, first check for a request error, then verify that the URL is complete. A URL that opens in a browser may lead to an account sign-in page, an informational page, or an access error—not a valid subscription. Don’t paste a web page’s contents into a server address field. Check the original details for the correct URL and confirm that your account can access them.

After importing, do a quick spot check: confirm the entry types match your existing details, open a sample entry to review its address and port, then test the connection manually. A different-than-expected number of entries doesn’t necessarily mean the import failed. The subscription’s current response, supported fields, or filtering may affect the result. Compare it with the information for that same source, not the number of entries from another source. For your first test, select one known server so automatic selection doesn’t obscure which entry is being used.

If you’ve imported servers but can’t connect, don’t keep adding the same subscription. Check the selected server in Home, Global Routing, and the connection switch. Then follow these steps for when the connection switch is on but there’s no internet access. Importing a subscription only brings details into the app; it doesn’t confirm that authentication, the remote service, DNS, and rules are all working.

Check Add Server fields

Use Add Server when you already have the complete details for a server and need to enter and check them individually. The goal isn’t to fill in every field: first select the right Type, then enter only the details that protocol requires. A field’s meaning can vary by Type, and you shouldn’t add options that aren’t shown based on guesswork. Address, port, authentication, and transport settings are separate layers. A connection test is meaningful only when each matches the details you already have.

Choose a Type before entering the basic details

1. In Home, open Add Server and check Type first. If you change it, review the form again so you don’t carry over authentication details from the previous type.
2. Enter a domain name or IP address in the server address field and the corresponding port in Port. Don’t put a full share link, path, or port suffix in the address field.
3. Depending on the Type, enter the Password, UUID, encryption method, or other authentication details. Preserve capitalization, hyphens, and required symbols.
4. Check TLS, SNI, transport, and path against your existing details. Save, then reopen the entry to confirm the values were saved correctly.

The server address identifies the connection destination. SNI in TLS declares a name during the handshake, and the two aren’t necessarily the same. If your existing details specify an IP address and a separate domain name, don’t assume the domain should replace every field. Port is the remote listening port, not the web port used by a subscription URL. TLS does not determine the port, either. Every value you enter manually should come from a source in your existing details. If a required value is missing, get it rather than trying common numbers.

Troubleshoot authentication and transport separately

Authentication failures and transport handshake failures call for different checks. For authentication, check that the credentials are complete and still valid, and that you selected the right protocol. For transport failures, check the transport type, TLS name, and path. Some credentials contain symbols that keyboards may replace when you type them. After copying, check for full-width characters and spaces at either end. Keep UUIDs in their original format. Don’t decode a Password just because it looks encoded. Enter the original value in the corresponding field, not a version that’s simply easier to read.

With transports such as WebSocket, Host and Path may each be used to construct the request. Don’t put the entire address in Path or remove its leading slash without checking. TLS, SNI, and certificate verification are related, but turning off verification is not a routine fix. For certificate errors, first check that the name, device time, and server details match. If a parameter is unclear, keep the error message and check your original details. That’s more useful than changing several security settings at once.

Name entries by purpose and source; don’t include a Password or full access token. A label such as “Personal test / manual / Trojan” can distinguish different settings for the same address. Before making changes, duplicate the test entry and keep the original. Change one type of setting at a time, then repeat the same test. Once it works, identify which change made the difference; don’t keep every attempted change in the main entry. For protocol definitions and rule terms, see the quick reference.

You’ll generally need to maintain manually entered entries yourself. Don’t assume a subscription update will sync their passwords or ports. Even if an entry has the same address as one in a subscription, the two may be separate records. If the remote settings change, check the source and your local manual copy separately. A failed copy doesn’t necessarily mean the whole subscription is unavailable.

Scan QR Code and clipboard imports

A QR code or clipboard is a way to transfer details, not a connection protocol. A QR code might contain a single server share link or a subscription URL. Clipboard contents could be a name, explanatory text, or web address. After the app recognizes the content, check what kind of item you’re about to import. A successful scan message doesn’t mean you should turn on the connection immediately. Read the content, confirm its type, save it, check its fields, and only then test the connection.

Scan the QR code and check the saved entry

1. Open Scan QR Code from the entry provided in the app. Grant camera access only if you need to scan with the camera.
2. Fit the full QR code in the viewfinder and hold the camera steady. Avoid cropped edges, glare, and other QR codes in the frame.
3. After scanning, check whether the app opened Add Server, a subscription form, or another confirmation screen. Review the name, Type, address, and Port.
4. After saving, return to Home and check which source the new entry belongs to. If there’s already a similar entry, compare them before deciding which one to keep.

If the QR code is displayed on the same device, you may be able to scan it from Photos if the scan screen supports that. If there’s no such option, import the original text link instead of repeatedly taking screenshots. Using a photo changes how you provide the input, not what you need to check. Resizing, compression, cropping, or annotations may make the full content unreadable. Use a clear original image or get the text directly from your existing details. The denser the QR code, the more important a sharp image and clear margins are.

Clipboard import: what to check

When copying a link, select the entire text from its protocol prefix through the last parameter. Don’t include a title, bullet point, or explanatory text. Return to the app and continue using the clipboard detection prompt or import option shown. If iOS asks for paste permission, make sure the request follows an action you just initiated. The prompt may appear at different times depending on system settings; if it doesn’t appear automatically, that alone doesn’t mean the link is invalid. Open the relevant form to check whether paste is supported, then verify the text format.

When copying from chats or web pages, the visible text may not match the actual link. A page might show a shortened URL, the text may contain line breaks, or Chinese punctuation may be appended at the end. Don’t guess at hidden characters or retype the link from the screen. Copy the original URL instead. For multiline text containing both notes and server entries, what the app recognizes depends on the format. Start with one complete entry, confirm it parses as expected, then import the rest.

If the Type after scanning doesn’t match the original details, cancel before saving and check whether the QR code belongs to a different entry. If fields are missing, keep the original details and enter them manually in Add Server. Don’t fill in similar-looking fields in the wrong form. If you need to compare with an existing entry, label the temporary one “QR test” to tell them apart. Remove it after comparing, so it isn’t selected accidentally next time. Before deleting it, make sure it isn’t the only copy you could recover.

The content remains in your clipboard or photos after import. Don’t use a QR code with real credentials in a public troubleshooting screenshot, and avoid leaving sensitive links in your clipboard. When you’re done, copy ordinary text to replace the current clipboard contents and remove temporary photos as you normally would. For a comparison of import options, see four ways to import subscriptions and servers. The same security precautions apply to every method.

For troubleshooting, note whether the QR code wasn’t recognized, was recognized as the wrong type, or saved but failed to connect. These outcomes relate to input, parsing, and connection, respectively. Treat them separately so an image clarity issue isn’t mistaken for a server failure.

Share links and Config formats

Share links encode server details in text that can be passed along. A subscription can return a set of these links. When you see a protocol prefix, first decide whether it describes a single server or a source of content, then choose the right import method. Common prefixes include ss://, vmess://, vless://, trojan://, and hysteria2://, but the same prefix doesn’t guarantee identical parameter combinations. The protocol, transport, security settings, and encoded name all need to be parsed. A recognized link still needs a full field check.

Check the prefix, query parameters, and name separately

Some formats encode authentication and address in the main body; others show the address, port, and query parameters directly. Settings such as TLS, SNI, and transport may follow a question mark. Text after a hash is usually a name or note. A display name that looks wrong doesn’t necessarily mean the connection settings are damaged; a normal-looking name doesn’t prove the query parameters are correct, either. Check the parsed fields in the app instead of judging by how readable the link is. You can change the local display name to make it easier to recognize, but keep the original connection details separately.

Percent-encoding represents reserved characters, while some link bodies use Base64. Don’t confuse the two or repeatedly decode the whole link. A valid symbol in a password, path, or name could turn into a delimiter if decoded incorrectly, changing where fields begin and end. Keep the original text when copying. To troubleshoot, compare the app’s fields with your existing details. Don’t send decoded credentials to a public text-processing tool. Encoding makes text easier to transfer; it does not keep it private.

How server details differ from rule files

A server entry tells the app where to connect and how to authenticate. Config determines how requests are handled. The two work together but aren’t interchangeable. Importing a rule file alone generally won’t provide the server credentials you need; importing a server doesn’t mean your rules are active. To troubleshoot routing, check the selected server in Home, the current Global Routing mode, and the file actually enabled in Config. Don’t rely only on whichever copy happens to be open in the editor.

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY

These are examples of rule syntax, not a complete configuration for every network. DOMAIN-SUFFIX matches domain suffixes, IP-CIDR specifies an address range, GEOIP checks the relevant address-location data, and FINAL is a fallback rule. Rule order affects which rule matches. A broad rule earlier in the list may prevent a more specific rule from being reached. PROXY and DIRECT are policy keywords. Keep them as written, and don’t replace commas or add explanatory text when copying.

When Global Routing is set to Config, check the rules in the selected configuration. Proxy and Direct apply different overall routing choices. These are not three sets of server details or three subscription sources. To check the effect of a rule, note the current mode, test the same destination once, then restore the previous mode. Don’t replace the entire Config while testing a subscription; otherwise, it’ll be difficult to tell whether a change came from the server or routing policy.

If you’re unsure whether an extended parameter is supported, check the corresponding field in the app and the original details. Don’t remove every unfamiliar parameter and save: the link might become importable but lose a required setting. Check format issues before and after import. For rule issues, troubleshoot in Config. Keep these two paths separate.

Subscription updates and troubleshooting

Updating a subscription requests its existing source again and parses the current response. It’s not simply a test of whether the old servers are online. After an update, entries may be added, removed, renamed, or changed, depending on the remote content and how the app handles it. Before updating, identify which entries belong to subscriptions, which ones you entered manually, and which one is currently in use. Treat local edits to subscription entries as changes that may be overwritten by a future update—not as your only long-term copy.

Run a manual update you can verify

1. Note the current source name, selected server, and important local changes. Make a recoverable backup of anything important first.
2. Use the update action for that subscription. Update one source at a time and check the result and any error message.
3. Compare groups, names, and settings before and after the update. Check that the entry you use is still there.
4. Reconnect using a server you’ve checked. Verify the same destination, then move on to other sources.

Manual updates are useful when you want to review changes or update infrequently. If the app offers automatic updates, enable them after a successful manual update if they suit your maintenance routine. An automatic update schedule doesn’t determine when remote details change, and frequent requests won’t fix expired credentials. Background execution, local network conditions, and the app’s state can all affect when an update runs; a scheduled time isn’t a guarantee. If there’s a problem, run a manual update with the app open to get a clear result.

Separate request failures from connection failures

If a subscription URL can’t be reached, check your current network, DNS resolution, and whether the URL is complete. If your connection state might affect the request path, note it and run a controlled comparison. Don’t switch settings back and forth without recording what you changed, or you may not be able to reproduce the issue. For an authentication response, check whether the URL is still valid. If the content can’t be parsed, determine whether the response is a subscription or a web page. Check server settings and connection availability only after the app has received content it can recognize.

A successful update doesn’t mean every server is usable. A subscription can return details normally while one server is temporarily unreachable. Likewise, a working old entry doesn’t prove the subscription URL is accessible. Record these results separately. If only some entries remain after an update, check whether the remote source changed, a filter is active, or the app can parse the relevant types. Don’t refresh repeatedly. First understand what changed in the initial update and keep the original error details so you don’t lose useful troubleshooting clues.

If you need to replace a subscription URL, back up the old source and identify the purpose of the new one first. Test the new source under a separate name and confirm its entries and connections work before removing the old record. Don’t delete the old source, clear the configuration, and reset settings all at once; you’ll have nothing to compare if something goes wrong. After updating, check that Global Routing and Config are still as expected. Subscription maintenance shouldn’t change routing behavior unless that’s an explicit part of the task.

For a maintenance log, record the source, what changed, which entry you tested, and the outcome. There’s no need to include the full subscription URL. You’ll have a useful record without spreading sensitive details across screenshots and notes.

Organize, name, and deduplicate subscriptions

When you have multiple subscriptions, it’s most important to know where each entry came from—not just whether the display names look tidy. Two entries with the same name may have different addresses, ports, or credentials. Different names may point to the same remote server. Before organizing, identify each level: subscription source, servers in each source, standalone entries you added manually, and temporary test copies. Make each type easy to recognize so you don’t update the wrong group or accidentally delete a live entry while clearing test data.

Name by purpose, not by credentials

Name subscriptions with a purpose and a source label that makes sense to you. Use server notes to identify a protocol or testing purpose. For example, “Work / primary” or “Personal test / manual” can help distinguish entries. Don’t put a Password, access token, or full account identifier in a name. Avoid using a test result as a permanent name, too: remote status and local network conditions can change. A name based on an old test can lead you to choose based on outdated impressions instead of current results.

1. Check each source and its entries first. Don’t delete entries in bulk from the full list.
2. Clearly label standalone manual entries and test copies. Keep the original details in a private, secure location.
3. Compare Type, address, Port, authentication, and transport settings when checking for duplicates—not just the display name.
4. Choose which entry to keep. Check whether Config or a policy refers to its name, then clean up a small batch and verify the result.

The remote source may control names within a subscription, so local renaming might not persist after an update. For categories you want to keep, use the source grouping or notes available in the app instead of rewriting lots of source-managed fields. If you save a standalone copy, note that it no longer depends on updates from the original source and will need manual maintenance. The more copies you keep, the more work they take to maintain. Keep copies for troubleshooting or recovery, not to repeat the full subscription every time it updates.

Compare settings before deciding entries are duplicates

Matching display names only mean the names overlap. Different credentials may have different access, and different transport paths may use different server settings. Before deleting an entry, open it and compare at least its address, port, protocol, and security settings. Check credentials only in a private environment. If only the address matches, test the entries separately and keep a note of what makes them different. Similar-looking list entries aren’t necessarily duplicates, and similar test latency doesn’t prove they are.

If a configuration uses a specific server name or a policy group member, renaming or deleting it may break references. Check the relevant Config before organizing entries; don’t focus only on Home. For policy keywords such as PROXY, understand how they relate to the current selection. A matching display name doesn’t guarantee the reference will remain valid. After organizing, select the intended server, confirm the enabled file in Config, and test a fixed destination. If something goes wrong, restore the name or entry you just changed instead of making more changes.

Having multiple sources doesn’t mean you need to switch between them often. Choose a verified reference entry and test other sources as needed. Labeling entries “in use,” “backup test,” or “needs review” is easier to revisit than sorting only by name. Store these notes securely and don’t combine status labels with credentials. Work on one source at a time, completing its update, review, and test before moving on. This helps prevent mix-ups and missed changes.

If you’re not using an entry but haven’t verified that it can be restored, keeping it for now is safer than deleting it. Confirm that the original details are available, the backup can be restored, and any configuration references have been handled before the final cleanup. A tidy list is the result; traceable sources and a clear recovery path are what make the work complete.

Connectivity Test, latency, and sorting

Connectivity Test provides a result under particular conditions; it’s not a permanent rating of a server. What the test measures—whether it establishes a connection, completes a protocol handshake, or reaches a test destination—depends on the method used. Before comparing a time value, find out what was measured. A reachable address doesn’t prove authentication succeeded, and successful authentication doesn’t mean every website is accessible. Separate these stages to explain results such as a successful test with failed browsing.

Keep the test conditions consistent

1. Check whether the device is using Wi-Fi or cellular data, and verify that the local network is working.
2. Choose one test method and destination. Note Global Routing, the selected server, and relevant configuration settings.
3. Test a small number of candidates under the same conditions. Repeat an unusual result without changing multiple settings at once.
4. Connect using a candidate server, test your usual tasks, and then decide whether to change the order you use.

TCP tests mainly show whether a connection to the destination port can be made. On their own, they don’t prove that proxy authentication and subsequent data transfer are working. A test may also mean different things for protocols using different underlying transports. If the app can test access to a destination through the proxy, include the destination’s response in your assessment. An unreachable destination, DNS issue, or temporary refusal can affect the result. Time values from different test methods shouldn’t be combined into a single comparison; first make sure you’re measuring the same thing.

Sorting doesn’t automatically select a server

Sorting by test results usually changes the order in which entries appear; it doesn’t necessarily switch the app to the first one. The server actually used depends on the current selection and the policies in your configuration. After sorting, check which server is selected. If Config uses a policy group, check how that group selects its members, too. The lowest time from one test is just an observation for that destination at that moment. It doesn’t guarantee higher sustained throughput or better performance for every task. List position is not a substitute for checking connection status.

Testing many servers at once can increase short-term load on your device, local network, or remote servers, and make results more sensitive to temporary fluctuations. Testing a few candidates in batches makes it easier to compare like with like. If one result times out, repeat the test under the same conditions. If it continues to fail, check the settings and distinguish an unreachable address from an authentication error or failed destination request. Don’t delete an entry based on a single red status or blank result, especially when your local network is unstable.

If the same server behaves differently on Wi-Fi and cellular, keep its settings unchanged and record each network condition. This helps determine whether the local connection is involved. If every server fails on the same network, check your local network and DNS before re-entering credentials. If only one entry keeps failing, compare its Type, Port, TLS, and transport settings. This layered approach avoids repeated work; see how to troubleshoot slow speeds step by step.

Record the test method, destination, network conditions, and result—not just a time value. Keep source groups and recognizable names after sorting so you can verify them again after the next update. Use a test result to guide maintenance only if you can reproduce it with the same steps. If a difference remains unexplained, mark it for review rather than concluding that a protocol or server is permanently unavailable.

Delete, back up, and restore on a new device

The last step in server management isn’t deletion; it’s making sure you can recover afterward. The app, subscription sources, server entries, and Config files are separate items. Restoring one doesn’t automatically restore the others. App Store purchase history lets you redownload the app. Your server credentials, subscription URLs, and local configurations still need to be saved separately. Make a list before moving to a new device instead of discovering missing details afterward. Check the App Store page for system requirements and purchase availability.

Create a backup checklist for each item

Keep the full URL and purpose for each subscription source. For manually added entries, save the protocol, address, port, authentication, and required transport settings. Keep the full Config file and note whether it’s enabled. If the app offers export or backup, first check exactly what it includes. A filename alone doesn’t tell you what’s covered. Some exports focus on configuration text, while other actions share only the selected server. Know what each one contains before relying on it for restoration. Keeping the original details securely also helps you check whether an export missed any extended parameters.

1. List your sources, manual entries, Config files, and key settings. Note where the recovery details for each are stored.
2. Export using an option available in the app. Check that the file includes the expected items and store it somewhere protected.
3. If possible, test the restore using a separate test entry or device. Don’t overwrite the only working copy.
4. After restoring, check the fields, selected server, Global Routing, and Config, then test the connection and access.

A QR code, a single share link, and a full backup cover different things. A QR code for one server usually won’t restore the subscription source or its update relationship. Saving only a subscription URL won’t restore local edits, standalone entries, or rule files. A full backup, on the other hand, may contain a lot of sensitive information. Restrict access and keep it separate from public screenshots. Before deleting the original details, confirm whether the backup is encrypted, how it’s unlocked, and how to read it on the destination device. Don’t wait until a failed restore to figure that out.

Know the difference between deleting an entry, removing a source, and disabling Config

Deleting one entry from a subscription doesn’t remove it from the remote source; it may return after the next update. Removing the entire subscription source may also affect its entries, so read the app’s confirmation prompt before proceeding. Disabling or switching Config doesn’t delete servers, but it changes how requests are handled. Work on one type of item at a time, then check the current selection. If a server was removed, don’t rely on its old name to determine which one is being used. If policies reference it, check that their members still exist.

After restoring, don’t assume the connection switch, system authorization, or in-app selection matches your old device. Open Shadowrocket, check the imported content, select the server you’ve verified and the intended Global Routing mode, and follow the system prompts to authorize the VPN configuration. The system prompt sets up the device’s network configuration; it doesn’t provide server details. For redownloading the app and checking purchases, see the new device and reinstall guide. For what the one-time app purchase covers, see one-time purchase and service costs.

If you deleted something by mistake, stop cleaning up and check your backups, original details, and any other devices that haven’t been changed. Don’t keep updating to guess whether a standalone entry will come back, and don’t overwrite an intact copy. After restoring a copy, check what it contains before testing the connection. Keep the original backup until you’ve confirmed the restored copy works. Record what you kept and where the recovery copy is stored, then update the backup after future changes to important settings.