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

Start with the link prefix: connection settings and subscription URLs are different

In Shadowrocket, a single-node share link usually describes one connection entry: the protocol, server, credentials, and whether TLS or a specific transport is enabled. ss://, vmess://, vless://, and trojan:// are the four schemes covered here. Similar prefixes do not mean their fields are interchangeable.

A subscription link is usually an HTTPS URL. Shadowrocket requests that URL, reads the node list returned by the server, and creates or updates entries based on the response. The URL itself may not show the server address and port; those details are often in the response body. Not every HTTPS URL is a subscription: account pages, sign-in pages, and documentation pages are not subscription endpoints.

A subscription can return multiple nodes or just one, so the number of imported entries alone does not identify the link type. Better indicators are whether you imported it as Type Subscribe, whether the subscription source was saved, and whether it can be requested again for updates. A one-time app purchase ≠ a service plan; the app and credentials for an existing service are managed separately.

ss://: Shadowsocks credentials and encoding boundaries

A common Shadowsocks share link contains encoded credentials, a server address, a port, and optional query parameters and remarks. The credentials usually include an encryption method and password. Below, BASE64URL represents an encoding operation, not literal text you can paste to import a node.

ss://BASE64URL(method:password)@server.example:8388#Office
Credentials example: aes-128-gcm:demo-password
Server example: server.example
Port example: 8388

• method specifies the Shadowsocks encryption method and must match the server configuration. Do not substitute a different method just because its name looks similar.
• password is a connection credential. Base64 and Base64URL are encodings, not encryption; decoded content should still be treated as sensitive information.
• What follows @ is usually the server and port. IPv6 addresses used as the host must be enclosed in square brackets to avoid confusing address colons with the port separator.
• #Office is a remark used mainly to identify the entry. Changing the remark will not fix an incorrect server address, password, or port.
• Links containing plugin= may also include plugin parameters. Being able to read the basic fields does not guarantee that all extensions are supported in your current setup.

Some older share formats encode a longer connection string as a single block, so the presence or absence of a visible @ is not a reliable test on its own. Keep the original link from your service provider, let the importer parse it, then check the result in the entry editor on Home. If the decoded credentials appear truncated, copy the original text again instead of guessing the missing password.

vmess://: Commonly carries Base64-encoded JSON

Common VMess share links start with vmess://, followed by a Base64-encoded JSON payload. Unlike common VLESS URIs, they do not display user-info@host:port directly. The example below illustrates decoded fields only, using a reserved example domain and a demonstration UUID; it does not represent a real service.

{
  "v": "2",
  "ps": "Office",
  "add": "server.example",
  "port": "443",
  "id": "00000000-0000-4000-8000-000000000000",
  "aid": "0",
  "scy": "auto",
  "net": "ws",
  "type": "none",
  "host": "edge.example",
  "path": "/demo",
  "tls": "tls",
  "sni": "edge.example"
}

Do not treat add, host, and sni as interchangeable server addresses. The first specifies the connection destination; in this WebSocket example, host is used for the request Host header, while sni is used for TLS name negotiation. In a real service, all three may be the same or different. If an imported entry keeps only the address and UUID but loses the transport path or TLS settings, it may save successfully yet still fail to connect.

vless:// and trojan://: Similar formats, different authentication fields

Common VLESS and Trojan share links both resemble standard URIs: credentials come before @, the server and port follow it, extension parameters come after the question mark, and a remark follows the hash. Similar formats do not mean you can convert between protocols by changing only the prefix.

vless://[email protected]:443?encryption=none&security=tls&type=ws&host=edge.example&path=%2Fdemo&sni=edge.example#Office

trojan://[email protected]:443?security=tls&type=tcp&sni=edge.example#Office

In the example, %2Fdemo decodes to /demo. Percent-encoding prevents reserved characters from changing the URI structure. For example, an unescaped # in a password may be interpreted as the start of a remark. Keep the original encoding when copying; importers typically handle each field. Repeatedly decoding and pasting the link by hand can break its separators.

Port 443 is just one possible server listening port. You cannot infer the protocol from the port number, and not every TLS connection should use 443. If certificate verification fails, first check the device date and time, SNI, and source parameters. Disabling certificate verification is not a routine fix.

Single-node links and subscriptions: check import options and update behavior separately

Importing a single-node link usually creates a local copy of its connection settings. If the server later changes the password, address, or transport parameters, the old entry will not update automatically just because it has the same name. A subscription saves a source that can be requested again to retrieve the list, but it cannot guarantee every request will succeed or replace checks on service validity and account status.

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

This is an obviously fictional URL, shown only to illustrate the “address + query credential” structure.

1. Import a single-node link: Copy the complete link from a trusted source, return to Home, and use the app's clipboard import option. If prompted to access the clipboard, allow it only when you need to import. If the option does not appear, open the add menu in the upper-right corner of Home and create an entry using the settings you already have.
2. Import a subscription: Go to Home → tap + in the upper-right corner, select Subscribe under Type, enter your subscription URL in URL, add a remark, and save. Do not enter an account sign-in page as the URL.
3. Check the result: Confirm that the subscription group, node types, and number of entries match your existing service details. Open an entry to check its address, port, and transport settings rather than relying on its remark alone.
4. Update later: Update a subscription from its actions on Home. For automatic updates, check the settings under Settings → Subscribe. Updating when the app opens does not mean the system fetches subscriptions continuously on a schedule, and a single-node entry does not become a subscription.

Keep the source link before changing a local entry

Subscription updates may replace subscription-managed node settings or change the list order and names. Before editing a subscription node locally, note why you made the change and keep the original settings. Manage important custom entries separately so an update is not mistaken for lost manual configuration.

HTTPS indicates that the connection uses the corresponding transport protection; it does not guarantee that the response is a node list. If an update returns a sign-in page, error page, or incompatible text, check the original subscription URL, its validity, and the response. A subscription token is an access credential; do not share the full URL in public chats or screenshots while troubleshooting.

After importing: verify the node, then check Global Routing and Config

“The link parses,” “the entry saves,” “a connection is established,” and “the target request follows the intended policy” are four different outcomes. A node share link provides connection settings; successful import does not automatically create a Config suited to your needs. Use Home to manage connection entries and status, Config to manage rule sets, and Settings to adjust app behavior.

Global Routing also includes Scene, which applies strategies based on configured scene conditions; it is not a fixed Proxy or Config. Settings → On Demand controls on-demand connection behavior, not a node protocol or subscription update switch. During troubleshooting, keep the connection trigger and test target consistent so that network changes and automatic triggers do not alter the test conditions at the same time.

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
FINAL,DIRECT

These are examples of rule syntax, not a complete configuration. DOMAIN-SUFFIX matches domain suffixes, IP-CIDR matches IP ranges, GEOIP classifies by IP geolocation database, and FINAL handles requests not matched by earlier rules. Rule order affects the result. Even with correct node settings, a request that matches DIRECT will not use the proxy route. Checking the matched rule and final policy in request logs is more useful than repeatedly importing the same link.

FAQ: troubleshoot parsing, authentication, transport, and updates separately

Use this final checklist: identify the link type → keep the complete original text → choose the matching import option → verify authentication and transport fields → test the connection → check rules and update behavior. The four schemes covered here are not a complete list of Shadowrocket's supported capabilities, and do not establish that other protocols use the same URI fields. Verify the supplied settings and actual support separately.