Shadowrocket supports several connection protocols, but matching protocol names do not mean their settings are interchangeable. This guide is for users who already have a service provider and connection details. It explains what to check across authentication, transport, encryption, and routing, so you can identify whether to verify the Password, UUID, TLS, UDP, or key fields before importing the configuration and testing the connection. We do not provide, sell, or recommend nodes or subscriptions.
Understand protocols, transport, and routing first
A protocol determines how the client communicates with a server; Global Routing determines which path handles traffic. These are separate settings. Adding Trojan in Home does not automatically route every request through that entry, and adding rules in Config does not supply missing server authentication details.
Shadowrocket is a paid client for Apple platforms, primarily iPhone and iPad, and is available exclusively through the App Store. It is closed-source commercial software sold as a one-time purchase; buying the client does not include a service plan. Check the App Store listing for system requirements and purchase availability.
| Layer | Typical settings | What to verify |
|---|---|---|
| Protocol and authentication | Shadowsocks、VMess、VLESS、Trojan | Type, Password, or UUID must match the server |
| Transport and handshake | TCP、UDP、WebSocket、TLS、QUIC | Confirm the server uses the same transport and handshake settings |
| Server entry | Address, port, and authentication fields | Connect to the correct service endpoint |
| Traffic routing | Global Routing and rules in Config | Confirm the request being tested actually uses the selected entry |
The port number does not identify the protocol. 443 is commonly used for TLS services, but entering 443 does not enable TLS automatically. If the server uses another port, enter the value shown in your existing configuration. The comparison below explains settings; it does not rank protocol performance.
Shadowsocks, VMess, and VLESS: Check authentication first
For these three protocols, first match the Type and authentication details, then check any additional transport settings. Do not copy an entry's address and password into a different Type. Changing the client's selection does not change which protocols the server supports.
| Protocol | Key fields | Encryption and transport notes |
|---|---|---|
| Shadowsocks | Server, port, Password, and encryption method | The encryption method must match; UDP support depends on both configurations and network conditions |
| VMess | Server, port, UUID, encryption, and transport settings | Authentication is time-sensitive; WebSocket or TLS also requires matching fields |
| VLESS | Server, port, UUID, transport, and security settings | The protocol itself does not encrypt payloads; security depends on the outer mechanism used in the configuration |
Shadowsocks: Don't guess the encryption method
The Shadowsocks Password and encryption method must be checked together. For example, if your existing configuration specifies aes-128-gcm, do not change it to chacha20-ietf-poly1305. Some methods have additional key-format requirements, so do not assume all authentication material is an ordinary password of any length. Keep the imported settings intact, then compare each field with your existing configuration.
VMess: Check the UUID and device time
VMess uses a UUID as an important authentication credential, and a significantly incorrect device clock can cause authentication to fail. First make sure the system date and time are correct, then check that the UUID is complete. If the server uses WebSocket, verify the Path and Host as well. If TLS is also enabled, check the server name and certificate verification settings. These values cannot be derived from the UUID.
VLESS: Authentication is not encryption
A VLESS UUID identifies the user; it does not mean the traffic is encrypted. Check TLS or other supported security settings against your existing configuration. If it includes Flow, confirm both ends support and use the same setting. VLESS and VMess both use UUIDs, but that does not mean you can change only the Type and leave all other settings untouched.
- Authentication failure: Check the Password, UUID, encryption method, and time first.
- Handshake failure: Then verify TLS, the server name, and certificate settings.
- Using WebSocket: Also check the Path and Host, including letter case and the leading slash.
Trojan and Hysteria2: Check TLS and UDP separately
For Trojan, focus on the password and TLS. Hysteria2 also requires a network that can carry UDP. For either protocol, a reachable port alone does not prove that the protocol handshake or an actual request has succeeded.
| Protocol | Connection characteristics | Check first |
|---|---|---|
| Trojan | Typically handles authentication and proxy traffic within a TLS connection | Password, TLS server name, certificate, and system time |
| Hysteria2 | Based on QUIC and relies on UDP underneath | Authentication details, TLS, UDP reachability, and any additional settings in your existing configuration |
With a domain certificate, the Trojan connection address may differ from the server name used for TLS verification. Enter each value according to your configuration. For example, if the server address is an IP but the certificate was issued for a domain, do not use the IP in place of the certificate name. If you encounter a certificate error, check the name, certificate validity, and system time rather than treating disabled verification as the default fix.
Hysteria2 is not enabled by switching another protocol's transport setting to UDP. It has its own handshake and authentication flow, and its settings cannot be mixed with configurations for other Hysteria generations. If the current network restricts UDP, Hysteria2 may not connect even when ordinary websites and TCP services are reachable. If your existing configuration includes bandwidth or obfuscation settings, verify them as provided rather than guessing or entering larger values.
Takeaway: Check network conditions first
If the same Hysteria2 configuration fails only on a particular Wi-Fi network, test it over cellular first and note the difference. Then check the Wi-Fi network's UDP conditions. Do not change authentication fields first or assume other protocols will necessarily be faster.
HTTP, SOCKS5, and WireGuard: Proxy endpoint or tunnel?
HTTP, SOCKS5, and WireGuard use different field structures and cannot share the same account setup. The first two are common proxy endpoints; WireGuard uses keys to create a network-layer tunnel. Access to a destination also depends on what traffic the server allows it to forward.
- HTTP: Check the server, port, and whether a username and password are required. An HTTP proxy endpoint does not inherently encrypt the connection to the proxy server; check the actual configuration to see whether TLS is enabled. When accessing an HTTPS site, distinguish the site's TLS connection from TLS on the proxy endpoint itself.
- SOCKS5: Check the server, port, and authentication requirements. SOCKS5 does not encrypt payloads by itself, and UDP forwarding requires support from the server. A successful TCP request does not prove that UDP requests can also be forwarded.
- WireGuard: Check the local Private Key and tunnel address, the peer's Public Key, the Endpoint, and any required settings such as Allowed IPs. If a Preshared Key is provided, it must match the peer's; it cannot replace the public/private key pair.
A WireGuard Endpoint contains the server address and port, while the tunnel address is internal to the tunnel; they are not interchangeable. Allowed IPs define address ranges and influence peer selection. They are not domain rules and cannot directly replace DOMAIN-SUFFIX in Config. When troubleshooting, check the key pairings, UDP reachability, and the peer's return route.
Import an existing configuration: Check Home → Type
Importing is usually better than rebuilding a configuration manually because it preserves complex settings, but you should still verify key fields afterward. The steps below assume you already have a subscription or a single connection configuration. A subscription manages server entries; a configuration file in Config manages rules and related behavior. They are not the same set of settings.
-
Keep the original configuration
Note the currently selected server and the Home → Global Routing setting. Before making changes, keep a recoverable copy of the existing configuration so troubleshooting does not cause you to lose both the connection settings and the rules.
-
Choose an import method
To add a single connection manually, go to Home → “+” in the upper-right corner → Type, then select the protocol used by your existing configuration. To use a subscription, select Subscribe under Type along the same path and enter your own subscription URL.
-
Check each field
After saving, check the server, port, and Password or UUID. Then verify the protocol-specific TLS, WebSocket, UDP, or WireGuard key settings. After updating a subscription, check whether the entries have been replaced by content from the remote source.
-
Test after connecting
Return to Home, select the entry you want to test, and turn on the connection. Allow the VPN configuration when prompted by the system. Note the current Global Routing setting, then visit a specific test destination. Do not rely only on the latency number shown in the list.
Troubleshoot subscription update failures separately from server connection failures. An update may fail because the subscription URL is invalid, the token has changed, or the fetch path is unreachable. A server connection may fail because of authentication, the handshake, or forwarding. Keep the existing entries, identify the stage where the failure occurs, and then update the existing subscription. Repeatedly deleting and re-adding entries will not fix incorrect server-side settings.
Use Global Routing to isolate protocol and rule issues
When testing a protocol, keep the server and destination fixed and change only one routing setting at a time. Proxy, Direct, Config, and Scene under Home → Global Routing are routing modes, not connection protocols. Scene applies the configured scene; it is not an additional transport method.
Config
RecommendedRoutes requests according to the active rules in Config. Rules can direct traffic to DIRECT, a proxy policy, or REJECT; requests that do not match a rule do not necessarily go direct automatically.
Best for: Everyday use with valid rules when you need to check routing results rule by rule
Proxy
Uses the proxy path as the global routing choice and can help isolate the effect of ordinary routing rules. It does not guarantee that all system traffic is captured, and it cannot fix protocol authentication failures.
Best for: Temporarily checking whether the selected server can reach a destination
Direct
Handles requests through a direct connection. If a website opens in this mode, that does not prove the proxy server selected in Home completed its handshake.
Best for: Checking whether the local network and destination are reachable, as a troubleshooting comparison
The following is a rule syntax example, not a complete configuration ready to use as a replacement. PROXY must refer to a valid proxy policy in the current configuration. Rules are evaluated in order, and FINAL handles requests that did not match earlier rules.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXYDOMAIN-SUFFIX matches domain suffixes, IP-CIDR matches IP address ranges, and GEOIP uses a geolocation database to determine an address's location. If a destination works with Proxy but fails with Config, check the matching rule, policy, and DNS results before changing protocols. Restore the original routing mode after testing so the temporary settings do not affect later requests.
Common protocol connection questions
Why does the handshake still fail when the port is set to 443?
The port does not determine the protocol. Go back to Home and edit the entry. First confirm the Type, then check whether TLS, a server name, and authentication fields are required. If you use WebSocket, also verify the Path and Host. A reachable port does not mean the full handshake succeeded.
Why won't websites load even though a latency value appears?
A latency test reports only the result of a specific test. First check that Home → Global Routing is not set to Direct, bypassing the entry you want to test. Then temporarily use Proxy to isolate routing rules and visit the same destination. If it still fails, check DNS, authentication, TLS, and server forwarding separately.
Does Hysteria2 or WireGuard fail only after switching Wi-Fi networks?
Keep the configuration unchanged and test over cellular first. These two connection types rely on UDP, so changed network conditions are worth checking early. Then check Settings → On Demand for settings that trigger connections based on the network. To avoid automatic changes interfering with a manual test, note and temporarily disable relevant triggers, then restore them afterward.
After updating a subscription, can I just switch Type back to the previous protocol?
Changing Type alone is not enough. Check all fields provided by the existing subscription and confirm whether the server-side protocol has actually changed. If the updated details are incorrect, check with your service provider. Authentication, transport, and TLS settings must match as a set; keeping the old password does not guarantee that the connection will work.
A useful troubleshooting record includes the current network, selected protocol, Global Routing setting, destination address, and failure stage—not just “it doesn't work.” Change one variable at a time and retest the same destination to determine whether the issue is in the configuration, network, or rules. For help with first-time authorization and basic operation, see the guide on this site.