Shadowrocket Share Links Explained: ss://, vmess://, vless://, trojan:// and Subscription URLs

At a glance

This guide is for iPhone and iPad users who already have their own service details but aren’t sure which type of link to import. First, distinguish share links, subscription URLs, and rule configurations. Then identify the authentication and transport fields in four common prefixes, and check the import and refresh behavior in Home. All examples use demonstration data that cannot be used to connect. This site does not provide, sell, or recommend servers or subscriptions.

1. Distinguish share links, subscription URLs, and rule configurations

Server settings, subscription sources, and routing rules are separate layers in Shadowrocket. A share link carries connection details for one server; a subscription URL points to remote content that can be requested again; and a rule configuration determines how requests are routed. Even when each appears as text or a URL, they are not interchangeable.

Content type	What it usually contains	What to check after import
Single-server share link	Protocol, server address, port, authentication details, and optional transport parameters	The corresponding server’s details in Home
Server subscription URL	A remote URL and access credentials; the response contains a server list	The subscription source and its entries in Home
Rule configuration	Routing rules, policies, and other configuration data, depending on the file	The selected configuration and rules in Config

An https:// URL is not automatically a server subscription. It could point to a login page, help page, or rule configuration. Check the purpose described by your existing service and the response content—not how long the URL looks. A server-list subscription does not necessarily configure DNS or routing rules. After importing, check the current Global Routing setting.

2. ss:// and vmess://: Base64 doesn’t encode the same kind of data

ss://: Find the encryption method and password, then the address and port

ss:// identifies a Shadowsocks share link. A common SIP002 format puts “encryption method:password” in Base64-encoded userinfo, with the server address and port outside it. Older formats may encode the entire connection string instead. Don’t assume every ss:// link can be split at the same point.

Decoded userinfo example:
aes-256-gcm:demo-password

Example server details:
Server: example.com
Port: 8388
Method: aes-256-gcm
Password: demo-password

Here, 8388 is only a sample port, not a required Shadowsocks port. The actual port must match your existing service. A link may also include a plugin query parameter and a note after #. The note helps identify the entry but does not replace the address. If the service requires extra plugin parameters, the address, password, and port alone may not be enough to connect.

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

A common vmess:// share format encodes a JSON object after the prefix. The example below shows how decoded data might look; it is not a complete link you can paste into an import field. Share formats can vary, so check the fields shown after import.

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

add and port are the server address and port; id is the UUID used for authentication.
When net is ws, the transport is WebSocket. path and host are parameters for that transport.
tls and sni affect the TLS connection. A port of 443 does not mean the TLS settings are complete.
v is a format field in this type of share-link JSON, not the Shadowrocket version number; ps is usually a display name.

What decoding tells you—and what it doesn’t

Base64 is an encoding, not a way to protect credentials. Inspect the structure locally; don’t submit a full share link to an online decoder. After importing, check the protocol, port, and transport settings before testing the connection.

3. vless:// and trojan://: URI fields you can’t leave out

vless:// and trojan:// commonly use a more readable URI structure: authentication details come after the prefix, the server address and port follow @, query parameters follow ?, and a note follows #. Readable doesn’t mean safe to share—the authentication details should still be treated like a password.

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

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

Field or position	Meaning	What to check
Before `@`	The VLESS example uses a UUID; the Trojan example uses a password	Don’t interchange the two types of credentials
`example.com:443`	Server address and port	Use the port specified by your existing service
`security=tls`	TLS settings in the share format	Check the imported TLS settings and certificate name
`sni`	Server name used in the TLS handshake	Match the name provided by the service; don’t replace it with the address
`type=ws`、`host`、`path`	WebSocket transport and request parameters	Preserve the exact path, capitalization, slashes, and Host
`#Demo-VLESS`	Display name	Changing the display name won’t fix authentication or transport errors

In a VLESS example, encryption=none describes a protocol parameter; it doesn’t mean the entire connection has no TLS. Check security and the imported settings to see whether TLS is enabled. Similarly, 443 confirms only the port number, not that certificate validation, SNI, or the WebSocket path is correct.

Special characters in a URL may need percent-encoding. In this example, %2Fdemo decodes to /demo. When handling a link manually, don’t decode it repeatedly and then rebuild it. Don’t treat an @ or # that belongs to a password as a structural delimiter. IPv6 addresses in the URI host usually need square brackets to distinguish their colons from the port separator.

4. Subscription URLs: Keep the remote source; refresh the list

A server subscription is usually an HTTPS URL, like the obviously fictional example below. During import, Shadowrocket requests the URL and parses the response to create selectable server entries. The response may contain multiple share links as text or may be encoded as a whole. You can’t tell whether it uses Shadowsocks, VMess, VLESS, or Trojan just by looking at the subscription URL.

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

Choose the import option that matches the information you have

You have a single share link

Copy the complete ss://, vmess://, vless://, or trojan:// link.
Use the add option in Home to import it, or scan a QR code containing the link.
Open the new entry and check its Type, address, port, and authentication fields.
If the parameters change, import the link again or update the corresponding entry manually.

You have a server subscription URL

In Home → +, open the add screen and set Type to Subscribe.
Enter the full URL, including its path, query parameters, and token.
Save and fetch the list, then check that the expected servers appear under the source.
To sync remote changes, update the subscription instead of adding the same source again.

Scanning a QR code and using the clipboard are just ways to enter data. Whether the code contains a single share link or a subscription URL determines how the imported item is managed.

Updating a subscription fetches its remote source again, so the number of entries, names, addresses, and credentials may change. A successful update doesn’t mean the currently selected server can connect or that routing rules are correct. Before updating, note which entry you’re using. Don’t assume local edits to subscription entries will remain; the next update may recreate those fields.

A response from a login page isn’t a valid server list, even if the HTTP request succeeds.
If the source revokes a token, repeatedly pasting the old URL won’t restore access. Check the valid URL for your existing service.
If the link contains &, make sure you copied the actual URL, not the entity text used to represent that character in page source.
A full subscription URL often acts as an access credential. When sharing a screenshot, hide the path and query parameters as well as the domain.

5. What to check in Home, Config, and Settings after importing

Use Home to view and select servers; it’s the starting point for checking an import. Config manages rule configurations, while Settings contains app settings. A share link containing type=ws is not a routing rule in Config. Transport settings determine how to connect to a server; rules determine which policy handles each request. These are separate layers.

In Home, open the new entry’s edit screen. Confirm that Type matches the original prefix, then check the server address, port, authentication details, TLS, and transport settings.
If you imported a subscription, confirm the entry belongs to the expected source and isn’t a standalone entry with the same name.
Check Global Routing. For everyday rule-based routing, make sure Config is selected and that the expected configuration is chosen on the Config screen.
Select a server you’re authorized to use, turn on the connection, authorize the system VPN configuration, and then test an actual request.
To check automatic reconnection behavior, open Settings → On Demand. This isn’t a subscription refresh switch, and it won’t fill in missing server parameters.

Config: Route traffic using the current configuration

Recommended

Use this when a valid rule configuration is already in place. Requests are matched against the current configuration; it’s not safe to assume that unmatched requests will always connect directly. Their handling depends on the configuration’s fallback policy.

Best for: Everyday routing by domain or IP after checking the rules

Proxy: Temporarily rule out routing rules

Send proxy-eligible requests through the currently selected proxy to compare the result with Config. This won’t fix server passwords, TLS, or transport settings, and it’s not a substitute for a complete connectivity test.

Best for: Checking whether routing rules are the issue while using the same server

Direct: Test a direct connection for comparison

Handle requests using a direct connection. A webpage loading in this mode doesn’t prove the newly imported server works—the request may not have used it at all.

Best for: Briefly checking basic local network connectivity as part of troubleshooting

In a rule configuration, DOMAIN-SUFFIX matches domain suffixes, GEOIP and IP-CIDR match their respective IP conditions, and FINAL handles requests that don’t match earlier rules. These aren’t query parameters for the four share-link formats, and importing a server won’t generate them for your needs. For more on rule configurations, see the Getting Started guide or the Troubleshooting manual.

6. Common questions about importing and updating

I copied a link, but no server appeared. Is the protocol wrong?

First, make sure the copied text starts with the protocol prefix, contains no extra instructions such as “tap to import,” and hasn’t been split by a messaging app. In Home → +, check the add type: import a single share link as a server, or choose Subscribe for an HTTPS subscription. If it still isn’t recognized, check the complete original link. Don’t replace the prefix yourself.

The QR code scanned successfully. Why can’t I connect?

A successful scan only means the QR code’s text could be read. Open the entry in Home and check that the port is complete, then verify the UUID or password, SNI, WebSocket path, and other fields. The QR code may be expired or may contain only a webpage URL. A successful scan doesn’t confirm that a server is usable.

Latency is shown, but webpages still won’t load. What should I do?

A latency result doesn’t verify authentication, DNS, TLS, or the full connection to the destination website. First, confirm that you selected the server you just checked. Then temporarily compare Global Routing → Proxy with Config. If only Config fails, check which rule matches. If both fail, check authentication, TLS, and transport settings instead of just changing the display name.

A subscription update created entries with duplicate names. Which one should I delete?

In Home, distinguish standalone entries from entries under a subscription source, then compare their addresses, ports, and protocols. The same name doesn’t mean the connection details are the same. Remove an old standalone entry only after confirming you no longer need it. If the same subscription was added twice, keep the verified source to avoid maintaining two separate lists.

The subscription URL times out. Can I change its port to 443?

Don’t replace the existing parameters with a guessed port. The access port for an HTTPS subscription URL is separate from the connection port of servers in its list. Check whether your current network can reach the source, whether the URL is complete, and whether the token is valid. A webpage response that returns a login page doesn’t mean the subscription updated successfully.

7. Final checks: valid structure, source, and actual requests

After importing, verify three things separately: the text was recognized, the server parameters are correct, and requests actually follow the expected route. None of these confirms the others. A successful import creates a local entry; a successful refresh retrieves remote content. Actual access still depends on server status, your current network, DNS, and routing settings.

Link type: Confirm whether it’s a single-server share link, a refreshable subscription, or a rule configuration URL.
Authentication and transport: Check the protocol, address, port, password or UUID, and any required TLS, SNI, Host, and path settings.
Source and updates: Confirm the subscription source is valid and that a standalone entry hasn’t been mistaken for one that updates automatically.
Routing and testing: Check that Global Routing matches the current configuration, then test with an actual webpage request—don’t rely on latency alone.
Protect credentials: Don’t share full share links, QR codes, or subscription URLs containing a token. If credentials are exposed, address them through your existing service.

Next: Change one layer at a time

Keep the original link and check the imported fields first. Once the fields are correct, test the connection; adjust rules only after the connection is confirmed. Don’t change the port, TLS, and Global Routing all at once, or you won’t know which change fixed access.