01 / SUBSCRIBE
Subscribe: entry point and data boundaries
Subscriptions, servers, and Configs: know the difference
A subscription is an address used to retrieve a server list. A server entry contains the specific parameters needed for one connection. A Config stores rules and related settings. They can be used together, but they are not interchangeable. Pasting an ordinary webpage URL into Subscribe will not create a connectable server. Importing a server share link as a rules file will not produce the expected routing behavior. Before you begin, identify what your data is for—it is more effective than trying random import options.
A subscription typically returns a set of server details when updated, which may include addresses, ports, protocols, and authentication fields. It answers “where does the list come from?” It does not mean that a particular server is selected or that a connection is active. Once the list appears, check the entries, select a server, and set Global Routing for your needs. Successful import, successful connection, and access to the intended service are three separate outcomes to verify.
This section assumes you already have your own subscription. Keep the original subscription URL and any instructions about its format, authentication, and update requirements. Do not use the URL of a management page, login page, or payment history as a subscription URL. Even if these pages share a domain, they may return entirely different data. A page loading in a browser does not prove that Subscribe can parse its URL.
Add a subscription using Add Server
Find the add option in Home, open Add Server, and check Type. To add a subscription, choose Subscribe, enter the full subscription URL, and add a recognizable name or note before saving. Controls may be arranged differently on other devices, so follow the interface you see. The key is to create a subscription record—not paste a whole URL into a server address field for a specific protocol. Check the entire URL before saving.
The path and query parameters in a subscription URL often identify the subscription; do not keep only the domain. Check for periods, quotation marks, line breaks, or leading spaces introduced during copying. A URL that wraps visually in a message may not contain an actual line break, so do not reassemble it by eye. Copy the original text, then check the beginning, end, and key parameters after pasting instead of retyping a long URL.
After saving, update the subscription and check whether server entries appear. Confirm that the number of entries matches your existing service's instructions, that names are recognizable, and that protocol fields are complete. There is no fixed expected number: the list can vary with your account and the remote data. If the result is empty, check the update error or returned content type before deleting anything. Keeping the original record makes it easier to spot a changed URL.
Establish a baseline you can verify again
After the first successful update, choose a server with clear parameters for testing. Note the local network, Global Routing state, and test destination. Do not change the subscription URL, rules file, and network environment all at once; if something fails, you will not know which layer changed. If an existing setup works, leave it untouched while importing the subscription and checking its list. This separates import issues from rules issues.
Some subscriptions also display additional details, such as usage limits or expiration dates. This information comes from the remote service; the app displays it, but it does not prove that a connection works. Conversely, the absence of these details does not mean the subscription is invalid. Check whether the update completed, whether the entries can be parsed, and whether the selected server can establish the expected connection. If needed, check your account status with your existing service.
| Item | What it does | What it does not prove |
|---|---|---|
| Subscribe | Fetches and updates the server list | That the current connection works |
| Server entry | Protocol, address, port, and authentication | That the rules match correctly |
| Config | Rules and related settings | That the subscription credentials are still valid |
Keep a brief record of your first successful import: the subscription's purpose, how you added it, the conditions used for the last successful test, and whether you also have manually added servers. You do not need to copy credentials; note where they are securely stored instead. If an update fails later, use this baseline to check what changed rather than resetting everything. For connection steps, follow the user guide.
02 / ADD SERVER
Add Server: manual fields and protocol checks
Choose Type first, then fill in the shared fields
Manual setup is useful when you already have complete server details, need to check a single entry, or want a separate test record. In Add Server, choose Type before filling in the other fields. Fields differ between protocols; the fact that they all use an address and port does not make their types interchangeable. If you change Type, recheck the fields you have entered to catch leftover values, mismatched authentication, or options that have reverted to their defaults.
A server address is usually a domain name or IP address. The address field generally should not include a webpage protocol prefix, path, or full query string; enter the port in its own field. If your details are a complete share link, use an import method instead of splitting it up and guessing at the fields. IPv6 addresses contain colons, so take particular care to distinguish the address from the port rather than guessing based on the last visible separator.
A name or note is for local identification, not authentication. Name entries by purpose or source, but do not put passwords, full subscription URLs, or private keys in the name. After saving, reopen the entry and check that Type, address, port, and authentication fields still match. A masked input does not mean the value is correct, and leading or trailing spaces from a paste can be hard to spot. Compare each field against the original details.
Protocol-specific parameters must match as a set
For Shadowsocks, check that the encryption method and password match the server. With VMess, VLESS, and other protocols, pay attention to their own identity and transport settings; do not apply one protocol's notion of a password to another. Trojan also requires the right authentication details and TLS settings. The goal is not to find a universal set of parameters, but to reproduce the settings provided by your existing service.
The TLS server name, connection address, and transport-layer Host may be the same, or intentionally different. The connection address determines where to connect first; the server name is used for TLS identity verification; Host or a path may belong to the transport layer. Do not change all three to the server's IP just to make them “match.” In particular, if the connection address is an IP, the correct server name may still be a domain. Keep the original values.
WireGuard's private key, public key, interface address, and peer address each serve a different purpose; do not paste an entire config into a single field. Hysteria2 authentication and TLS settings must also match the server, while local UDP support is a separate consideration. Read Hysteria2 and QUIC explained for an overview of its transport, but still check every parameter.
| Field group | What to check | Common mistakes |
|---|---|---|
| Address and port | Connection target and listening port | Pasting a full URL into the address field |
| Authentication | Password, identifier, or key | Missing characters, extra spaces, or values in the wrong fields |
| TLS | Enabled state and server name | Replacing the verification domain with the connection IP |
| Transport | Type, path, and Host | Adding a slash or changing capitalization without checking |
Verify each layer after saving; do not change several parameters at once
After entering the details manually, check whether the server domain resolves, whether a transport connection can be established, and finally whether the target request follows the expected route. Authentication failures, TLS verification failures, and connection timeouts are different problems. Do not change a password just because a request timed out, or change rules because of an authentication error. If the interface gives a specific error, record its category and where it occurred; that is more useful than simply noting “it doesn't work.”
Do not treat disabling certificate verification as a general fix. It may hide the real cause, such as an incorrect server name, wrong device time, or an invalid remote certificate. First check the original details, device time, and connection target, then review the transport settings. Adjust an option only when you understand what it does, when it applies, and what risks it carries. Note the change in your test record so a temporary diagnostic setting is not mistaken for a normal configuration.
If a subscription created the server entry, editing it directly may be overwritten on the next update. For experiments, keep a separate copy if the interface supports it, label its purpose, and avoid giving it the same name as the subscription entry. Change one field per test, then decide whether to keep or revert it. Once the manual entry works, use what you learned to check the existing service details instead of maintaining multiple unexplained copies.
03 / IMPORT
What to check when importing by QR code or clipboard
Scan QR Code changes only how you enter data
A QR code is just a way to carry text. It may contain a single server link, a subscription URL, or an ordinary webpage URL. Before using Scan QR Code, make sure it contains your own subscription or server details. Successful scanning means the text was read; it does not mean the content is right for the current import option or that the server has been tested. Check what type of item was recognized before saving.
Scanning with the camera may require camera permission. If you previously denied access, check the app's permissions in system settings instead of repeatedly trying to reimport the list. Adjust the distance, avoid glare, and keep the entire QR code in view to help distinguish scanning issues from format issues. A cropped edge, tiny code, or obstruction may prevent the scanner from reading the full content; this is unrelated to whether the server parameters are correct.
If the QR code and app are on the same device, use an image recognition option if one is available in the interface. If not, copy the original link and import it from the clipboard. Do not upload an image containing credentials to a public scanning website just to import it. Treat saved QR code images as credential files, not ordinary screenshots that can be freely shared.
For clipboard imports, check the original text first, then verify the result
When copying, select only the full link—not surrounding instructions, numbering, bullets, or punctuation at the end of a sentence. If the system asks for permission to read clipboard content, allow it only after confirming that you initiated this action. If the app does not pick up the expected text, copy it again from the source and check whether another copy action replaced it with a verification code, search term, or other content. Do not assume the import feature is broken.
Bulk text may contain multiple share links, but different sources use different separators. Do not assume every set of newline-separated links can be imported at once. Test one complete link first and check its type and fields before handling the whole batch. If fewer items appear than expected, check for blank lines, broken links, and explanatory text, and keep the original for comparison. Repeated imports may create duplicates; they will not fix a truncated link.
Importing a subscription URL should create a record that can be updated. Importing a single server link usually creates an individual entry. If you expected to get an automatically updating list but see only one server, check what type of link you copied. Conversely, if scanning a subscription QR code produces a group of entries, check whether the associated subscription record was also retained. The number of list entries alone does not tell you how the data was imported.
Troubleshoot recognition, parsing, and connection separately
First, recognition: can the camera or image reader extract the full text? Second, parsing: can the app recognize the extracted format, and are the required fields present? Third, connection: can the server be reached, does authentication work, and does the request match the expected rules? If the QR code gets no response, start with recognition. If an entry appears but cannot connect, trying different scanning angles is unlikely to help.
After importing, open the new entry for editing and check Type, address, port, authentication, and TLS settings. Extended parameters in a link may not map identically across different parsers, so “saved” does not mean the fields are correct. If the original details specify a path, server name, or transport that is missing, add it or obtain the correct format before testing the connection.
If you see an error such as “unsupported format,” first check that you copied the original link, not a redirect page wrapped by a messaging app. Do not change the protocol prefix to force an import, or delete query parameters you do not recognize. They may control TLS or transport behavior; removing them can save a different configuration with different behavior. For format checks, continue to the next section. For connection issues, see Troubleshooting.
After importing, confirm which group the new entry belongs to, remove any accidental duplicates, and delete credential images you no longer need. You can replace sensitive clipboard text with unrelated text, but that does not erase copies already saved by other apps or devices. If you sent a full link somewhere you do not control, follow your existing service's process for changing the relevant credentials; deleting the local entry is not enough.
05 / UPDATE POLICY
Subscription updates and rollback
An update changes the list, not just its display
A subscription update requests data from the original URL again and refreshes the related server records with the response. The remote list may add, remove, or modify entries, so an update is more than “testing the connection again.” Distinguish list changes from connection status: successfully retrieving data does not mean every server on the list works. An old server still connecting does not prove that subscription authentication is valid; these two paths can change independently.
Do not assume manual changes to subscription entries will be preserved. How remote and local records are matched may depend on names, identifiers, and app behavior. Preserve adjustments you need to keep through separate entries or a supported local management method, and label them as different from the original remote data. Otherwise, after an update it may be hard to tell whether a field was overwritten, an entry was recreated, or you selected another server with the same name.
Before updating, know which subscription and server you are using, and whether you have a backup you can restore. If your setup is working reliably, there is no need to update every device at once. Update on one device first, review the changes, and complete your checks before updating the others. This shows the real impact of the new list and keeps an original state for comparison if something goes wrong, instead of losing the baseline on every device.
Set an update schedule based on how often the list changes
Update frequency should follow the requirements of your existing service and how often its list changes; more frequent is not always better. Repeatedly requesting the same URL may trigger remote rate limits and make troubleshooting harder to follow. If the interface offers automatic updates, read what the option actually does and check its triggers and network requirements. Background scheduling on mobile devices also depends on device state, so an interval is not a guarantee of an exact update time.
Manual updates are useful when adding a subscription for the first time, after receiving a change notice from your existing service, when a list may be stale, or when you need to control changes during maintenance. After updating, check the entries, current selection, and actual connection—not just whether the refresh finished. If the previous entry was removed, select one that is still listed and test it again. A similar name does not guarantee the new entry has the same connection parameters.
The network path used to retrieve subscription data can affect update results. If a server connects but the subscription update fails, check whether the current local network can reach the subscription resource, whether DNS resolution works, and whether the URL requires separate authentication. Switching networks can provide a useful comparison, but change one condition at a time and record the result. Do not modify the entire Config just to retrieve the list; that mixes the update path with normal traffic routing.
Classify the failure before deciding whether to roll back
A connection timeout usually means the request did not complete within the allowed time, but the cause could be DNS resolution, the network path, or the remote response. A timeout alone does not identify the problem. For an authentication error, first check whether the full URL was changed, whether the credentials are still valid, and whether your existing service requires a newly generated link. If a webpage or verification page is returned, the request may have succeeded while the app is still unable to parse it as a server list.
Handle parsing errors and empty lists separately. A parsing error may be caused by a format change, truncated content, or unsupported fields. An empty list may mean the remote resource returned no usable entries. Keep the original URL and error details, check your existing service's instructions, and, if needed, verify the returned content type without exposing credentials. Do not repeatedly import an empty result into other subscription groups or use it to replace all existing entries without a backup.
If only some servers stop working after an update, first compare whether their protocols, addresses, or transport settings changed, then test other known entries in the list. Do not delete the entire subscription because one server failed, or bury the problem under repeated retries. If new entries do not work with your network conditions, keep the working ones and investigate why; this is more useful than repeatedly importing the same subscription. See Troubleshooting for more ways to classify the issue.
An update is complete when you have checked the list and verified key uses—not when the refresh animation stops. Record which stages succeeded or failed, keep the necessary rollback details, and make sure the next automatic update will not immediately overwrite a temporary fix. If credentials have changed, check your other devices for old URLs and update them one at a time. This prevents different devices' stale results from being mistaken for the same update outcome.
06 / ORGANIZE
Organizing multiple subscriptions and rule references
Keep sources distinct before changing display order
When managing several subscriptions, the first priority is knowing which subscription produced each server—not making one longer list. Give each subscription a stable, concise name that distinguishes its purpose. Keep source and purpose at the subscription level, and put details about individual servers in their notes. Avoid naming entries after ever-changing test results; after an update or sort, it can be hard to find the same item by name.
A name can follow the pattern “purpose—source label—note.” Choose a source label for your own use; it need not include a full domain or account details. If two subscriptions return entries with the same name, keep their sources distinct before deciding whether they are duplicates. Matching names do not mean their addresses, authentication, or transport settings match; different names do not mean their connection targets differ. Deduplicate based on key fields, not display text alone.
Clearly distinguish manual servers from subscription-generated entries. Use a note to mark whether an entry is a standalone record, a test copy, or one to keep long term, and note when its parameters need to be checked again. Do not rely on a temporary fix as your only working entry while forgetting that the subscription will keep updating. Clear source information helps you decide which changes are maintained remotely and which are your responsibility, preventing them from overwriting each other.
Server lists and Global Routing serve different purposes
Organizing the list does not change how traffic is routed. The Config, Proxy, and Direct options in Global Routing are different operating modes: Config routes requests according to the current configuration, Proxy sends regular traffic through the selected proxy route, and Direct connects directly. Individual requests may still be affected by system restrictions or related settings, so do not treat these modes as identical switches when troubleshooting.
In Direct mode, selecting a server and arranging the list does not mean requests are going through it. In Config mode, check whether a rule sends the test destination to PROXY. You can switch modes for comparison, but restore your normal settings after testing. Do not forget that a temporary test may leave you outside your usual rule-based routing, making later results harder to interpret.
The snippet below shows rule syntax in a Shadowrocket .conf file. It illustrates order and routing only and contains no server credentials. Rules are generally matched in sequence; a request matched earlier is not reconsidered by the last line. The example domains are for illustration only. Before adding the snippet to your own Config, check the existing rule order and policy references to avoid duplicate final rules that override subsequent entries.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXYKeep changes within a clear scope when organizing
If a policy group in your Config references specific server names or filtering criteria, renaming, moving, or deleting entries may change which members are available. Check for these dependencies before standardizing names. If a policy group becomes empty after a subscription update, a remote rename may have stopped a filter from matching; the subscription itself may still be working. Check each layer in turn: whether the subscription has entries, whether the criteria match, and which policy is currently selected.
| Global Routing | Check during troubleshooting | What organization cannot replace |
|---|---|---|
| Config | Rule order and policy references | Verifying which rule a request actually matches |
| Proxy | Currently selected proxy route | Verifying the protocol and destination work |
| Direct | Result of a direct connection over the local network | Proving that a specific server was used |
If you just want to reduce visual clutter, check whether the interface offers filtering or collapsing before deleting entries. A server still returned by the remote subscription may reappear after the next update; repeatedly deleting it is not a stable maintenance strategy. If you filter by name, confirm the filter's scope so you do not exclude similar, usable entries. Check the results again if the remote naming changes.
When organizing across devices, do not equate “same order” with “same configuration.” Devices may use different networks or Configs, and a manual entry may exist on only one of them. Before migrating, list what actually needs to match, such as subscription URLs, important rules, and the default selection. Local test results and temporary sorting may not need to be copied. This reduces backup size and avoids carrying stale state to another device.
After each major cleanup, check three things: important tasks still have a suitable selectable entry, policy references still have members, and your backup notes explain the new naming scheme. Do not merge, rename, deduplicate, and change rules all at once before testing. Work through one subscription at a time and verify each group before continuing. Organization is useful when the result is understandable and reversible—not merely neater on screen.
07 / CONNECTIVITY TEST
Latency tests, sorting, and real-world availability
First, understand what the test measures
Connectivity Test results depend on the test method, destination, and current network. Some tests mainly measure connection setup time; others may also measure the response from a destination accessed through a proxy. Check which method is in use before comparing numbers—results from different methods are not directly comparable. A low time value describes only one stage of that test; it does not directly indicate sustained throughput or the overall experience in every app.
Latency, throughput, and stability are different measures. A webpage's first load is affected by resolution and connection setup; large downloads depend more on sustained throughput; calls and interactive sessions can be sensitive to jitter and packet loss. Sorting by test results can help narrow down an issue, but it cannot replace testing real tasks. After choosing a candidate, check whether it remains stable for your needs instead of relying on its position at the top of the list.
A test timeout does not have just one explanation. The server may be unreachable, the test destination may not respond, the current network may restrict a transport, or the app's test method may not suit that route. If only the test fails while real requests work, check the test destination and method. If both fail, check the protocol, authentication, and network path. Record the two results separately to avoid treating a test endpoint problem as a failure of every server.
Make test conditions comparable
When comparing servers, use the same device, network, test method, and destination whenever possible, and avoid heavy background transfers. Test a small number of candidates first, then repeat the test later to see whether the results are broadly consistent. One unusually low result or timeout does not prove long-term quality. After switching mobile networks or waking the device, confirm the current network state before interpreting results.
Testing an entire list may send many requests at once and use device resources. If you have a lot of entries, filter by purpose or protocol and test in groups rather than repeatedly running the full list. Avoid running large tests during a meeting, download, or other important task. If performance fluctuates briefly afterward, stop testing and check the original connection before assuming the remote service remains at fault.
To check whether the local network is a factor, compare Wi-Fi and cellular data under controlled conditions, without changing the server and rules at the same time. If a protocol has problems on only one network, investigate the network conditions instead of deleting all entries using that protocol. For UDP transports such as Hysteria2, distinguish local network conditions from server settings. See How to troubleshoot slow speeds, layer by layer.
Sorting changes what you see, not whether a connection works
After sorting by latency, check whether the selected server changed. Being first in the list, being selected, and being used by a policy are different states; list position alone does not identify the connection in use. If a Config policy group is involved, check whether it selected a different entry. Make a real request and review its result after sorting to confirm that traffic follows the expected route.
Test results change with the environment, and old values may stop being useful. Retest important candidates after changing networks, updating subscription addresses, or changing server transport settings. Do not treat an old sort order as a permanent ranking or a name from the remote service as a performance guarantee. When keeping results for maintenance, record the test conditions instead of saving a number without context.
If every entry times out, stop switching servers one by one and check whether the local network works, the system connection is established, and the test destination is reachable. If only entries from one subscription fail, compare its update status and shared parameters. If the same protocol fails across subscriptions, check the local network and that protocol's settings. Grouping by common traits can narrow things down faster than rebuilding entries one by one, while preserving your original evidence.
Choose a server for the task at hand, not just the lowest number in a test. Keep a small set of candidates verified on your current network, know which subscription they belong to, and retest them under the same conditions when a connection fails. Do not delete many entries based on one test; first confirm that the problem is reproducible. Comparisons you can repeat provide a sound basis for long-term maintenance decisions.
08 / BACKUP & RESTORE
Delete, back up, and verify restoration
Before deleting, identify the item and what else it affects
Deleting one server, deleting a whole subscription, and deleting a Config affect different data. If a deleted server is still supplied by a subscription, it may reappear after the next update. Deleting a subscription record may also remove its related list, depending on the scope of the action. Deleting a Config may affect rules and other settings. Read the confirmation prompt and check whether the current selection depends on the item; do not bulk-delete based only on similar names.
Before cleaning up duplicates, decide what makes them duplicates. Two entries with the same address may use different ports, authentication, or transports. Two subscriptions with the same server names may serve different purposes. If you are not sure about an entry, keep it and add a note rather than deleting it immediately. If a policy group references it, update the reference or confirm a replacement first; otherwise the group may have no members after the list is shortened.
Deleting a local record does not revoke remote access. If a subscription URL has been exposed, removing it from the app does not invalidate copies held by others; the same applies to server passwords and private keys. To revoke access, use your existing service's credential management process, then update the records on all your devices. Local cleanup controls where information is stored; changing remote credentials controls who can access it. Neither replaces the other.
Back up the data and document what's included
Before backing up, list what you may need to restore: subscription URLs, manually added servers, Config files, policy selections, and local adjustments that would be hard to recreate. The app's export or backup options may cover different data; do not assume one file contains everything. Check the available options and their descriptions, save the backup somewhere you control, and record what it includes and what you will need to set up again manually.
A subscription URL can retrieve a server list again, but it is not a backup for manually added servers or rule configurations. Conversely, an old list containing server parameters does not guarantee that it can still retrieve remote updates. A complete recovery plan accounts for both data that can be fetched again and data that must be restored locally. For subscription-generated entries, avoid making many standalone copies just to preserve display order; doing so can make their source harder to maintain.
Treat backup files, exported share links, and QR codes as sensitive data. Choose a storage location you control and limit access; do not attach full files to public support requests. If the export option offers encryption or password protection, understand what it protects and store the recovery password somewhere else you can trust. Do not keep the only copy of that password on a device you are about to reset or replace.
| Data | What it restores | What else to check |
|---|---|---|
| Subscription record | Retrieve the remote server list again | Are the URL and credentials still valid? |
| Standalone server | Restore manually entered parameters | Are the protocol and authentication fields complete? |
| Config file | Restore rules and configuration | Do policy references still have matching members? |
| Maintenance notes | Explain names and temporary changes | Which changes should be kept or reverted? |
Verify the actual setup after restoring
After replacing a device or reinstalling, first get the app, then restore data according to the backup's scope. Getting the iPhone / iPad app and restoring subscriptions are separate steps; restoring a purchased app does not automatically restore server details. For other platforms, start at the all-platform download page, then check the backup format and the import options supported by the target platform. Do not assume a full backup from one platform can replace another platform's settings without review.
After restoration, import the Config and existing data first, check that everything is present, then handle policy references and current selections according to their dependencies. If the target device already has some entries, back up its current state before merging the two sets of data. When entries have the same name, compare their sources and parameters before removing duplicates. Confirm each group before continuing to reduce unexplained duplicates and overwrites.
After the first restore, do not immediately delete all data from the old device. Check that subscriptions update, manually added servers open in the editor, important rules are present, and Global Routing is in the expected state. Then test a real use case. The system may ask you to authorize connection capabilities again; do not treat this authorization as an ordinary backup field. Follow the current device prompts and check the connection state afterward.
Include a failure-path check in your restore test: if a subscription update fails, do you know where the original details are? If a server is removed, do you have another verified option? If a configuration reference breaks, can you find the relevant rule and policy? A backup is valuable not just because it imports, but because you know how to restore essential functions when things change. A file with unknown contents is not a reliable rollback plan.
Finally, remove temporary exports, outdated QR codes, and copies you no longer need, while keeping a current, understandable maintenance record. If you changed credentials, check whether old backups still contain information that should not be shared and handle them according to your retention plan. For everyday setup, return to the quick-start guide; for specific errors, see Troubleshooting. Before your next large update, reorganization, or migration, review the backup scope and recovery steps in this section.