Shadowrocket
Subscription and Server Management Guide

02 / ADD SERVER

Add Server: manual fields and parameter checks

Manual entry is useful when you already have complete server parameters and need to verify each connection detail. Select the protocol type first, then fill in its fields. Do not enter the address and password and then repeatedly switch types. Protocols differ in their authentication methods and transport settings, and some fields may no longer apply after switching. The goal is to reproduce the supplied details accurately, not to experiment until the form looks complete.

Enter the address, port, and authentication details separately

Enter the supplied domain name or IP address in the server address field, and the supplied port number in the port field. An ordinary address field generally does not need a webpage path; do not paste a full share link into it. Remove any spaces around the domain, and make sure the port is a valid integer. If the details contain a colon, determine whether it separates the port or is part of an IPv6 address. Do not simply split the text at the final colon.

Authentication details must match the selected protocol. Shadowsocks requires the correct encryption method and password; VMess and VLESS often use a UUID; Trojan typically uses a password; HTTP and SOCKS5 may use a username and password. Do not enter a UUID as the server domain or put a remark in the password field. Copying can help avoid mistakes when characters look alike, but check for leading or trailing spaces and unexpected line breaks after pasting.

Do not guess TLS, SNI, or transport settings

Names used for TLS do not always match the connection address. The server address determines the connection target; SNI supplies a name during the TLS handshake. They serve different purposes. If the supplied details specify an SNI value, enter it exactly as given. If no value is provided, do not copy one from another server. For certificate errors, check the name, device time, and certificate status. Disabling verification is not a routine fix.

With some transports, fields such as Host and Path can affect whether the server handles the connection correctly. Slashes, capitalization, and query strings in a path may all matter; do not rewrite them to suit English reading conventions. The same address and port do not guarantee matching transport parameters. If the supplied details are missing a required field, ask your service provider to confirm it instead of copying settings from another working entry and hoping they fit.

Verify a manual entry by changing one variable at a time

Before saving, give the manual entry a clear remark so it can be distinguished from subscription-generated entries. For the initial test, select only this server and avoid changing Config, DNS, or network conditions at the same time. First check whether the parameters establish a connection on the current network; then check whether the rules behave as expected. If you change several things at once, even a successful result will not tell you which field made the difference.

A manual entry usually will not receive the same updates automatically when a subscription refreshes. If your service provider changes the port, password, or certificate requirements, check the entry again. Keep a record of the parameter source and purpose, but do not put the full password in a visible remark. Clean up duplicate test entries after checking them so you do not accidentally select an outdated entry later and mistake stale parameters for an app connection problem.

Types such as WireGuard have their own key, address, and peer parameter structures; do not configure them as if they were ordinary “domain and password” entries. Configure them manually only when you have complete, matching details, and keep private keys confidential. For an overview of the differences between types, read supported protocols and fields, then return to this section to check each field.

04 / LINK FORMATS

Share link formats and configuration boundaries

A share link encodes connection parameters; it is not simply another kind of webpage address. Each protocol has its own prefix and field structure, and parameters may be encoded. To determine whether a link is complete, check that its prefix, main content, query parameters, and remark have been preserved rather than trying to read the password by eye. If a link is not recognized, first check its format and original content. Do not replace characters blindly.

Distinguish a single-server link from a subscription URL

Content with prefixes such as ss://, vmess://, vless://, or trojan:// usually describes server details for the corresponding protocol. An ordinary HTTPS subscription URL, by contrast, is a network address for retrieving a set of entries. A prefix can help identify the type, but it does not guarantee that the content is valid or supported. The same protocol may use different encodings and additional parameters, which the app must parse in a supported format.

Do not use a share link as a browser address to test it. If a browser cannot open a protocol-specific link, that does not mean the server is unavailable. Conversely, an HTTPS address displaying a webpage does not mean it is an importable subscription. Check whether the response is in the expected format and whether the client creates the correct entry. Identify the type of source first, then use the corresponding import option.

# Subscription URL structure shown for illustration only; not a usable service
https://example.com/sub?token=xxxx

# Common single-server share link prefixes
ss://
vmess://
vless://
trojan://

Handling encoding, query parameters, and remarks

Percent-encoded text and Base64 content in a link may contain required fields. Do not convert them manually just to make them “look cleaner.” Plus signs, slashes, and equal signs can have encoding significance; if a copy tool changes a plus sign to a space or drops the final character, parsing may fail. Get the complete original text again before checking compatibility. Do not attribute a copy error to the protocol itself.

Parameters after the question mark may specify TLS, transport, a path, or other protocol options; they cannot all be treated as tracking information and deleted. In many share formats, the part after the hash is a remark, but preserve it in its original form for the app to process. If a name displays incorrectly, the remark encoding may be the cause, and the main parameters may still work. Check the displayed name and connection separately rather than treating them as the same issue.

A server link cannot replace Config

Importing a server usually saves a connection target; it does not mean rules, DNS, or Global Routing are configured. To route traffic by rules, check the current Config and configuration mode. Proxy and Direct also handle traffic differently when selected temporarily. A server name that mentions a particular use is only a remark; it does not make the client create the corresponding rules or replace an actual configuration check.

The following is an illustrative rule snippet from a Shadowrocket .conf file, not a complete configuration. Rules are checked from top to bottom in their actual file order, and processing stops at the first match. FINAL should be the last-resort rule. PROXY, DIRECT, and REJECT are rule actions, not three priorities that can be reordered arbitrarily.

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

Check format issues and rule issues separately

If parsing leaves out the address, port, or protocol, first check the original content and format compatibility. If the server parameters are complete but a domain is routed unexpectedly, check which rule matches it. Do not try to fix rules by repeatedly editing a share link, or cover up a missing field by importing an unfamiliar configuration. Handle one layer at a time so the results remain clear.

When asking for help, you can share the protocol type, error message, and a redacted outline of the fields, but do not send the full authentication content. Hiding only the displayed name is usually not enough; sensitive information may be in the encoded content or URL parameters. If you are unsure how to redact it, describe the symptom and field names only. Keep the original details in a trusted location and avoid exposing more information than necessary.

For details on when to use Config, Proxy, and Direct, see Config, Proxy, and Direct in Global Routing. This chapter focuses on data formats and the boundaries between entry types. For everyday connection steps, follow the user guide.

06 / ORGANIZE

Organizing multiple subscriptions and tracking entry ownership

When managing multiple subscriptions, the priority is not to standardize every name but to retain the source and maintenance method for each entry. You should be able to distinguish subscription-generated servers from manually added servers and temporary test entries. Otherwise, when a server stops working, it will be hard to tell whether to update the subscription, edit manual parameters, or remove a temporary entry. Organize entries to make ongoing maintenance easier; there is no need to add complex layers just for a tidy appearance.

Use consistent names that reveal little sensitive information

Name subscriptions by purpose and source label, such as “Daily A” or “Backup B.” Mark manual entries as “Manual” and temporary entries as “Test.” Do not include passwords, full subscription URLs, or authentication tokens in names. Use consistent labels for the same source to make updates and backups easier to match. Remarks can explain an entry's purpose, but should not promise that a server will always work; conditions can change with the network and remote service.

A subscription refresh may replace server names with names from the remote content, so do not keep important maintenance details only in those names. For information you need to retain long term, use a separate protected record with the subscription label and useful identifying details. Do not rely on list position to remember a server; updates, collapsed groups, and sorting can all change its position. Confirm it using at least its name, protocol, and source.

Check duplicate entries by identity, not by name

Two entries with the same name may connect to different addresses; entries with different names may use the same target. To identify duplicates, compare the protocol, address, port, and key authentication or transport settings. Do not expose sensitive fields during comparison. If entries come from different subscriptions, retain their source information even if their parameters currently match, since future updates may differ.

When you find duplicates, first remove temporary entries that are clearly the result of an accidental import. Do not delete entries under a subscription without confirming their source. Local changes may be recreated or overwritten on the next refresh; actual behavior depends on the current app. If you no longer use a subscription, complete any migration and backup first, then remove the subscription entry. Deleting a few servers individually may not change what the next update returns.

List groups and rule policies are different concepts

Groups shown on Home are for organizing the list; they should not be mistaken for policy selections in Config. Seeing servers under the same subscription only indicates a shared data source. It does not mean they switch automatically according to a rule. Actual traffic handling depends on Global Routing, the current configuration, and its policy references. After reorganizing the list, check that your existing selections still suit your needs.

Renaming an entry can affect configuration references that use its name. Before changing names, check for custom rules or policies that depend on them, and keep a record mapping old names to new ones. Do not rename everything and update the subscription at the same time. Keeping naming changes separate from remote synchronization makes it easier to identify which action affected a connection or selection.

Make small, sequential changes instead of a single large cleanup

Organize one subscription at a time: first confirm the entry is valid, check which servers belong to it, test one server, and then remove clearly duplicated temporary entries. Finish one group before moving to the next. Do not collapse, rename, sort, and delete everything at once. Changing only a few entries per pass makes it easier to return to a working state if something goes wrong, without rebuilding the entire list.

Test and sorting results are only part of the basis for organizing entries; they should not determine deletion by themselves. A server that times out on the current network may behave differently on another network, and a temporarily high latency does not mean its parameters are invalid. Record “currently unavailable,” “parameters expired,” and “no longer needed” as separate states before deciding to keep, update, or remove an entry. This helps prevent temporary network issues from causing data loss.

When using multiple devices, be clear about how each device syncs and who maintains it. Saving the same subscription on two devices does not mean manual remarks, sorting, or selections will stay in sync. Do not assume a change on one device takes effect everywhere without confirming the sync method. After moving to another iPhone or iPad, check its servers, Config, and system connection authorization independently.

08 / BACKUP & REMOVE

Safe steps for deletion, migration, and backups

Before deleting anything, confirm the object, scope of impact, and available recovery materials. A single server, subscription entry, Config file, and system VPN configuration are different objects; deleting one does not remove the others. If you want to stop a connection, disconnect first and check the On Demand conditions. If you want to organize the list, manage its entries. Do not delete all your data just to disconnect normally.

Back up the necessary details before deleting anything

At a minimum, a backup should include valid subscription URLs, manually entered server parameters, the Config actually in use, and notes that explain how they are related. A subscription URL can retrieve the current remote content, but it cannot guarantee recovery of a previous server list. A configuration file may not include every manually added server. Identify the materials needed to rebuild each object; do not rely on a screenshot of the list alone.

If the current app provides an export, share, or backup option, check what it includes and whether it contains authentication details or custom configuration. Different options may export only a single entry rather than the entire state. After exporting, check in a trusted location that the file is readable and complete before deleting the original entry. Do not assume that a file can be restored successfully just because it was created.

Protect backups containing sensitive information

Backups may contain subscription tokens, passwords, UUIDs, or private keys. Store them in a protected location under your control. If you sync between devices, check the account, devices with access, and sharing scope; do not use a folder that is public by default. Label backups clearly by purpose and contents, but never put full credentials in the filename. After a temporary export, also remove copies from message attachments, the photo library, and other transfer locations.

Reinstalling the app and restoring its working data are separate tasks. To get a previously purchased app on a replacement iPhone or iPad, see how to restore a previous purchase. Reinstalling the app does not guarantee that servers, subscriptions, and custom configurations will all be restored. Do not rely on assumptions about system backups; confirm in advance that you can rebuild essential data and keep a separate checklist.

Clean up entries in small, deliberate steps

Before deleting a server, switch to another entry confirmed to work and check whether any name references depend on it. Before deleting a subscription, read the confirmation prompt and check what will happen to associated entries; the current app's prompt is authoritative. A single server removed from a subscription may reappear on the next refresh. If you are retiring a source for good, plan at the subscription level rather than repeatedly deleting entries after every update.

Before deleting Config, export any custom content and confirm that another suitable configuration is available. If access behavior changes afterward, first check the current Global Routing and selected file rather than immediately changing a server password. If you remove the system VPN configuration, a future connection may request authorization again. That rebuilds the system connection configuration; it does not mean the subscription must be purchased again or server credentials have expired.

After recovery, verify the import, selection, and connection

During recovery, add the subscription or manual servers first, then confirm the list and source. Next, import and select the required Config, and finally check Global Routing and system connection authorization. Do not restore a large number of old entries and immediately delete duplicates; first verify one complete working path. If a configuration copy is from an earlier setup, check that the server names it references still exist so that a successful restore does not point to missing entries.

Keep the old device and valid backup materials until verification on the new device is complete. Once everyday access, subscription updates, and custom rules all work, remove copies you no longer need. If a subscription token or password in a backup has been reset, use the current details from your service provider. An old backup can help explain the configuration, but it can no longer serve as valid authentication material.