Shadowrocket Supported Protocols: Shadowsocks, VMess, VLESS, Trojan & WireGuard

At a glance

Shadowrocket supports multiple connection protocols, but the type you add must match the details of your existing service—not an arbitrary Type selection. This guide compares protocols, transports and authentication details, then covers what to check after importing, how Global Routing works, and how to troubleshoot connection failures in order. It’s for users identifying the type of an existing configuration.

Protocol overview: Match Type to the server

Shadowsocks, VMess, VLESS, Trojan, HTTP, SOCKS5, WireGuard and Hysteria2 are distinct connection types, not speed settings for the same connection. Shadowrocket must use a configuration that matches the protocol running on the server. Changing only the Type does not convert an existing service to another protocol. Matching addresses, ports and authentication details do not mean two protocols are compatible.

Protocol	Key features	Details to check first
Shadowsocks	Uses a specified encryption method and shared password; TCP and UDP support depends on both ends’ configuration.	Server address, port, encryption method, password and any required plugin.
VMess	Uses authentication details such as a UUID and can work with different transport methods and TLS.	UUID, transport method, TLS status, Host, path and other related settings.
VLESS	Uses UUID authentication; the protocol itself does not encrypt payloads. Protection depends on the outer transport configuration.	UUID, transport method, TLS or other specified security settings—not just the address.
Trojan	Commonly deployed over TLS and authenticated with a password.	Password, port, TLS server name and certificate match.
HTTP / SOCKS5	General-purpose proxy types; authentication, UDP support and connection protection vary.	Type, address, port, username and password; for HTTP, also check whether TLS is required.
WireGuard	Encrypted tunnel over UDP; identifies the peer using key pairs.	Local private key, peer public key, tunnel address, endpoint and routing settings.
Hysteria2	Built on QUIC over UDP, with TLS and authentication-related settings.	Server UDP port, authentication details, server name and optional obfuscation settings.

Bottom line: Choose Type based on the original settings

First check the protocol name provided by your existing service. Then select the matching option under Home → “+” → Type. For related protocols or optional transport settings, check each parameter carefully—don’t substitute based on similar names.

Protocol, transport and TLS: Check each layer separately

Connection details often include names such as VLESS, WebSocket and TLS, but they describe different layers. The protocol defines how the two ends structure requests and authenticate; the transport determines how that data is carried; TLS concerns transport encryption and server identity verification. Treating all three as one “protocol name” is a common source of errors when editing an imported configuration.

Layer 1: Connection protocol: For example, VMess and VLESS. Even though both can use a UUID, their Types are not interchangeable. A Shadowsocks password also cannot be used as valid Trojan credentials.
Layer 2: Transport method: For example, TCP and WebSocket. If your details specify WebSocket, also check the path and Host. Switching to plain TCP does not bypass the server’s transport requirements.
Layer 3: Security settings: The TLS server name is used for identity verification and may also affect server access. The connection address, HTTP Host and TLS server name can differ; retain each value from the original configuration.

A port number identifies the service entry point; it does not identify the protocol. For example, 443 can be used by a TCP service or a QUIC service over UDP. 51820 is common for WireGuard, but it is not required. Don’t assume 443 means Trojan, or change every WireGuard port to 51820.

Adding servers and importing subscriptions: Check each setting after saving

The steps below assume you already have a service provider and subscription, and are authorized to use the connection details. A subscription distributes and updates configurations; it is not a connection protocol. It’s normal for an import to include multiple Types. This site does not provide, sell or recommend proxy servers or subscription services.

Review the original details

Note the protocol name, server address, port and authentication method first. Manual setup also requires the complete transport and TLS settings; a server address alone is not enough to recreate a connection.
Choose an add method

To add a server manually, go to Home → “+” → Type and choose the protocol specified in your details. If you already have a subscription, select Subscribe under Type, enter your own subscription URL and save. The example https://example.com/sub?token=xxxx shows URL formatting only; it cannot be used to connect.
Check the connection details

Return to Home, open the edit screen for the relevant item in the SERVER list, and check its Type, address and port. Then review the password or UUID, TLS and transport path. For WireGuard, check the complete configuration, including keys and tunnel settings; don’t treat it like a password-based form.
Check the routing mode

Go to Home → Global Routing to review the current selection. To route by rules, select Config and confirm the active configuration under Config. Adding a server successfully does not mean every request will use that connection.
Connect and verify

Return to Home, select the item you want and turn on the connection switch. The first time, follow the system prompt to allow adding a VPN configuration. Run Connectivity Test, then visit a destination you control to check both the connection status and the actual request result.

After updating a subscription, review the item details again to see whether the address, port or Type changed. A successful update means the subscription content was retrieved and processed; it does not prove that every connection works. Likewise, a temporarily unreachable subscription URL does not mean saved connection settings have immediately stopped working. Track “configuration retrieval” separately from “connecting with the configuration” when troubleshooting.

Comparing Global Routing modes: The protocol does not determine where requests go

The same Trojan or WireGuard connection may handle different requests depending on the Global Routing mode. This comparison is about Shadowrocket’s routing settings, not protocol performance. The “recommended” Config option below applies when you’re routing by rules and have prepared and checked those rules. When troubleshooting, choose a mode based on what you’re testing rather than always using the same one.

Config

Recommended

Routing decisions follow the rules in the current configuration. Requests matching DIRECT connect directly; only requests matching a proxy policy are sent through the corresponding connection. The FINAL policy is also determined by the configuration.

Best for: Using existing rules to distinguish direct requests from proxied ones.

Proxy

Handles requests within its scope using a proxy mode. Use it for a temporary comparison to see whether Config rule matching affects access. Don’t assume this means all system traffic will always go through the proxy.

Best for: Temporarily checking the difference between rule-based routing and the connection itself when you already have a working connection.

Direct

Handles requests in a direct mode. Even if a server is selected on Home, that alone doesn’t mean requests are using it.

Best for: Comparing direct access to confirm whether an issue occurs only on the proxy route.

Scene in Global Routing applies routing behavior according to configured scene conditions; it is not an additional connection protocol. Settings → On Demand manages on-demand connection settings and does not change a server’s Type. Whether a VPN connection starts automatically, which rule a request matches, and which protocol carries it are three separate questions to check.

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

These rule snippets illustrate evaluation order; they are not a complete connection configuration. The first rule matches api.example.com with PROXY; the following DOMAIN-SUFFIX rule then covers example.com and its subdomains. 192.0.2.0/24 is a documentation-only IP-CIDR range, and no-resolve means the rule will not actively resolve domain names. GEOIP matches based on IP geolocation data, while FINAL handles requests that did not match earlier rules. Here, PROXY is a policy name, not a protocol.

Troubleshooting connection failures: Identify the failing layer first

A latency value, a connected VPN status and an accessible destination website are different results. Interpret Connectivity Test results in light of how the test works; they do not prove that a destination service is available. The checks below follow observable symptoms and are troubleshooting steps, not test results invented by this site.

Observed symptom	Check first	Next step
An authentication error appears immediately after saving	Check whether the Type, password, UUID or key matches the original details.	Open the item’s edit screen and compare each field; check for spaces or truncated text when copying.
A TLS or certificate error appears	Check the server name, certificate validity, device time and transport settings.	Keep verification enabled, correct the settings and reconnect.
Hysteria2 or WireGuard keeps timing out	Check whether the destination UDP port is correct and whether the current network allows the required UDP traffic.	Keep the configuration and compare it on another network you’re authorized to use. Don’t switch it to TCP without a reason.
Some domains fail while other requests work	Check Global Routing, the active Config, rule order and domain resolution results.	Compare the same destination in Proxy and Config modes, then check which specific rule it matches.
An item stops working after a subscription update	Check whether the updated address, port, authentication details or Type changed.	Compare with the latest details from your existing service and distinguish subscription retrieval errors from connection errors.

Bottom line: Change one setting at a time

Keep the destination and configuration fixed. Compare networks first, then routing modes, and finally protocol settings. Don’t change the Type, port and TLS settings at the same time, or you won’t know which change affected the result.

FAQ: A supported protocol does not mean every configuration will work

I have Shadowsocks. Will switching to VLESS make it faster?

Not by changing the Type alone. Each protocol requires a matching server and authentication details. Keep the original configuration, run Connectivity Test from Home and visit the same destination. Only add and compare a second configuration if your existing service explicitly provides a complete alternative. A protocol name alone does not guarantee speed.

HTTP and SOCKS5 are both proxies. Can I switch between them?

No. Open the item’s edit screen on Home and check the Type, port and authentication details against your existing configuration. A standard HTTP proxy connection and SOCKS5 are not automatically encrypted just because both are proxies. HTTPS to a destination through HTTP CONNECT also does not mean the connection from the client to the proxy server uses TLS.

Hysteria2 times out on my current network. Should I change the port?

First check the UDP port and authentication details in the original configuration, then test the same settings on another available network. The port must be actively listening on the server; you can’t choose one arbitrarily in the client. Hysteria2 is based on QUIC, so changing the number to 443 does not turn it into a standard TCP connection.

The subscription lists a protocol. Why was the import still incomplete?

Support for a protocol family does not guarantee that every sharing format, extension parameter or combination can be parsed. After importing, open the item’s edit screen and check TLS, the transport path and authentication fields. If a required field is missing, check with your existing service for complete details that match the options available in the app instead of guessing.

Does WireGuard only need a public key?

No. Check the local private key, peer public key, endpoint address and port, tunnel address, and related routing settings. The server also needs the corresponding client configuration. Keep private keys and authentication tokens from subscriptions confidential; don’t post the complete values publicly when troubleshooting.