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

1. First, tell the difference: does the link describe a server or retrieve a list?

Check the prefix first, then verify what the source says the link is for. Length alone won’t tell you whether it’s a subscription. ss://, vmess://, vless://, and trojan:// are usually single-server share formats containing the connection parameters required by their protocols. A URL starting with https:// could be a subscription, a webpage, or a remote configuration file; confirm its purpose and response format.

A subscription is not a proxy protocol, and https:// doesn’t indicate that the list contains only one protocol. A subscription response can include multiple server records of different types, depending on the format provided. It may also contain just one record, so the number of imported entries doesn’t tell you whether a link is a subscription.

2. What should you check in each of the four share formats?

Identifying the prefix is only the first step. Before saving, compare the actual fields in Add Server. A correct address and port don’t guarantee that authentication, TLS, and transport settings are correct. These examples illustrate the formats only; they don’t represent usable services.

ss://: Check Method, Password, address, and port

A Shadowsocks share link often Base64-encodes the encryption method and password together, followed by the server address and port. In the example below, decoding the authentication part gives aes-128-gcm:test. The example port is 8388; it is not a standard port for all Shadowsocks services.

ss://[email protected]:8388#Example-SS

• Under Home → Add Server, set Type to Shadowsocks, then check Address, Port, Method, and Password.
• #Example-SS is a remark, not part of the password.
• If the original link includes a plugin parameter, check the corresponding plugin options too; don’t keep only the address, port, and password.

vmess://: commonly a Base64-encoded JSON object

A common VMess share format encodes a JSON object after vmess://, rather than using a direct user@address format. The example below shows decoded data for illustration; it is not a complete share link you can paste to import.

{
  "v": "2",
  "ps": "Example-VMess",
  "add": "vmess.example.com",
  "port": "443",
  "id": "00000000-0000-4000-8000-000000000001",
  "aid": "0",
  "net": "ws",
  "type": "none",
  "host": "edge.example.com",
  "path": "/demo",
  "tls": "tls",
  "sni": "edge.example.com"
}

• add and port specify the connection target; id is the UUID. v identifies the share data format, not the app version.
• net=ws indicates WebSocket. host and path must match the transport settings; they aren’t all server addresses.
• Check tls and sni against the TLS settings. Don’t add or remove them just because the port is 443.

vless://: transport and TLS parameters follow the UUID

VLESS commonly uses a URI format to express its parameters. In the example below, the UUID comes before @, and the query specifies TCP transport and TLS settings. encryption=none does not mean the connection has no TLS.

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

• In Add Server, select VLESS, then check the UUID, Address, and Port.
• Next, check the transport type and TLS Server Name. If the original link includes fields such as flow, use the original values; don’t add fields based on the example.
• The same vless:// prefix can represent different transport combinations. Don’t configure every VLESS link as TCP.

trojan://: check Password and TLS Server Name separately

A Trojan link usually carries the password before @. If the password contains URI-reserved characters, they must be percent-encoded correctly. Encoding the already encoded text again changes the actual authentication value.

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

• In Add Server, select Trojan, then check Password, Address, Port, and TLS settings.
• sni is the server name used for the TLS handshake and may differ from the Address used to connect.
• Don’t disable certificate verification to work around a connection error. First check the server name, device time, and original parameters.

3. How do you choose an import option in Home?

Keep an existing subscription as a Subscribe entry. For a single share link, first try the app’s clipboard detection. The options below describe what each Add Server setting is for. “Recommended” applies only when you already have a subscription; it is not a ranking of protocol performance.

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

The HTTPS URL above is a text example only; don’t open or import it. In actual use, enter the original subscription URL you already have and keep its query parameters. If a chat app has wrapped the link onto multiple lines, check that it contains no spaces, line breaks, or trailing punctuation.

4. How should you check subscription updates and connection tests separately?

A successful subscription fetch means the list was retrieved; it doesn’t mean every server can connect. Likewise, a working server doesn’t prove the subscription URL is still valid. Subscription access and proxy connections use different requests and authentication details.

1. First, check whether the list changed. Update the existing subscription from Home and check for errors and new entries. The connection toggle alone won’t tell you whether the update succeeded.
2. Next, check which network path the update uses. If your current network can’t reach the subscription URL, and you already have a working connection, check Settings → Subscribe → Update via Proxy. This changes the network path used for subscription updates; it won’t fix an expired token.
3. Test one server. Return to Home, select an entry, and use Connectivity Test to check the result. A successful test doesn’t guarantee the destination webpage, authentication, or every transport is working; verify with an actual visit too.
4. Finally, check routing. Go to Home → Global Routing and check the current mode. Direct sends requests without a server proxy. Proxy can temporarily help isolate rule-related issues, while Config routes traffic according to the current configuration. Restore your usual mode when testing is complete.

5. Import errors, changed fields, and link privacy

Troubleshoot in order: check that the original link is complete, then verify its format, fields, and network access. Don’t start by changing the password or removing query parameters; either could turn a parseable link into a record that can’t authenticate.

Use this order for the final check: identify what you have → choose the right import option → check the fields → test updates and connections separately. This helps distinguish parsing errors, subscription access failures, server authentication failures, and routing issues—without repeatedly changing parameters that are already correct.