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

1. First, identify whether a link describes a connection or points to a list of configurations

An individual server entry in Shadowrocket stores the protocol, server address, port and authentication details. Share links beginning with ss://, vmess://, vless:// or trojan:// usually encode these fields directly in the link. Importing restores the fields locally; it does not verify that the server is reachable.

A subscription URL is usually an HTTPS address. Shadowrocket requests that address, reads the response and creates or updates a set of server entries. So whether a share link can be parsed and whether a subscription server can be reached are two separate questions. HTTPS is just the access method; regular websites and login pages use it too, so the prefix alone doesn't confirm that an address is a subscription URL.

An individual entry generally won't change automatically if its server address changes. Entries from a subscription can receive updated parameters when you refresh it. An update may also remove old entries or overwrite subscription-managed fields, so local edits aren't a reliable long-term maintenance method. This guide explains how to use configurations you already have; it does not provide, sell or recommend connection services or subscriptions.

2. ss://: Identify Shadowsocks credentials and port

ss:// indicates the Shadowsocks share-link format. The common SIP002 format puts the encryption method and password in Base64-encoded user information, followed by @server:port. Decoding the credentials below gives aes-128-gcm:password. The domain and password are dummy values.

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

• YWVzLTEyOC1nY206cGFzc3dvcmQ=: the encryption method and password encoded in Base64, not the server domain.
• ss.example.com: the server hostname. 8388 is the port in this example; the actual value must match the server configuration.
• #Example-SS: the display name. Changing it usually doesn't affect connection parameters.
• ?plugin=: Some links include plugin parameters. Don't discard them when copying; whether they work depends on the specific parameters and client support.

Some older links encode the encryption method, password, server and port together, so there's no obvious @. These two formats don't indicate different protocols. Base64 is an encoding, not encryption; anyone with the complete link can usually recover its connection credentials.

3. vmess://: Decode the JSON, then check transport and TLS

A common VMess share-link format consists of vmess:// followed by Base64-encoded JSON. Its syntax differs from VLESS URIs; changing the prefix to vless:// won't convert the protocol. The example below is decoded JSON for instructional purposes, 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",
  "scy": "auto",
  "net": "ws",
  "type": "none",
  "host": "ws.example.com",
  "path": "/connect",
  "tls": "tls",
  "sni": "tls.example.com"
}

add and port specify the connection target, id is the authentication UUID, and ps is the remark. net=ws indicates WebSocket transport; path is its path, and host is the Host value for that transport. Only tls=tls indicates that TLS is enabled. Setting the port to 443 doesn't add the TLS settings automatically.

• sni specifies the server name used during the TLS handshake. Don't overwrite it just because it differs from add.
• aid is a legacy compatibility field, set to 0 in this example. It isn't connection latency or a port.
• scy is the VMess encryption setting; it isn't the same setting as WebSocket or TLS.
• v is a format field in this type of share-link JSON, not the Shadowrocket app version.

If the address and UUID are present after import but the connection still fails, check the transport type, path, Host and SNI together. A correct server address alone isn't enough to establish a connection using WebSocket and TLS.

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

Common VLESS and Trojan share links look much like standard URIs: authentication comes before @, the server and port follow it, parameters come after the question mark, and the remark follows the hash. The examples below show the structure only; they aren't usable connection configurations.

vless://[email protected]:443?encryption=none&security=tls&type=ws&host=ws.example.com&path=%2Fconnect&sni=tls.example.com#Example-VLESS
trojan://[email protected]:443?security=tls&type=tcp&sni=tls.example.com#Example-Trojan

In the VLESS example, encryption=none describes VLESS's own encryption field; it doesn't mean the entire connection lacks TLS. This example separately specifies transport security with security=tls. Share-link parameters can vary between implementations. If the source includes fields such as flow, preserve their values and check the imported result rather than copying parameters from another link.

%2Fconnect decodes to /connect. If a password contains reserved characters such as @, # or &, they usually need correct percent-encoding. Otherwise, a parser may treat part of the password as a separator. IPv6 literal addresses in URIs also need square brackets, for example [2001:db8::1]:443. This address is for documentation purposes only.

5. Import individual links and subscription URLs from Home

Before you start, identify what type of content you have. Config manages rule configurations; a server subscription URL isn't a rule configuration just because it's also a URL. Server entries and subscription groups in Home serve different purposes from routing rules in Config.

A subscription URL may look like https://example.com/sub?token=xxxx; the domain and token here are dummy values. A real token may grant access, so keep the full query string intact and don't post it in public forums. Opening a URL in a browser doesn't guarantee the app can read a valid subscription: the response may be a login page, an error page or an unsupported format.

1. After saving the subscription, note its group name and entry count so you can compare the results after the next update.
2. Update it and check for errors or changes to server addresses or entries.
3. Select an entry, run Connectivity Test, then turn on the connection and try accessing a destination.
4. If you need to edit a subscription entry, keep a copy of the original parameters first; a later update may overwrite subscription-managed fields.

6. Choosing between manual and automatic updates

Updating a subscription requests the remote list again; it doesn't test every server or add automatic syncing to an individual share link. For the first import, update manually and confirm that the source and response are correct. Once you have a repeatable way to verify it, adjust the update settings under Settings → Subscribe as needed.

If a subscription request can only reach its destination through an existing proxy connection, check Settings → Subscribe → Update via Proxy. You must already have a working connection before enabling this setting. It can't fix an expired token or restore servers that are all unavailable. If the current connection isn't working, forcing updates through it may cause timeouts.

7. Troubleshooting: From import errors to connection failures after updates

Troubleshoot in this order: identify the type → copy the complete link → check the fields → request the subscription → test an individual entry → try accessing a destination. Share links carry connection parameters; subscription URLs provide a way to retrieve a list. Identify which layer is failing to avoid mistaking a routing issue for a format issue, or a remote server failure for an import failure.