Shadowrocket supports protocols including Shadowsocks, VMess, VLESS, Trojan, WireGuard, and Hysteria2. This guide is for users who already have their own server details or subscription and need to match the Type to the right fields. Use the comparison table to identify each protocol, then check the settings in Home → “+” → Add Server. Finally, distinguish the protocol from the transport and Global Routing. This guide does not provide server resources, and these six protocols are not a complete list of all available types.
At a glance: What to check for each of the six protocols
Choose the protocol that matches your existing server configuration rather than guessing which type is “faster.” Go to Home → “+” to open Add Server, then check the available types under Type. The protocol names below are for identification; available fields and options depend on the current interface.
| Protocol | Key features | Settings to check first |
|---|---|---|
| Shadowsocks | Uses a shared secret and a specified encryption method to establish a proxy connection. | Address, Port, Method, and Password; any additional obfuscation settings must also match. |
| VMess | Uses a user identifier for authentication; transport settings must match the server. | Address, Port, UUID, encryption settings, TLS, and transport. |
| VLESS | Uses UUID for authentication; the protocol itself does not encrypt content. | UUID, transport, and the corresponding security settings. A UUID alone does not make a complete configuration. |
| Trojan | Uses Password for authentication and typically protects the connection with TLS. | Password, Port, TLS, and the server name matching the certificate. |
| WireGuard | Uses a key pair to establish an encrypted tunnel over UDP. | Client Private Key, peer Public Key, Endpoint, tunnel addresses, and routing scope. |
| Hysteria2 | Based on QUIC, runs over UDP, and uses TLS and authentication parameters. | Address, UDP port, authentication details, server name, and any additional parameters required by the server. |
Bottom line: Match the server configuration first, then compare connection performance
Check Type, Address, Port, and authentication details one by one. Comparing latency or page loading only makes sense once these settings match. Don’t switch the same address to a different Type at random to try to speed it up.
Shadowsocks, VMess, and VLESS: Authentication settings are not interchangeable
The main differences between these protocols are their authentication methods, security settings, and transport combinations—not their names. After choosing a Type in Add Server, enter the fields from your original configuration. Keeping the same address or port after switching Type does not mean the other settings will still work.
- Shadowsocks: Method and Password must both match. Even with the correct Address and Port, a mismatched Method can make the server reachable while requests fail. Don’t assume two options are equivalent just because the password looks the same.
- VMess: UUID is a user identifier, not a subscription URL or a regular login password. If the transport uses WebSocket, check the corresponding Host and Path as well. TLS must also be enabled or disabled to match the server. If authentication fails, make sure the device’s date and time are correct.
- VLESS: A correct UUID does not guarantee that the security settings are correct. VLESS does not encrypt content by itself; protection depends on the security layer used with it. Check which security options are available in the current interface and what the server requires. Don’t copy VMess encryption settings without verifying them.
WebSocket is not an authentication protocol on the same level as VMess or VLESS, and TLS is not a new server account. In the server editor, treat the protocol Type, the transport carrying the connection, and the TLS security layer as three separate components. Whether a particular combination works depends on what both the app and server support.
Trojan, WireGuard, and Hysteria2: Security settings and network requirements
These protocols require particular care with certificates, keys, and underlying network conditions. After choosing a protocol in Add Server, configure its authentication first, then review TLS or tunnel settings. Connection problems are not always caused by an incorrect password.
Trojan: Match both the Password and TLS server name
Trojan commonly uses TLS, but using port 443 alone does not make a configuration valid. If the Address is an IP but the certificate was issued for a domain, enter the server name used for TLS verification as specified in your configuration. Don’t address certificate errors by simply disabling certificate verification. Address, TLS server name, and WebSocket Host serve different purposes; don’t enter the same domain in every field just because it appears in the configuration.
WireGuard: Enter the client private key and peer public key separately
WireGuard uses a key pair, not a UUID or Password. Keep the client Private Key confidential, and make sure the peer Public Key belongs to the actual server. Endpoint specifies the peer’s address and UDP port. Tunnel addresses, Allowed IPs, and MTU can also affect reachability. Check them against your existing configuration rather than applying arbitrary defaults.
Hysteria2: Confirm that the UDP path is reachable
Hysteria2 is based on QUIC and requires the network to allow the relevant UDP traffic. A response on a TCP port does not prove that the UDP path on the same port is working. If the server requires additional obfuscation or specific authentication, enter the matching settings in the client. Hysteria and Hysteria2 are not interchangeable just because their names are similar.
- Fails on only one network: Keep the server settings unchanged and test the same destination over Wi-Fi and cellular. Note the difference. This can help narrow down the network path, but does not by itself prove that the protocol is being blocked.
- Certificate-related error: Check the system time, server name, and certificate validity. Don’t remove TLS security settings as a first step.
- Small requests work, but large pages stall: Check packet loss, path MTU, and server logs. This alone does not prove that a particular protocol is underperforming.
How to choose a Type and save it in Add Server
Start with a complete set of existing server details. Don’t guess the port or switch Types at random. The steps below focus on the Home screen on iPhone and iPad. Available fields vary by Type; enter only what the selected protocol requires and what your configuration specifies.
-
Open the add-server screen
Go to Home → “+” in the top-right corner to open Add Server. Have the server’s address, port, authentication details, and transport settings ready. Don’t combine parameters from unrelated sources.
-
Choose a type
Open Type and select the protocol used by your original configuration. For example, if it specifies Hysteria2, don’t choose another type with a similar name. If the required option isn’t available, first check the app’s status in the App Store and the configuration’s compatibility requirements.
-
Enter the basic details
Enter Address and Port, then fill in Password, UUID, or keys as required by the protocol. For example, if your configuration specifies Port 8443, enter 8443. Don’t change it to 443 just because TLS is enabled.
-
Check additional settings
Check TLS, server name, and transport options against your original configuration. For WebSocket, verify Host and Path. For WireGuard, check the tunnel address and peer settings; don’t use fields from another protocol.
-
Save and test
After saving, return to Home, select the entry, and connect. If a system prompt asks for permission to add a VPN configuration, follow the prompt. Check the result with Connectivity Test and by opening a webpage. Note any errors, then change one setting at a time and try again.
Importing a subscription and adding a server manually serve the same purpose, but use different workflows and maintenance methods. If you already have your own subscription, go to Home → “+” → Type → Subscribe and enter your subscription URL. A subscription update may change entries and fields, so record important manual changes first. Subscription URLs can contain access credentials; don’t share them in screenshots or support requests.
How are protocols different from Global Routing and On Demand?
The protocol determines how Shadowrocket connects to a configured server. Global Routing determines how requests are handled, while On Demand determines when a connection is triggered. To troubleshoot, check Home → Global Routing, Config, and Settings → On Demand separately. Don’t confuse these three types of settings.
| Setting | What it does | What to check |
|---|---|---|
| Add Server → Type | Determines the protocol used to connect to the server. | Must match the server’s authentication, transport, and security settings. |
| Global Routing → Proxy | Handles requests using a proxy route. | When troubleshooting, check actual requests and connection records too; the toggle alone isn’t enough. |
| Global Routing → Direct | Handles requests using a direct connection. | A webpage opening successfully does not prove that the current protocol carried that request. |
| Global Routing → Config | Handles requests according to the enabled configuration rules. | In Config, check which configuration is enabled and which policy the rules match. |
| Global Routing → Scene | Applies routing settings based on configured scene conditions. | Check the scene conditions and the settings actually in effect. Scene is not a protocol. |
| Settings → On Demand | Triggers a connection when the configured conditions are met. | Does not replace server settings or match rules for individual requests. |
In Config, DOMAIN-SUFFIX, GEOIP, IP-CIDR, and FINAL are rule keywords, not Type options. For example, DOMAIN-SUFFIX,example.com,DIRECT routes requests matching the domain suffix through DIRECT; FINAL,DIRECT is the fallback policy when no earlier rule matches. Rules are evaluated in order. If a webpage connects directly, check which rule matched before changing the protocol.
FAQ: Why does it still fail if the config imports and the test succeeds?
A successful import only means the content was recognized. It doesn’t prove that authentication works, UDP is reachable, or webpage requests use the expected policy. Keep the original configuration, then troubleshoot settings, network, mode, and rules in that order. Avoid changing several things at once, so you can compare results.
Can I change the same server from VMess to VLESS by editing its Type?
Changing the Type alone does not convert a configuration. Open the entry’s editor from Home and check whether the server separately provides VLESS settings for the port, UUID, transport, and security. Create an entry with the new settings only if the server explicitly supports that combination.
Hysteria2 won’t connect. Will changing the port to 443 fix it?
Changing the port is no substitute for checking the configuration. First confirm the server’s actual UDP port in the entry editor, then test the same configuration on another network. 443 is just a port number; using a port that isn’t listening won’t establish a connection or change how the network handles UDP.
Why are there different protocols after refreshing a subscription?
A subscription can contain entries with different Types. Open each entry from Home and check its type and settings individually. Refreshing retrieves the subscription content again; it does not convert one protocol into another. When testing, make sure the intended entry is selected.
Does a successful Connectivity Test mean webpages will definitely work?
No. The result reflects the selected test method and destination; it does not cover every request path. Also check the mode under Home → Global Routing. If you use Config, review the enabled rules too, and check DNS resolution and what happens when you open the webpage.
Which protocol is always fastest and safe to choose?
There is no universal answer independent of the server and network conditions. Keep the test network, destination webpage, and approximate time of day the same, then compare loading and stability across configurations that work. Don’t attribute a one-off speed difference between servers in different regions to the protocol alone.