Shadowrocket
Subscription and Server Management

01 Subscribe: Set up an updatable subscription

Understand the difference between subscriptions, server entries, and Config

A subscription is a remote URL that returns server details. A server entry is a connection record shown locally after parsing. Config manages rules and related connection settings. These are related, but they are not interchangeable. Seeing a group of servers after importing a subscription only means the details reached the app. It does not confirm that the current rules route requests through those servers or that your remote account still has access. Before you begin, identify whether you have a subscription URL, a single shared link, or a configuration file URL.

This section assumes you already have your own subscription. Keep the complete URL and any format instructions from your provider. If there is an account status page, check whether the subscription is still active. Do not infer a URL's purpose from a single English word in it; some subscription paths have no obvious suffix. Subscription URLs often contain access credentials and should be treated like passwords. The URLs below are examples for illustration only; they cannot be used to connect and do not represent an available service.

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

Save a Subscribe entry in Add Server

1. From Home, open the add menu, choose Add Server, then select Subscribe under Type.
2. Enter the complete subscription URL in URL, add a recognizable name in Remarks, and save. The fields shown may vary with the current app interface.
3. Wait for the initial fetch to finish, then return to the list and check for server entries associated with that subscription. To fetch the details again, use the update action for that subscription.

Choose a name that describes its purpose, such as “Personal · Daily”; there is no need to repeat the full URL. Before saving, check that the URL's beginning, query parameters after the question mark, and ending are all intact. Watch for spaces, line breaks, or non-ASCII punctuation introduced when copying from a message. A QR code, a browser page title, and a subscription URL are different things. If you enter the URL of a display page in the URL field, the app may retrieve the webpage rather than server details.

What to check after the first fetch

Check the group name first, then inspect a server's Type, Address, and Port to confirm the returned details match your information. The number of subscription entries can change as the remote service is maintained, so “more entries” does not mean the import succeeded. If the name appears but the list is empty, distinguish among a failed request, an empty response, and content the app could not parse. Keep the original subscription, note the exact error, and avoid repeatedly deleting and recreating entries before you understand what happened.

A failed first request does not necessarily mean the URL is invalid. The current network may be unable to reach it, the remote service may be temporarily unavailable, or the response may be a login page. If you already have working entries, leave them as they are. If there are no servers, test once on your current network and once on another trusted network so you can compare results without changing several settings at once. See how to troubleshoot a subscription that fails to parse or returns an empty list.

By the end of this section, you should be able to identify the subscription parent, the servers it manages, and the currently selected connection. If you see a standalone server but no subscription relationship that can be updated, you may have imported a single shared link. Do not assume it will update automatically based on its display name; before the next maintenance, confirm that the entry actually belongs to Subscribe.

02 Add Server: Check each field when entering details manually

Choose the form by protocol, not by name

Manual entry is for when you have the complete server details. In Add Server, choose Type first, then fill in the fields required by that protocol. Authentication, transport options, and encryption settings vary by Type. After switching types, do not assume the existing fields still mean the same thing. A server name is just a label: a name containing Trojan or another protocol term does not replace the protocol specified in your server details.

Address usually takes a hostname or IP address, and Port takes the listening port on the server. If the hostname and port are listed separately, do not include a protocol prefix, webpage path, or query parameters in Address. For IPv6, follow the input format required by the current field; do not assume that brackets and port notation from a shared link belong in every form. Use the port provided for your server rather than copying one from a common example.

Check authentication, TLS, and transport separately

For Shadowsocks, the password and encryption method must match. VMess and VLESS commonly use UUID authentication; Trojan uses its own password authentication. WireGuard has a different set of keys, addresses, and peer settings, so it is not a form that only needs an address and password. Fill in Hysteria2 authentication and transport parameters from its own server details as well. This section describes what to check; it does not mean options are interchangeable across protocols.

Keep TLS-related fields consistent with the details you were given. SNI sets the server name used during the TLS handshake. The destination Address and the name on the certificate may differ, so two hostnames are not necessarily redundant. If you see a certificate error, check the hostname, device time, server certificate, and transport settings first. Disabling certificate verification is not a general fix: it can hide an address or certificate problem and changes the boundaries of connection verification.

With transports such as WebSocket, Host and Path may affect server routing. The slash, capitalization, and query parameters in Path can all matter; do not simplify them based on appearance. Host also does not have to match Address exactly. For fields not specified in your details, appropriate defaults are better than copying parameters from unrelated examples. Change a field only when your information requires it, and record each change alongside its result.

Make one change at a time after saving

When saving a manually entered server for the first time, use a recognizable Remarks label and distinguish it from subscription entries. First confirm that it saves and can be selected, then run a test and try an actual connection. If it fails, change one justified set of parameters at a time: correct the port, then check authentication, then transport. Changing Type, TLS, Path, and DNS all at once—even if the connection starts working—will not tell you which change mattered.

If a shared link for the same server imports correctly but your manual entry does not work, compare the fields side by side without exposing complete credentials. Focus on authentication characters, TLS status, SNI, and transport parameters—not just the server name. If details are missing, ask your own provider. The app cannot infer the correct password, UUID, or server listening method from a hostname.

Manually entered entries usually do not update automatically when the original subscription refreshes. If you copied one from a subscription and then changed it, mark it as “Manual” in Remarks and note why you changed it. If the remote service changes a port or credential, check each manual copy separately so you do not accidentally select an old entry with the same name.

03 Import with Scan QR Code or the clipboard

Identify the payload before choosing how to import it

QR codes and the clipboard are ways to carry text; they do not determine what the text is for. A QR code may contain a single server link, a Subscribe URL, or an ordinary webpage URL. A successful scan only means the QR code was read. It does not prove the server details are complete, the subscription is active, or the data is trustworthy. Before importing, confirm which of your existing details it represents. After import, check which group received the entry.

When using Scan QR Code, keep the entire code in view and avoid cropping its edges, screen glare, or a heavily compressed image. The system may ask for camera access the first time you scan; grant permission when you initiate a scan if needed. Whether the app can read a QR code directly from a saved image, and where that option appears, depends on the current interface. Do not upload an image containing credentials to an external scanning page just to decode it.

Always check the result after scanning

1. Confirm the result matches the details you expected, especially whether it is a single server or a subscription.
2. If an edit or confirmation screen appears, check Type, Address, Port, and Remarks before saving.
3. Return to Home, find the new entry, check its group, and only then test and select it.

A camera focus problem and a server connection failure are different issues. For a scan problem, adjust the lighting, distance, or image clarity. For a connection problem, check the parameters and network instead. If the app says the content is unsupported, check the payload format rather than repeatedly scanning the same clear QR code. A QR code from a provider may point only to a webpage. Use the client details explicitly provided there; a webpage redirect is not a server import.

Copy one complete set of details to the clipboard

When copying a link from your own details, use a dedicated copy action if available. Avoid selecting explanatory text, quotation marks, or trailing punctuation along with it. In Shadowrocket, use the clipboard import option shown in the current interface. If the system asks whether to allow pasting, confirm only after checking that you just copied the intended content. Do not tap through multiple prompts before checking the clipboard; you could import an older entry copied earlier.

For multiple lines, first confirm that the app supports the corresponding batch format. A mix of links for different protocols, explanatory text, and subscription URLs may not be handled as the collection you expect. A safer approach is to validate the process with one entry, then import only batch formats that are explicitly supported. If only some entries import, compare the original text line by line instead of pasting everything again and creating duplicates.

If a link appears truncated, check whether the trailing name and query parameters are still present. Some editors wrap a long line visually without inserting a line break; other ways of sharing text really do alter it. You can check the text boundaries on your device, but there is no need to copy complete credentials into multiple notes or shared documents. When comparing, focus on character positions and whether fields are present rather than saving copies everywhere.

If you already imported the same details with Subscribe and then scan a single entry, it will usually create a separate record rather than merging it into the subscription. That record may not update when the subscription refreshes. Before importing, check whether the entry is already in the list. If the new copy is only for a temporary test, label it clearly in Remarks and follow the backup and deletion guidance when you are done.

Finally, confirm “details imported” and “system connection established” separately. A new entry in the list does not mean the connection is turned on. System VPN configuration permission is also different from camera or paste permission. Handle the relevant system authorization only when you initiate a connection, then verify the result with an actual request. This prevents different permission steps from being mistaken for a single import failure.

04 Shared links: Formats, encoding, and configuration boundaries

The link prefix determines how it is parsed

Server sharing links usually start with a protocol-specific URI prefix, such as ss://, vmess://, vless://, or trojan://. After the prefix, authentication details, address, and parameters may appear directly, or the contents may be encoded in a structured format. Each protocol therefore requires its own parsing approach. Replacing the prefix alone will not convert a link from one protocol to another.

These examples show where fields appear. Their passwords and hostnames are fictional and cannot be used to connect. In the Trojan example, the authentication information comes before the address, parameters follow the question mark, and the remark follows the hash. The VLESS example uses a sample UUID. In actual use, keep the complete original text and confirm the transport parameters required by the server. A link that looks complete does not prove the server accepts its settings.

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

vless://[email protected]:443?encryption=none&security=tls&type=tcp&sni=example.com#example-vless

Do not repeatedly decode or assemble links by hand

Some characters in a URI act as delimiters, and special characters in authentication details or names may need percent-encoding. Percent-encoded sequences are not extraneous characters to remove at will. Repeated decoding can turn characters that belong to a field into new delimiters. If your provider supplied the link, use the original copied text. Do not remove parameters, add spaces, or change capitalization just to make it “look shorter.”

Sharing formats such as VMess may contain Base64-encoded data, but Base64 is an encoding method, not a security measure. The fact that a string can be decoded does not make the result suitable for a public page. Decoded authentication details are still sensitive. If the app cannot parse the content, check the prefix, completeness, and format support first, then inspect the fields. Do not keep trying different encoding conversions.

A remark is often at the end of a link and usually is not used for authentication, but that does not mean everything at the end can be deleted. Query parameters before the hash may control TLS, SNI, transport type, or path. Removing them may still allow import while preventing the connection from working as intended. If the imported form does not match expectations, compare the original link with the parsed fields and check whether any parameters were truncated or ignored.

A server sharing link and a .conf file are different types of data

A single sharing link mainly describes one server connection. A Shadowrocket .conf can contain settings such as rules. The snippet below is an example for the rules section, showing the basic order of matching; it is not complete connection information. Copying it will not create a server or replace a subscription. Before using it, confirm that the policies it refers to make sense in your own configuration and connection setup.

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

DOMAIN-SUFFIX matches a domain suffix, GEOIP evaluates the destination IP's geographic assignment, and FINAL handles requests that did not match earlier rules. Rules are evaluated from top to bottom, so a broad rule higher up may prevent a more specific rule below it from taking effect. When troubleshooting a server, if a request goes through DIRECT, that visit cannot show whether the proxy server works. This is why imports and routing rules need to be checked separately.

The best way to verify a shared link is not just to see whether it can be pasted. After importing, confirm that the protocol, authentication, and transport fields match the original details. If a field is missing, check whether the original format included it and whether the current parser supports it before filling it in manually from your information. Do not borrow parameters from another server when you do not know what they do; that turns a reproducible issue into a new, mixed configuration.

Before sharing your own details, confirm whether you are sharing a single server, a subscription URL, or an entire configuration. Each contains a different scope: a single entry does not include the full subscription update relationship, and a rules snippet may not include every referenced object. Label the type and purpose before sending it. That makes omissions easier to spot than sending an unexplained long string.

05 Update settings: Preserve the current state, then verify changes

Updating a subscription and updating the app are separate actions

A subscription update requests server details from a remote source; an app update is handled through the App Store. They are separate processes. A failed subscription update does not mean you need to update the app immediately, and an updated app does not mean the subscription has refreshed. For maintenance, first identify whether you are dealing with changes to remote details, a connection problem, or an app operation issue. Then choose the relevant action to avoid unnecessary variables.

Before updating, confirm that your current network can reach the subscription URL and note the currently selected server and its status. The remote service may change names, addresses, ports, authentication, or the number of entries, and the local list may change accordingly. Do not assume an update only adds entries or that old entries are always retained. Back up important manual changes first, since a refresh may replace subscription-managed data with the remote results.

Choose when and what to update

A manual update is useful after your provider announces a change, an entry stops working, or you need to check the details. If the current interface offers automatic update settings, configure them for your network conditions and usage, then check the results after a while. Automation does not replace verification: an unreachable network, account status changes, or an unexpected response format can all prevent the update you expect.

Avoid triggering updates for every subscription repeatedly just to troubleshoot one failed connection. If multiple requests fail at once, it is harder to tell whether the problem is with the network or a particular subscription. The remote service may also limit frequent requests. A clearer approach is to update one relevant subscription, check the error and list changes, then handle the others. If you rely on a connection for something important, keep its working state and choose a suitable time for maintenance.

Check the result, not the button state

When the update finishes, inspect at least one entry expected to have changed and confirm that its fields actually refreshed. A button becoming available again or a loading indicator disappearing only means the operation ended; it does not prove the returned data is correct. If your provider explicitly changed a port but the old value remains, confirm that you updated the right subscription, that its URL points to the right details, and that the remote service has published the change. Do not immediately rebuild every entry.

Some subscriptions include usage or expiration details. This information comes from the remote service and is displayed by the app; it does not mean the app independently verified your allowance. If details are missing or do not match your provider's records, check the response headers or content separately from your account status. Do not infer access from a date in a name or treat an old display as proof that a renewal has taken effect.

After an update, the previously selected entry may have been renamed, replaced, or removed. Recheck the selected entry and test an actual connection. If your rules refer to custom names or policies, check that those references still work. Data can refresh successfully while the connection path changes; that is often a selection or reference issue rather than a failed subscription request. For routing context, see the differences between the three Global Routing modes.

If you have confirmed that the remote details are wrong, wait for them to be corrected instead of guessing at each parameter in the app. Mark any temporary manual entry that works so you do not mistake it for a subscription-managed entry at the next update. After the issue is resolved, remove temporary copies and keep a clear set of subscriptions and a small number of manual entries.

06 Organize multiple subscriptions: Names, ownership, and rule references

Use subscription ownership to keep the list organized

The goal of managing multiple subscriptions is to know where each entry is updated from, why it is kept, and whether it is still in use—not to make the list as long as possible. Give each Subscribe parent a stable alias, then retain enough of the remote entry details to recognize it. An alias can describe personal use or a category, but should not contain full credentials. If two subscriptions return servers with the same name, you should still be able to distinguish them by group.

A subscription alias and server Remarks serve different purposes. The parent identifies the update source; the child identifies a particular connection. Mark manual copies separately to show how they are maintained. You might use labels such as “Personal · Daily,” “Personal · Backup,” or “Manual · Test,” but “Backup” in a label does not mean automatic failover is configured. Names are only for organization; the active settings determine what is selected.

Do not delete duplicate entries by display name alone

Two entries with the same name may point to different servers. The same address may also use a different port, authentication, or transport. To determine whether entries are duplicates, compare their subscription groups, Type, Address, Port, and key transport fields in that order. Check authentication locally; there is no need to export it to a public spreadsheet. If two subscriptions each manage the same target, a deleted child entry may reappear at the next refresh.

Decide whether you still need the subscription before repeatedly deleting the duplicate entries it manages. If you added the same subscription twice, confirm which parent is tied to current use, back up what you need, and then remove the extra parent. If the duplicate is a standalone copy created for testing, make sure no current rule or selection refers to it before deleting it. Clean up in batches and test access after each batch so you do not remove dependencies you cannot restore.

List order is not a routing policy

The order of the server list is mainly for finding entries. Moving one to the top does not necessarily route every request through it. Sorting by name does not automatically create priority or failover. Requests are also affected by Global Routing, the currently selected server, and rules and policy references in Config. After organizing the list, check those actual settings. The first name in the list does not tell you the current connection path.

If a custom configuration refers to specific names, check how references work before renaming entries. Some configurations point to an object by its exact name; others organize objects with filter expressions. Name changes affect these approaches differently. Keep naming conventions consistent with configuration references, and do not assume that references are all synchronized just because the entries still appear in the list after a rename.

Make name filters as specific as possible so broad keywords do not include unrelated entries. Remote names are not a permanent interface. If you rely on a region, symbol, or number in a name, check the filter results after an update. An empty set of candidates or an unexpectedly large set can affect policy selection even when every server connects. In that case, check the set and its references rather than repeatedly changing server authentication.

Before removing a subscription you no longer use, consider whether you need to keep it and save any details needed for recovery. Do not confuse an invalid subscription, a temporary outage, and something you no longer need. The first two are troubleshooting issues; the last is a management decision. Confirm its purpose before deleting it so you do not remove a useful backup just to tidy the list.

07 Connectivity Test: Latency, sorting, and real-world access

Understand what each test measures

Interpret Connectivity Test results in light of the test method. A TCP test mainly checks whether a connection to the server port can be established. An HTTP test also involves the specified target and the corresponding request. Results from different methods are not directly comparable. A responsive port does not mean authentication, TLS, proxy forwarding, and the destination website are all working. A failed test does not necessarily mean the server is permanently unavailable; first determine which layer failed.

Before testing, check the current method and target in Settings; the available options depend on the app interface. To compare servers, use the same network, target, and test method where possible. Mobile and Wi-Fi networks, different times of day, and the device's signal conditions can all affect the results. Tests run under different conditions do not provide a reliable comparison, even if the numbers look consistent.

One test cannot predict long-term performance

Latency is the round-trip time observed in one test or a set of tests under specific conditions. It is not the same as download speed, sustained throughput, or long-connection stability. The lowest number may come from a nearby entry point, while access to the final destination can still depend on other routes and load. Use tests to narrow down candidates, then verify with real-world use. Do not keep only the lowest-latency entry and immediately delete other entries that may still be useful.

If a test times out, retest one or two entries instead of immediately running batch tests on every subscription. Testing many entries concurrently generates connection requests and may also be affected by the current network or remote limits. If all entries fail at the same time, check the shared network, test target, and current settings first. If only one entry keeps failing, focus on its Address, Port, authentication, and transport.

Use sorting to find entries; use real access to verify them

After sorting by latency, check whether the results are from the tests you just ran and whether any entries are untested or failed. Entries in different states may be sorted differently; an empty value does not mean zero latency. Sorting does not select an entry. After sorting, select the one you intend to use and check the system connection status. If Config uses a policy group, confirm that requests actually use this entry rather than another selection in the group.

1. Keep the network and test method consistent, test the relevant servers, and note which entries fail.
2. Select an entry to check, review Global Routing and the active Config, and make sure the destination is not handled by DIRECT.
3. Connect and access the destination you actually need. Confirm that the request completes, rather than checking only whether the homepage appears.
4. When a test fails, note the exact message and check DNS resolution, connection, authentication, TLS, and destination access separately. Do not change several layers at once.

If a test succeeds but real-world access fails, check whether the rules route the destination through a different policy, whether DNS returned the expected address, whether TLS matches, and whether the destination itself is available. Conversely, a test target may be unreachable while your actual use works normally because the test conditions are unsuitable. Do not let one test result override what you observe in actual use. Use both results to narrow down the issue instead of choosing one as definitive.

If you changed Global Routing temporarily for troubleshooting, restore your usual setting when you are done. Proxy can help you examine the proxy route, but it is not a universal fix. Direct provides a direct-route comparison but cannot confirm that the proxy connection works. With Config, check the actual rule match. If REJECT blocks the destination, changing servers may not help; check the rules and possible false matches. See REJECT policies and matching boundaries.

Keep entries that have a clear purpose, maintainable parameters, and results that meet your needs in real-world use—not just a name that happened to appear at the top after sorting. Tests help narrow down problems; they do not replace checking account status or making backups. For long-term comparisons, use the same method on a small number of entries to make changes easier to identify.

08 Delete and back up: Restore the right data

Identify exactly what you are deleting

Deleting a server entry, a Subscribe parent, a Config, or the system VPN configuration affects different things. A server entry stores connection parameters; a subscription parent manages the remote update relationship; Config holds rules and other settings; and the system VPN configuration belongs to device authorization and connection settings. Check the object and its level before deleting it. “Starting over” does not mean the same thing for every item; you could leave incorrect details while removing rules you still need.

If you delete a child entry managed by a subscription, it may reappear at the next update if the remote service still returns it. Deleting the parent may also remove the entries it manages; check the confirmation prompt for the scope. In either case, deleting something locally does not cancel remote access or revoke a subscription URL that has already been exposed. Manage remote accounts and credentials through your own provider's account process.

Back up everything your setup depends on

Saving only one sharing link may restore only one connection. Saving only the subscription URL may not restore local renaming, manual copies, rule files, or personalized settings. Before backing up, list what you actually need: subscription URLs, important manual entries, the active Config, and any settings that affect connections. Do not assume a file called “Backup” contains all of these items; check the scope in the current export feature's description.

If you use an in-app backup or export option, check what it includes, whether it contains credentials, and whether restoring it will overwrite existing data. If you save items separately, label each one with its purpose and scope, such as “Rules config,” “Personal subscription URL,” or “Manual test entry.” There is no need to include actual server passwords in the name. Backup files may contain sensitive authentication details, so restrict access to where they are stored and protect them according to your device's security settings.

Restore and verify a small set of data before replacing everything

1. Check whether you need to keep the entries currently on the device, and make a separate backup of the current state if necessary.
2. Restore subscriptions, manual entries, or configurations according to their data type. Check the results and avoid importing the same details into multiple groups.
3. Check the selected server, Global Routing, Config, and related settings. The entry appearing in the list does not mean the restore is complete.
4. Test and verify real-world access. Then remove duplicates and temporary files, keeping one valid backup with a clearly defined scope.

When switching devices, verify the app and its data separately. Getting a previously purchased app from the App Store does not guarantee that all subscriptions and local configurations will be restored as expected. Whether they transfer depends on the migration method and the results. See switching devices and reinstalling for purchase and restore instructions. The app developer is Shadow Launch Technology Limited, and the product page's app ID is 932747118.

After restoring to another iPhone or iPad, the system may ask you to authorize the VPN configuration again. Authorization on the old device does not mean the new device is authorized. Also check whether your server limits the number of devices or simultaneous connections so you do not mistake a remote limit for a damaged backup. Test one entry with known parameters first, then restore other details gradually. This helps distinguish device authorization, data migration, and server status issues.

Backups need maintenance too. A backup may no longer work after the remote service resets authentication, changes an address, or you edit local rules. After a successful end-to-end check, update your valid backup and label what it contains. Do not keep an unlimited number of sensitive copies that are hard to distinguish. Also, do not delete the only old copy until you have confirmed that the new backup can be restored. Base both deletion and retention on recoverability.

The management workflow on this page is: keep track of where your details came from, check fields after importing, preserve the current state before updates, check references while organizing, verify real-world access after testing, and confirm a backup before deleting anything. For a specific error, continue with Troubleshooting. To set up your first connection, return to Getting Started and follow one step-by-step workflow, verifying each stage without rebuilding every subscription and configuration at once.