Shadowrocket Subscription and Server Management

First, identify what the information is for

Before importing, have the complete subscription URL you already received, and confirm that your provider identifies it as being for Shadowrocket. The path, query parameters, and token may all determine which list the URL returns; copying only the domain is usually not enough. Don't infer the URL's purpose from a page title or its length, and don't enter an account, login, or renewal page URL as a subscription. A webpage being accessible does not mean it contains parseable subscription data.

A server entry stores the protocol and parameters needed to connect. A subscription retrieves those entries from a remote source, while Config controls behavior such as rules and DNS. These three objects can coexist, but they are not interchangeable. Seeing servers after importing a subscription only confirms that retrieval and parsing succeeded; it does not prove the selected server can connect or that existing rules will handle traffic as expected.

Create a Subscribe entry from Home

From Home, open the add menu, go to Add Server, and choose Subscribe under Type. The exact location may vary; follow the app's current interface. Paste the complete URL, add a recognizable note, and save. If prompted to fetch or update the subscription, follow the prompt. Make sure the network is available, and avoid adding the same URL repeatedly while waiting, which can create several similar subscription groups.

Before saving, check that the URL has no leading or trailing spaces, line breaks, quotation marks, or non-ASCII punctuation. A long URL wrapped across lines in a message may still copy correctly, but text extracted from a screenshot can contain recognition errors. Pay particular attention to everything after the question mark, case-sensitive tokens, and percent encoding. Treat the URL as a credential: paste it directly into the app rather than submitting it to an unfamiliar website to check its format.

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

This is a format example, not a usable subscription. Get your actual URL from your provider. The token after the question mark illustrates a query parameter; it does not mean all subscriptions use the same parameter name. Some URLs contain identifying information in the path. Preserve the URL exactly as provided: don't remove a segment to make it look neater or add parameters from the example.

Check these four results after saving

After the first fetch, check that the subscription group appears, server entries are present, their protocols match the information you have, and the note identifies the group. If the list is empty, keep the original URL, check the app's message, and ask whether your provider changed the subscription endpoint. Don't immediately edit every server or delete the old list. Troubleshoot an import failure separately from a server connection failure.

If the list appears but contains unfamiliar names, compare them with the subscription information you already have. Don't treat a name as a guarantee of connection quality or location. Notes come from the subscription content and may change with later updates. When tracking an entry, record both its subscription and protocol, rather than relying on its position in the list.

[Check]

A successful subscription import, a successful server test, and a successful real request are three separate checkpoints. Check them in order; one does not prove the others.

If parsing fails, first check the complete URL and current network, then confirm that the response still contains subscription data. A remote service may return a login prompt, error page, or empty response; even if the request receives a response, it won't produce a server list. See Troubleshoot an empty list or parsing failure for more detail. Keep the error message, but don't include the full token when asking for help.

If the same subscription already exists, update the existing entry instead of importing it again. To try a new URL, create a temporary group with a different note and keep the original for comparison. Once the new list is complete and a real request succeeds, decide whether to remove the old entry. This separates changes in remote content from the effects of local actions and makes accidental deletions easier to diagnose.

Scan QR Code does not recognize every kind of page

Before using Scan QR Code, confirm that the code comes from your existing server information or subscription details. It may contain a single share link or just a webpage URL. Reading the code does not mean the app can convert its contents into a server entry. If scanning opens an ordinary webpage or reports a parsing error, check what the original source says it is for. A server name printed beside a QR code doesn't prove the code is for importing.

When scanning from another screen, fit the whole code in the frame. Avoid glare, cropped corners, or multiple codes in view at once. Longer QR codes tend to be denser, so making them too small can hinder recognition. Use the original clear image rather than a compressed chat thumbnail. A recognition failure points to an image or content issue; it doesn't show that the server is no longer working.

When the system asks for camera access, grant permission if needed for the action. If you previously denied it, check Shadowrocket's camera permission in Settings, then try scanning again. A permission issue is unrelated to server authentication, so there's no need to change the subscription URL. Other image-recognition entry points may differ; follow the current interface rather than assuming buttons are in the same place on every system or device.

Clipboard imports preserve the original string

When copying a share link, copy from the protocol prefix through the parameters and any note. Explanatory text, numbering, bullets, and code fences in a message are not part of the link. If the app offers a clipboard import option, copy the link and start the import from within the app, then allow access if prompted. No system prompt doesn't necessarily mean copying failed. Avoid copying something else before importing, which would replace the link in the clipboard.

Whether multiple links can be imported at once depends on how the entry handles the content. For easier verification, import one link first, check the result, then handle the rest. Some lines may be ignored if a multiline text includes explanations, blank lines, or webpage markup. Check the imported entries individually; a message saying “Imported” doesn't prove that every item was saved.

If the system asks to allow pasting and you decline, restart the action from the app's import option and watch for the permission prompt. Copying and subscription network requests are separate processes: if the clipboard content wasn't read, the problem is at the input stage; if a subscription was created but its contents couldn't be fetched, the issue is at the request stage. Identify where the failure occurred before changing an otherwise correct URL or server parameter.

After importing, compare fields—not just names

After importing a single share link, check Type, address, port, and any required TLS or transport fields. A correct note only shows that the name was read; it doesn't prove the other parameters are complete. Some formats percent-encode notes. Encoded or different-looking names don't necessarily affect the connection, but check that link parameters weren't placed in the note or that the note wasn't left in the address field.

After importing a subscription QR code, confirm that it created an updatable subscription entry, not just a server from the current list. Check the saved entry type and the update option in the app, not the QR code's title. For ongoing updates, keep the correct subscription object rather than copying a single server from it; a single-server import usually doesn't retain the subscription's update relationship.

[Privacy]

QR codes, share links, and clipboard contents may contain full credentials. Don't upload them to public decoding sites. Before sharing a screenshot for help, remove QR codes, passwords, and query tokens.

Scanning the same code repeatedly can create several similar entries. Before cleaning them up, compare their groups, protocols, and addresses, then confirm which one is selected. Entries with the same name but different parameters aren't necessarily duplicates; entries with different names but the same address may use different credentials or transport settings. If unsure, keep both for now, distinguish them with clear temporary notes, and compare them individually as described in the testing section.

After importing, you can replace the clipboard contents with ordinary text to reduce the chance of accidentally pasting credentials later. This doesn't revoke information already shared. If a complete link was exposed publicly, handle the credential change through the management interface for your existing service, then update the saved information in the app. Convenient input methods don't replace credential management; treat the original share information as sensitive data.

Preserve a comparable state before updating

A subscription update may add, remove, or rename servers, or change addresses, ports, or credentials. Before updating, confirm which group you're working with and note the selected entry and its subscription. If you're troubleshooting a connection, record the symptoms first. Otherwise, changes to the list can make it hard to tell whether the old issue or new parameters affected the result.

Don't assume an update will preserve manual changes. Subscription-managed entries come from remote content; whether local notes, sorting, or field changes persist depends on the actual result. Create a separate manually entered entry for parameters you need to maintain independently, and note its purpose. There's no need to clear the old group before updating. Keeping its previous state can help show whether the app retained existing data if a fetch fails.

What manual and automatic updates do

A manual update is useful when your provider announces parameter changes, a list is clearly out of date, or you need to recheck it after the first import. Update the relevant subscription, wait for the operation to finish, then check the message and group contents. Repeated clicks in quick succession usually won't fix a remote error and can make results harder to track. After a failure, identify whether it's a network, authentication, or parsing issue before deciding what to do next.

If the current app offers automatic update settings, choose options that suit how often you use the subscription and check what you've enabled. Background scheduling can be affected by the network, device state, and system restrictions. Setting an update interval doesn't guarantee that every request will finish at an exact time. To confirm an important change, check the list in the app and refresh it manually if needed instead of relying solely on when a background task is expected to run.

The network path used for subscription updates may depend on the current connection, routing mode, and app settings. If an update fails while a connection is enabled but succeeds when it's off, check the difference in network paths; don't immediately conclude that a server is unavailable. Compare under the same basic network conditions and change one variable at a time. Avoid switching networks, replacing the URL, and reimporting the entire subscription all at once.

Troubleshoot the failed stage instead of rebuilding

A request-stage failure may appear as a connection error, timeout, or name resolution problem. First confirm that the device can use its current network normally. An authentication or access failure calls for checking that credentials in the URL are complete and that the remote service hasn't revoked the old URL. A parsing failure calls for checking whether the response still matches the subscription format. Each stage has a different cause; don't reduce them all to “the server doesn't work.”

If the remote service has changed the subscription URL, edit the corresponding field in the existing subscription and check the update result. Renaming the group won't change the request URL, and editing one server won't fix the subscription endpoint. You can temporarily keep both versions to compare, but clearly label the old entry so you don't keep working in it and mistake that for the new URL not taking effect.

[Update boundary]

A successful update message doesn't mean the list must grow or that every server can connect. If the remote content hasn't changed, the list may remain exactly as it was.

After an update, check that the group still exists, then see whether its entries changed, and finally confirm the selected entry. If a server was removed from the remote list, you may need to recheck the local selection. An enabled connection switch alone doesn't prove that traffic is still using the same entry as before the update. If rules refer to a named object, check that the reference still points to the intended entry.

A change in the number of entries doesn't necessarily indicate a change in service quality. The remote list may simply have been split, combined, or renamed; compare the actual parameters and documentation. If repeated refreshes don't return the expected content, note the error, steps taken, and checks completed, then ask the administrator of your existing service to verify the response. Describe the issue without sharing your full subscription URL publicly.

Update Shadowrocket through the App Store, not by refreshing a subscription. Check the App Store page for whether an app update is available, compatibility, and system requirements. See How to verify the App Store listing for guidance on the official listing and app ID. To troubleshoot an empty list, check the subscription request and parsing process instead.

Identify what the test measures and how it works

Before using Connectivity Test or a test option in the list, check the test method and target used by the app. Different methods may measure a connection to the server port or include access to a test target through the proxy; these results mean different things. Compare values only when the method, target, base network, and timing are similar. Don't rank results from different modes against each other.

A test value represents one measurement or a set of measurements, not every future request. Current network load, wireless signal, server status, name resolution, and the target's response may all affect it. Don't immediately delete an entry after one high reading or assume one low reading makes it suitable for everything. Keep the network unchanged, repeat a few tests, and look for a consistent pattern before switching.

Interpret timeouts and failures in light of the test method. If the test target is unreachable, several servers may fail at once; if a protocol field is wrong, only the relevant entry may be affected. A failed test doesn't always mean the server address is completely unreachable, and a successful one doesn't prove that a particular request will work. Use the test as a diagnostic clue, then verify with a real request.

Follow a repeatable check sequence

First, confirm the basic network is working and rule out an unfinished network login or unstable signal. Next, check the selected entry and its protocol parameters to avoid testing an older entry with a similar name. Then run the test using a fixed method and wait for the result. Finally, check Global Routing and the current Config before accessing the destination you need to verify. At each step, be able to state what you checked.

If all entries fail at once, check the basic network, shared test target, and global settings first. If only one subscription fails, check whether it was just updated and whether authentication changed. If only one server fails, review its address, port, TLS, and transport parameters. Narrowing down the scope this way preserves evidence and is more effective than reinstalling the app or clearing every subscription. It also avoids recreating settings that were already correct.

Before temporarily changing a mode to compare real requests, note the original setting and restore it afterward. Don't keep a mode you don't understand just because it made one request succeed. In Config mode, a request may match DIRECT or another policy. Even a low latency shown in the server list doesn't prove that the request used that server.

Sorting changes the display, not the selection

Sorting by latency helps find entries that responded faster in the current test, but sorting doesn't automatically select one or provide ongoing health checks. After sorting, check the selected indicator; don't assume the first entry is in use. If only some entries were tested, don't group untested, timed-out, and completed results together. First check which entries the results cover.

During batch tests, avoid refreshing subscriptions or moving entries at the same time. When the list changes, test results may no longer line up with the same names and positions. Finish testing and note which entries you want to compare before updating or organizing. Retest under the same network and method to tell whether a change came from new parameters rather than a switch in network conditions.

[Evidence]

For troubleshooting, record the test method, basic network, selected entry, and actual error—not just a latency number. Remove all credentials before sharing your notes.

Latency and speed are different: a shorter response time doesn't guarantee faster large-file transfers or stable long-lived connections. This guide doesn't set a universal pass threshold because test targets, networks, and needs vary. If results fluctuate, reproduce the issue under fixed conditions first. Avoid frequent batch tests that generate extra requests; then use the stage where the error occurs to check the relevant parameters, subscription, or rules.