Shadowrocket Link Formats: ss://, vmess://, vless://, trojan:// and Subscription URLs

1. Tell share links and subscription URLs apart

Text beginning with ss://, vmess://, vless://, or trojan:// is usually a single-connection share link. It packages the fields required by the protocol into copyable text. After import, Shadowrocket saves those fields as a connection entry in Home. The name is only a label for identification; it cannot replace the address, port, or authentication details.

Subscription URLs usually begin with https://. Shadowrocket requests the URL, reads the subscription content returned by the server, and parses its entries. A subscription URL is not a proxy protocol: one subscription can contain entries that use different protocols. A regular webpage URL may also begin with HTTPS; opening it in a browser does not mean it can be used with Subscribe.

2. ss://: Authentication and server address

A common Shadowsocks sharing format, SIP002, combines the encryption method and password as method:password, encodes them in Base64URL, and places the result before @, followed by the server address and port. Decoding the authentication part of the example below gives aes-128-gcm:test; test is a sample password only.

ss://[email protected]:8388#SS%20Demo

You may also encounter an older format: the entire string method:password@host:port is encoded and placed after ss://. In this format, @ is not visible outside the encoded text; that does not mean the server address is missing. Some links also carry plugin details in query parameters. If the existing service requires a plugin, restoring only the encryption method, password, and port is not enough for a complete configuration.

• Random-looking authentication text is not necessarily a subscription URL; it may simply be encoded fields.
• Base64URL commonly uses - and _ in place of some Base64 characters. Padding at the end may also be omitted, so avoid editing it by hand.
• The encryption method must match the server settings. A port of 8388 does not mean every Shadowsocks service uses that port.

3. vmess://: An encoded JSON description

A common VMess share-link format consists of vmess:// followed by a Base64-encoded JSON object. Unlike the Shadowsocks example above, the server address is usually stored in the JSON add field rather than appearing at the end of the link. The structure below is decoded for illustration; it is not an address to paste into Subscribe.

{
  "v": "2",
  "ps": "VMess Demo",
  "add": "example.com",
  "port": "443",
  "id": "00000000-0000-4000-8000-000000000000",
  "aid": "0",
  "scy": "auto",
  "net": "tcp",
  "type": "none",
  "host": "",
  "path": "",
  "tls": "tls",
  "sni": "example.com"
}

v identifies the share format, not the Shadowrocket app version. ps is a label, add and port specify the connection target, id is the UUID credential, and aid corresponds to Alter ID. The all-zero UUID shown is for format illustration only; use the complete value supplied by your existing service. Changing the label will not fix an authentication error.

• net specifies the transport. If your existing configuration uses WebSocket, you usually also need to check host and path; do not assume the TCP example above applies.
• tls and sni relate to TLS settings. The connection address and TLS server name can differ, so keep the values from the original configuration.
• scy describes VMess encryption settings. It is separate from TLS and cannot replace it.
• Encoded text may include padding characters or be split across lines when forwarded. Copy the entire original link; do not take just the first line or include the quotation marks around it.

4. vless:// and trojan://: Similar structure, different authentication

Common VLESS and Trojan share links both resemble URI structures: authentication follows the prefix, the server address and port come after @, query parameters follow ?, and a label follows #. Similar appearance does not mean you can simply change the prefix: VLESS usually uses a UUID, while Trojan uses a password, and the server-side protocol must match.

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

trojan://[email protected]:443?security=tls&type=tcp&sni=example.com#Trojan%20Demo

In the VLESS example, encryption=none is a protocol field; it does not mean the connection is not using TLS. Query parameters may also describe a WebSocket path, Host, flow, or other transport details. Field names can vary between share formats. After importing, open the entry and check that these details match the original configuration.

• If a password contains reserved characters such as @, #, or ?, it must be URI-encoded; otherwise, it may be mistaken for a field separator.
• IPv6 addresses in URIs are usually enclosed in square brackets before the port, so the address colons are not confused with the port separator.
• You can change the label to a name that is easier to recognize; do not guess the UUID, password, SNI, or path from the label.
• 443 is an example port only. Whether TLS is enabled, which port is used, and which server name matches the certificate all depend on the existing service.

5. Use Add Server or Subscribe as appropriate

First identify whether you have a single share link or a subscription URL, then choose the right entry point. Home manages connection entries, Config manages configuration files, and Settings manages app preferences. Pasting a subscription URL into a regular connection's server field will not make the app parse it as a subscription.

1. Identify the prefix

   Check the beginning of the text. Treat the four protocol prefixes as single share links. For an HTTPS URL, first confirm that it is a Subscribe URL supplied by your existing service, not an account webpage.

2. Review a single entry

   In Home, tap the “+” in the upper-right corner to open Add Server. To add an entry manually, select the matching protocol under Type, then enter the address, port, and authentication details from your existing service. After importing a share link, open the entry and check those fields too.

3. Add a subscription

   Go to Home → “+” → Add Server, set Type to Subscribe, enter your own subscription URL, add a label you can recognize, and save. Do not enter a single ss:// link as the subscription URL.

4. Check for updates

   Return to Home, pull down to refresh the subscription, and check whether entries appear. After the update, review the number of entries, protocols, and key fields. If the service has changed its content, the list may change too.

5. Test the connection

   Select the entry you want to test, allow the VPN configuration when prompted by the system, and turn on the connection. Then check how requests behave. Successful field parsing, a successful subscription update, and access to a target website are three separate outcomes; verify each one.

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

The address above illustrates the format of an HTTPS subscription URL; it is not a usable subscription. Preserve the full path, parameters, and token in a real URL, including query parameters that may look unnecessary. A subscription update may replace entries managed by that subscription. Before making manual changes you need to keep, note the original values and check the result after updating.

6. After importing, check Global Routing—not the protocol

A link determines how to connect to a server; Rule determines how requests are handled. If an entry connects but requests are not routed as expected, check Home → Global Routing. The suggestions below describe routing options for everyday use with existing rules; they are not recommendations for a protocol or service.

Scene in Global Routing is for scene settings. Check the matching scene conditions in the app; do not treat Scene as a protocol parameter in a share link. Settings → On Demand manages on-demand connection behavior; it cannot fill in a missing UUID, password, or transport path. For more field details, see Configuration Field Guide; for basic concepts, see Quick Glossary.

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

This snippet illustrates rule order only: requests to example.com and its subdomains use PROXY, while unmatched requests go to DIRECT through FINAL. DOMAIN-SUFFIX matches domain suffixes; GEOIP and IP-CIDR are IP-related rules and do not belong in a share link's authentication fields. Renaming a link to PROXY does not create a routing rule.

7. Format errors, failed updates, and credential safety