Shadowrocket supports a range of proxy and tunneling protocols. This guide is for users who already have service details and need to verify connection settings. Compare protocols in the table, check authentication, transport and TLS fields, then use Global Routing to rule out routing issues. You’ll learn which fields to fill in and where to look when a connection fails. A protocol name alone doesn’t tell you how fast a connection will be.
Protocol overview: identify the Type, then check the settings
Shadowrocket supports protocols including Shadowsocks, VMess, VLESS, Trojan, HTTP, SOCKS5, WireGuard and Hysteria2. To add a server, go to Home → tap “+” in the top-right corner → Type. Your selection determines which fields appear. The protocol must match the connection details from your service provider; changing the Type name alone does not convert a connection.
| Protocol | Key characteristics | Settings to check first |
|---|---|---|
| Shadowsocks | Uses an agreed encryption method and password for authentication, with relatively few settings. | Server address, port, encryption method, password, and any required plugin. |
| VMess | Uses a UUID to identify the user; authentication and transport settings must also match. | UUID, encryption settings, AlterId (if included in the details), transport type and TLS. |
| VLESS | The protocol itself does not encrypt payloads; check which security layer is used in the actual setup. | UUID, transport type, TLS or REALITY settings, and Flow (if applicable). |
| Trojan | Typically uses password authentication over a TLS connection. | Password, port, TLS server name and certificate verification. |
| HTTP / SOCKS5 | A general-purpose proxy type; authentication and encryption depend on the specific setup. | Proxy address, port, username, password, and whether TLS is enabled. |
| WireGuard | An encrypted tunnel over UDP that uses keys and peer settings. | Local private key, peer public key, Endpoint, tunnel addresses and routing ranges. |
| Hysteria2 | Built on QUIC, which relies on UDP, and can carry proxy traffic. | Server address, port, authentication, TLS server name and any obfuscation settings. |
Use this table to identify settings, not to rank performance. Available fields depend on your installed version of Shadowrocket, and the app must support any extended features provided by your service provider. Keep the original connection details and check each field; don’t assume compatibility based on similar names.
Shadowsocks, VMess and VLESS: check authentication and transport separately
Shadowsocks: the encryption method and password must match
The Shadowsocks server address and port identify the entry point. The encryption method and password must also match for the connection to work. For example, if the server specifies aes-128-gcm, don’t switch the client to chacha20-ietf-poly1305. If a connection uses a plugin or other extended settings, don’t treat it as a standard configuration by keeping only the address and password.
- Preserve the password’s exact capitalization and symbols. When copying it, check for leading or trailing spaces and line breaks.
- Don’t mix older and newer encryption methods. Some methods also require a specific key format.
- If an imported subscription works but a manually entered connection doesn’t, compare the encryption method and extended settings first—not the routing rules.
VMess: a valid UUID doesn’t mean the configuration is complete
A VMess UUID identifies the user; it is not a server domain or subscription token. Check the transport type, TLS and any other settings specified by your service provider in addition to the UUID. If the connection details include AlterId, use the value provided rather than copying one from another configuration. An incorrect device clock can also affect authentication, so first make sure the system date and time are correct.
VLESS: don’t mistake the UUID for an encryption setting
VLESS also uses a UUID for authentication, but the protocol itself does not encrypt payloads. Your service provider may combine it with TLS or REALITY. If the details include Flow, Public Key or Short ID, enter every value required for that combination. REALITY cannot be replaced by simply enabling standard TLS, and a public key should not go in the password field.
WebSocket is a transport method; common settings include Host and Path. For example, if the connection details specify the Path as /connect, changing it to / can cause the handshake to fail. Host, the server address and the TLS server name may all differ, so check each one against the provided details.
Trojan, HTTP and SOCKS5: distinguish TLS from proxy authentication
Trojan typically protects the connection with TLS and then authenticates with a password. A certificate error doesn’t necessarily mean the password is wrong: the connection may use an IP address while the certificate is issued to a domain. Check the TLS server name (SNI). Don’t disable certificate verification just to clear an error; first check the domain, device clock and server certificate status.
| Setting | What it means | Common mix-up |
|---|---|---|
| Server address | The domain or IP address the client connects to. | It may not be the domain name on the TLS certificate. |
| Port | The port the server listens on; the connection details might specify 443, for example. | 443 is a common example, not a port used by every protocol. |
| SNI | The server name sent during the TLS handshake. | Don’t enter a full URL; omit https:// and any path. |
| Username and password | Proxy credentials that an HTTP or SOCKS5 service may require. | These aren’t your subscription website login details unless your service provider says otherwise. |
HTTP proxies often use CONNECT to forward HTTPS requests to their destination. But an HTTPS destination and TLS between the client and proxy entry point are two different things. SOCKS5 also does not encrypt the connection; username and password authentication is not a substitute for encryption. If confidentiality matters, check the entire connection path—not just whether the proxy has a password.
- HTTP and SOCKS5 ports may be 8080, 1080 or another value. These are common examples, not defaults to fill in automatically.
- Don’t assume an HTTP proxy can forward arbitrary UDP traffic.
- SOCKS5 UDP support also depends on the server and network conditions. Working TCP web traffic doesn’t guarantee that UDP will work.
WireGuard and Hysteria2: verify UDP separately
WireGuard is an encrypted tunneling protocol, not a proxy configuration that just needs an “address and password.” It uses a local private key and a peer’s public key. Endpoint points to the remote entry point, while the tunnel address is used inside the tunnel. Reversing the keys, leaving out an address or using an unsuitable routing range can leave a saved configuration unable to reach its destination.
- Use the Private Key assigned to this client, and verify that Public Key is the remote peer’s public key.
- Use the Endpoint port specified by your service provider. 51820 is a common example, not a requirement.
- Allowed IPs defines the destination address ranges the peer can handle; don’t replace it with an arbitrary server IP.
- MTU controls packet size inside the tunnel. Change it only when there’s a clear symptom and a reason to do so, and keep the original value so you can restore it.
Hysteria2 uses QUIC and typically relies on UDP to connect. A network that allows TCP 443 may still block UDP 443, even though the port number is the same. Authentication, the TLS server name and any optional obfuscation settings must match the server. Bandwidth settings can’t change the physical network or increase the capacity the server can actually provide.
In short: test UDP before changing settings
If TCP-based connections work on the same network but WireGuard or Hysteria2 keeps timing out, try another network you’re permitted to use and ask your service provider to confirm the UDP port. Don’t start by changing the password, disabling certificate verification or arbitrarily increasing bandwidth values.
Import and verify: keep the complete settings from your service provider
If you already have a subscription, keep its settings together and check that all required protocol details were imported. A subscription URL, a single-server share link and a configuration file link serve different purposes; a URL beginning with https:// alone doesn’t tell you which one it is. Get subscription details directly from your service provider.
-
Identify the connection details
First confirm whether you have a subscription, details for a single server or a configuration file. This subscription URL example,
https://example.com/sub?token=xxxx, shows the format only; it is not a working service. Don’t share a real token publicly. -
Import a subscription
Go to Home → tap “+” in the top-right corner → Type → Subscribe, enter your subscription URL and save. Return to Home to check the import. To update it, pull down on Home and confirm that the list changes as expected.
-
Check settings manually
To add a server manually, go to Home → tap “+” in the top-right corner → Type, choose the matching protocol, then enter the address, port and authentication details provided. If transport or TLS options appear, check those too; filling in only the main fields may not be enough.
-
Retest the connection
On Home, select the server you just checked, connect, then test the destination. To rule out automatic connections, note your current Settings → On Demand settings first. Pause on-demand connections while troubleshooting, then restore the original settings afterward.
Updating a subscription may overwrite settings managed by that subscription. Before testing changes, record the original values and what you changed. Don’t change the protocol, DNS, rules and transport settings all in one test. Change one thing at a time so you can tell what caused the result.
Global Routing: protocol connections and rule-based routing are separate layers
Home is where you select a server and connect; Config is for managing configuration files; Settings contains app settings. Global Routing determines how traffic is routed. It doesn’t convert Shadowsocks to Trojan or replace protocol authentication. Check it first when troubleshooting so traffic that isn’t using the selected server isn’t mistaken for a protocol failure.
Config
RecommendedRouting follows the policies in the current configuration. Traffic may use a proxy, connect directly or be rejected. Check where the configuration comes from and what policy FINAL uses; don’t assume traffic that matches no rule will always connect directly.
Best for: everyday use when you’ve checked the rules and need to route traffic by destination.
Proxy
Routes traffic handled by Shadowrocket through a proxy. Useful for temporarily ruling out rule matching as the cause. It won’t fix an incorrect password, an unreachable port or a failed TLS handshake.
Best for: checking whether the current server can reach the same test destination.
Direct
Routes traffic directly. This doesn’t test whether the selected proxy server works. If a webpage loads after switching, that only confirms the direct connection works.
Best for: comparing access over your local network with access through the proxy.
In Global Routing, Scene applies routing behavior based on the selected scene. Check the conditions for that scene as well. If you’re checking a single connection’s settings, note the original routing mode and retest with a fixed mode to avoid changes triggered by switching networks.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYThis example shows rule syntax in Config mode; it isn’t a recommendation to replace your current configuration. DOMAIN-SUFFIX matches domain suffixes, IP-CIDR matches address ranges, GEOIP relies on IP geolocation data, and FINAL handles traffic that hasn’t matched any earlier rule. Rules are evaluated in order. 192.0.2.0/24 is a documentation example range, not an address for a real service.
Troubleshooting: identify the next step from what you observe
Why does the connection time out after a successful import?
A successful import only means the details were parsed; it doesn’t mean the server is reachable. On Home, open the server’s edit screen and check its address, port and Type, then check your current network. For Hysteria2 and WireGuard, verify UDP reachability separately. A successful subscription update is not a substitute for testing the connection.
Why won’t webpages load even though a latency value appears?
A latency test may not cover the full connection path, including authentication, TLS, DNS and access to the destination. Note the current Global Routing setting, temporarily switch to Proxy and test the same destination. If only Config fails, check the active configuration and the rule matching that destination. Restore the original routing mode after testing.
Can I change VLESS directly to VMess?
Not by changing the Type alone. The server protocols and authentication handling differ, so even identical-looking UUIDs don’t make them compatible. Ask your service provider for complete details for the other protocol, then create a new entry via Home → tap “+” in the top-right corner. Keep the original entry for comparison.
Which protocol is guaranteed to be the fastest?
You can’t determine that from a protocol name alone. Keep the network, destination and test time consistent, and record whether the connection succeeds, how pages load and how sustained transfers perform. Compare only connections you already have with correct settings. If UDP is restricted, a failed Hysteria2 test doesn’t predict how other protocols will perform.
For help with individual fields, see Configuration Fields. To look up terminology, visit the Glossary. When reporting an issue, include the error message, protocol type and steps to reproduce it, but hide passwords, UUIDs, subscription tokens and private keys. Don’t post complete connection details publicly.