Shadowrocket supports a range of proxy and tunneling protocols, but client support doesn’t mean the server has them enabled. This guide is for users who already have a provider and subscription and are ready to import settings or enter them manually. Identify the protocol in the comparison table, check authentication, transport, and TLS, then distinguish protocol type from Global Routing. This helps avoid blaming connection failures on a protocol being “too slow.”
Protocol and settings quick reference
Use Add Server in Shadowrocket to add a connection configuration. Fields vary across Shadowsocks, VMess, VLESS, Trojan, HTTP/SOCKS5, WireGuard, and Hysteria2. Check Type first, then enter the server address and authentication details. Get an existing subscription from your provider; don’t guess the protocol based on the port number alone.
| Protocol | How it works | Check first |
|---|---|---|
| Shadowsocks | Creates a proxy connection using a password and a specified encryption method | Address, port, Password, encryption method |
| VMess | Uses UUID authentication and has its own data protection mechanism | UUID, encryption settings, transport, TLS |
| VLESS | Uses UUID authentication; the protocol itself does not encrypt data | UUID, transport, TLS, and any additional parameters required by the server |
| Trojan | Typically carries proxy traffic over TLS and uses password authentication | Password, TLS, server name, and certificate |
| HTTP/SOCKS5 | A general-purpose proxy protocol; authentication depends on the server | Proxy type, port, username, password, TLS requirements |
| WireGuard | An encrypted IP tunnel over UDP | Keys, peer endpoint, tunnel address, routing parameters |
| Hysteria2 | Proxy transport over QUIC, which relies on UDP | Authentication, port, TLS, obfuscation, and bandwidth settings |
This table is a checklist, not a complete support matrix. To determine whether a specific protocol extension is available, check both the fields offered in the app and the server configuration. Even if two entries use port 443, they may carry Trojan, VLESS, or Hysteria2. The port is only one part of the connection destination; it does not determine the protocol.
Shadowsocks, VMess, and VLESS: authentication is not the same as encryption
The client and server must use the same encryption method and password for Shadowsocks. Changing the encryption method alone won’t make it compatible with the server. If the address and port are correct but authentication still fails, compare the imported settings with the original details from your provider instead of repeatedly switching methods.
VMess and VLESS both use UUIDs, but you can’t convert one into the other just by changing Type. VMess has its own data protection mechanism; VLESS does not encrypt data by itself, so connection security depends on the outer security layer. A UUID is authentication information, not a TLS certificate, and shouldn’t go in the server name field.
- Authentication: Check that the UUID or password is complete. Make sure copying hasn’t added spaces, line breaks, or non-English punctuation.
- Transport: Settings such as TCP and WebSocket must match the server. For WebSocket, also check Path and Host.
- Security: Check separately whether TLS is enabled, which server name is used, and what certificate validation requires. A resolvable address is not a substitute for validation.
- Additional parameters: If the original configuration includes special flow-control or security parameters, import them as provided. Don’t remove them or reuse settings from another entry.
Trojan and HTTP/SOCKS5: distinguish the proxy protocol from TLS
Trojan typically handles authentication and proxy traffic over a TLS connection. Check both Password and the TLS settings. Even with the right password, a server name mismatch can cause certificate validation to fail before authentication. The destination can be a domain name or an IP address, but the server name used for certificate validation must match the server’s instructions.
HTTP and SOCKS5 mainly define how a proxy connection is negotiated. The protocol name alone doesn’t mean the connection to the proxy server is encrypted. An HTTP proxy can use CONNECT to tunnel traffic to an HTTPS destination, but that’s separate from using TLS between the client and the proxy server. Whether a SOCKS5 server accepts a username and password or supports UDP forwarding also depends on the server.
- Common ports:
443is often used for TLS services,1080for SOCKS5, and8080for HTTP proxies. These are conventions only; use the values provided by your provider. - Authentication example: If the server requires a username and password, enter both. Don’t paste the entire subscription URL into Password.
- Diagnosing errors: For HTTP
407, check proxy authentication first. For a TLS handshake error, check TLS and the certificate rather than changing rules.
WireGuard and Hysteria2: both use UDP, but their configuration needs differ
WireGuard is an IP-layer tunnel that uses keys for authentication. Keep the local Private Key, the peer’s Public Key, and any Preshared Key required by the server separate; these fields aren’t interchangeable. In addition to the server endpoint, check the assigned tunnel address and routing parameters. example.com:51820 is just a format example; port 51820 isn’t required.
Hysteria2 is based on QUIC, runs over UDP, and uses TLS. Authentication, server name, and optional obfuscation must match the server. Set bandwidth parameters according to the actual connection and your provider’s instructions; entering a higher value doesn’t provide more available bandwidth.
| What to check | WireGuard | Hysteria2 |
|---|---|---|
| Identity and authentication | Key pair and optional preshared key | Authentication details configured on the server |
| Connection basics | Encrypted IP tunnel over UDP | QUIC connection over UDP with TLS |
| Common errors | Peer public key, endpoint, or tunnel address doesn’t match | Authentication, server name, or obfuscation doesn’t match |
| Network restrictions | Handshake fails if UDP is blocked | QUIC connection can’t be established normally if UDP is blocked |
Bottom line: check UDP reachability first
If the same configuration works on cellular but keeps timing out on a particular Wi-Fi network, compare UDP restrictions on both networks before checking protocol settings. Don’t judge speed by the protocol name or keep increasing bandwidth values.
Import and verify: keep the original settings, then test one change at a time
For an existing subscription, import the complete content provided by your provider. It may include more than the address and password, such as TLS, transport, and protocol extension settings. Manual entry works for a single connection when all fields are known. If details are missing, get them first instead of guessing.
-
Confirm the source
Get your existing subscription or individual connection details from your provider. Confirm the protocol, address, port, and authentication method, and keep the original content for comparison.
-
Import a subscription
On Home, tap “+” in the upper-right corner to open Add Server. Set Type to Subscribe, enter your subscription URL, and save. Check that the expected entries appear.
-
Check the fields
To add a connection manually, go to Home → “+” → Add Server and choose the actual protocol under Type. Enter the address, port, and authentication details first, then check TLS, transport, and protocol-specific settings.
-
Test the connection
Return to Home, select the entry, and enable the connection. Complete authorization when prompted by the system. Test access to a known destination, note any error, and change only one setting at a time.
A subscription update fetches the content published by your provider. Treat this separately from manually editing a single node. If an entry reverts after an update, check the subscription source settings first; don’t assume local edits will be kept. A token in a subscription URL is a credential—remove it before sharing logs or configurations.
Check Global Routing separately from protocol type
The protocol determines how Shadowrocket connects to the server; Global Routing determines how requests entering the tunnel are handled. Switching to Trojan won’t automatically enable rule-based routing, and selecting a node doesn’t mean every request will use it. When troubleshooting, check the connection entry on Home, the current Global Routing mode, and the active configuration in Config separately.
Config
RecommendedHandles requests according to the rules and policies in the current configuration. A match may result in PROXY, DIRECT, REJECT, or a defined policy; it doesn’t necessarily mean all unmatched requests go direct.
Best for: everyday use with an existing, verified routing configuration
Proxy
Handles requests entering the tunnel in proxy mode, which can help isolate differences caused by rule-based routing. The selected connection must still have the correct protocol and authentication settings.
Best for: temporarily testing a proxy connection or checking whether rules are affecting it
Direct
Handles requests in direct mode. If a webpage loads, that doesn’t prove the selected proxy entry works or that a particular protocol connected successfully.
Best for: establishing a direct-connection baseline on the local network
Scene in Global Routing is a mode, not another proxy protocol. Check the actual settings for the active scene. Settings → On Demand manages conditions for connecting on demand; it won’t fix an incorrect UUID, password, or TLS configuration. Test the connection manually first, then check the automatic connection conditions to distinguish a connection failure from a connection that never triggered.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYThe example above illustrates rule syntax and matching order; it isn’t a complete, working Config. DOMAIN-SUFFIX matches domain suffixes, IP-CIDR matches IP ranges, GEOIP relies on IP geolocation data, and FINAL handles requests that haven’t matched earlier rules. REJECT denies a request. Rule keywords determine where requests go; they don’t fix protocol handshakes. The example domains and documentation IP ranges don’t represent real services.
FAQ: What to check when a supported protocol won’t connect
I have a server address. Can I choose any Type?
No. Go to Home → “+” → Add Server → Type and select the protocol used by the server. An address and port alone aren’t enough to recreate the configuration. Get the authentication, TLS, and transport settings from your provider.
Why does one connection work and another fail if both use port 443?
Check Type first, then authentication and TLS. TCP port 443 and UDP port 443 are different transport endpoints. Trojan and Hysteria2 can’t share the same protocol settings just because they use the same port number.
Why can’t I open a webpage even though latency is shown?
A latency result only shows that the test received a response; it doesn’t confirm that DNS, authentication, and the destination request all succeeded. Return to Home and check Global Routing, then inspect the destination’s DNS resolution and the specific connection error. Don’t judge whether a protocol is working based on a latency number alone.
Do I still need protocol settings after buying Shadowrocket?
Yes. Buying the app doesn’t include a connection service. Shadowrocket is a closed-source commercial app; get connection details and any existing subscription from your provider. The app is primarily for iPhone and iPad. Check the App Store listing for compatibility with other Apple devices; system requirements and purchase eligibility are as listed on the App Store page.