Shadowrocket supports a range of proxy and tunneling protocols. This guide assumes you already have a service and its configuration. It explains the parameters each protocol requires, what to check in Home → Add Server, and what to troubleshoot first if a connection fails. Select the Type that matches your existing configuration, then verify authentication, transport, and TLS settings. Changing the protocol name alone does not convert an entry to another protocol.
Quick guide: Protocol, transport, and routing are different settings
Shadowsocks, VMess, VLESS, Trojan, HTTP, SOCKS5, WireGuard, and Hysteria2 each define how a client communicates with a server. The address and port are just the connection endpoint; the password, UUID, keys, and transport settings together determine whether the connection can be established. Display names in the list can be customized, so a name that mentions a protocol does not mean the Type is set to that protocol.
The transport layer determines how data is delivered, such as over TCP, WebSocket, or QUIC. TLS provides encryption and identity verification for the relevant connection layer. Global Routing determines how a particular request is handled. Changing Global Routing will not fix an incorrect password or make a network that blocks UDP carry QUIC.
Check the Type first, then troubleshoot the port
Even if both entries use port 443, check each Type and its server settings separately. Do not infer that an entry uses Trojan, VLESS, or Hysteria2 from the port number.
Identify and check an existing configuration in Add Server
Adding a server manually is useful for checking a single entry; an existing subscription keeps its source and can be updated in one place. In either case, verify the original settings first. Subscriptions may contain access credentials, so do not share full URLs, QR codes, passwords, or private keys when troubleshooting.
-
Open the add-server screen
Go to Home → tap “+” in the upper-right corner to open Add Server. In Type, select the protocol that matches your existing configuration. Do not guess based on the display name.
-
Check the endpoint
Use your existing configuration to enter the address and port. In the address field, enter only the hostname or IP required by that field. Do not paste an entire share link as the hostname, and do not assume 443 is the default port for every protocol.
-
Check authentication
For Shadowsocks, verify the encryption method and password. For VMess and VLESS, verify the UUID. For Trojan and Hysteria2, check the relevant authentication details. For WireGuard, verify the local private key and peer public key. These credentials are not interchangeable.
-
Check the transport
Check TLS, the server name, and the underlying transport against the existing configuration. If it uses WebSocket, also verify the path and Host. A resolvable address does not mean these fields can be skipped.
-
Save and test
After saving, return to Home, select the entry, and run Connectivity Test. Then test access to a specific destination. If you use an existing subscription, go to Home → “+” → select Subscribe under Type and enter your own subscription URL. After updating, check the entries again to make sure the subscription has not overwritten local changes.
Shadowsocks, VMess, and VLESS: Distinguish authentication from encryption
These three protocols often appear in existing subscriptions, but their settings differ. Shadowsocks relies on both sides using the same encryption method and password. VMess uses parameters such as a UUID for authentication and has its own data-protection mechanism. VLESS does not encrypt content by itself; having a UUID does not mean the connection is protected by TLS.
| Protocol | Check these settings | Common mistake |
|---|---|---|
| Shadowsocks | Address, port, encryption method, password, and any plugin settings required by the existing configuration | The password is correct, but the encryption method does not match the server |
| VMess | UUID, transport, encryption settings, and TLS parameters if enabled | Copying only the UUID and missing the WebSocket path or TLS settings |
| VLESS | UUID, transport, TLS, or security-layer settings specified by the existing configuration | Treating the UUID as a password, or assuming the protocol encrypts content by itself |
For example, if the existing configuration requires the WebSocket path /gateway, entering / points to a different endpoint. The required Host may also differ from the connection address. Resolving the domain and reaching the TCP port only confirms that the initial connection steps work; it does not verify the authentication or path.
- The Shadowsocks encryption method must match exactly. Do not assume similarly named methods are the same algorithm.
- VMess authentication involves time checks. If authentication fails, also check that the date and time on your Apple device are correct.
- Check the VLESS UUID and security-layer settings together. Disabling the security layer is not a troubleshooting fix.
Trojan and Hysteria2: Both use a security layer, but have different transport requirements
A typical Trojan configuration uses TLS for authentication and proxy traffic. In addition to the password, check the certificate, server name, and actual connection address. The connection IP may differ from the domain in the certificate. If the existing configuration specifies a server name, keep it rather than replacing it with the address field value.
Hysteria2 is based on QUIC, uses UDP at the transport layer, and incorporates TLS. It is not interchangeable with other Hysteria protocol generations just because the names are similar. If a network restricts UDP, a TCP service can work while Hysteria2 times out. In that case, check the network conditions and port protocol first instead of repeatedly changing the authentication string.
- Trojan: Check the address, port, password, and TLS server name. If you see a certificate error, first check the device time, server name, and certificate validity.
- Hysteria2: Check the authentication details, TLS settings, and any obfuscation or bandwidth parameters specified by the existing configuration. Only enter these if they are included in the configuration; do not add them yourself.
- Check for both: If the source configuration uses port 443, confirm whether TCP, UDP, or both must be allowed. The same port number does not mean the same network path.
- Performance comparisons: Compare under the same network, destination, and test window. A protocol name does not tell you its throughput, and a latency test is not a substitute for sustained transfer testing.
HTTP, SOCKS5, and WireGuard: Different purposes and credentials
HTTP and SOCKS5 are commonly used with existing proxy endpoints. An HTTP proxy can use CONNECT to create a tunnel to a destination, but that does not automatically mean the client-to-proxy connection uses TLS. If the destination uses HTTPS, its TLS connection and encryption of the proxy connection are separate matters.
SOCKS5 supports different commands and authentication methods, but the protocol name alone does not guarantee that the server and network support UDP. A standard HTTP proxy should not be treated as a general-purpose UDP tunnel either. If your use case depends on UDP, check the specific configuration and what it supports in practice.
| Type | Main settings | What to check |
|---|---|---|
| HTTP | Proxy address, port, and optional username and password | Whether the endpoint uses TLS and whether the authentication requirements match |
| SOCKS5 | Proxy address, port, and optional username and password | Server capabilities, authentication method, and required UDP support |
| WireGuard | Local private key, tunnel address, peer public key, Endpoint, and other settings specified by the configuration | Key pairing, UDP reachability, and tunnel address settings |
WireGuard is a key-based tunneling protocol, not a standard proxy with a username-and-password setup. The peer public key is not the local private key, and Endpoint is the peer's network address, not the tunnel address assigned to your device. Mixing up these addresses can leave the endpoint reachable while communication through the tunnel still fails. Keep your private key on your own device and in trusted configurations; never include it in a public screenshot.
Once the protocol is correct, use Global Routing to check for rule issues
Use Home to select a connection and server, Config to manage configuration files, and Settings for app preferences. Proxy, Direct, Config, and Scene under Global Routing are routing modes, not protocols. During troubleshooting, note the original setting before changing it temporarily. Scene behavior depends on the configured scenes, so also check which scene is currently active.
Config
RecommendedUses the rules in the current configuration to determine how connections are handled. A matching rule may use PROXY, DIRECT, or another defined policy. Traffic that does not match is handled by the final rule; it is not necessarily sent direct.
Best for: Everyday connections using verified rules in an existing configuration
Proxy
Routes connections that would normally be affected by routing rules through the proxy policy. This can help compare results with Config, but does not change the selected server's authentication or transport settings.
Best for: Temporarily checking whether a routing rule is causing access issues
Direct
Uses a direct connection rather than the selected remote proxy for this traffic. If the website opens, that does not prove the selected server is configured correctly.
Best for: Establishing a baseline for local network reachability
If Proxy works but Config fails, check the rules first
Keep the same server and destination. If switching to Proxy restores access, first check the matching policy and final rule in Config. Do not immediately change the Type, UUID, or password. Restore the original routing mode after testing.
For example, DOMAIN-SUFFIX,example.com,PROXY selects a policy based on a domain suffix; IP-CIDR,192.0.2.0/24,DIRECT matches an address range; GEOIP relies on IP geolocation data; and FINAL handles traffic that matches no other rule. These keywords determine where traffic goes, not which protocol it uses. The examples illustrate syntax and match criteria; they are not complete rules to substitute directly into an existing configuration.
FAQ: Importing, testing, and using a configuration
Why does the connection time out after a successful import?
A successful import only means the content was recognized and saved. Go back to Home, edit the entry, and first check the Type, address, and port, then verify authentication and transport settings. For Hysteria2 and WireGuard, also check UDP reachability. Testing on both Wi-Fi and cellular networks can help identify local network issues.
Can I change VMess directly to VLESS?
Changing the Type alone is not enough. The server must provide an endpoint for the protocol, and the UUID, transport, and security-layer settings must also match. If the source of your existing configuration provides a separate, complete set of settings, add it as a separate entry for testing and keep the original for comparison.
Why did my manual changes revert after updating a subscription?
Subscription entries refresh from their source, which can overwrite local changes. Compare the Type, port, and transport settings before and after the update. To test something temporarily, create a separate manual entry. For long-term maintenance, correct the configuration at its existing source instead of repeating the same changes after every update.
Does turning on On Demand make a protocol faster?
Settings → On Demand controls when a connection starts based on specified conditions. It does not change a protocol's encryption, congestion control, or server bandwidth. To troubleshoot automatic reconnections, check these conditions. To investigate speed, use the same network and destination, and record connection success rate, latency, and sustained transfer performance separately.
Choose in this order: use a protocol explicitly provided by your existing service, make sure all required settings are present, confirm the network meets its transport requirements, and then assess performance under consistent conditions. A list of supported protocols cannot replace the server configuration or guarantee that one protocol will be faster on every network.
Genuine App and Configuration Basics
Shadowrocket is a closed-source commercial app for Apple platforms, primarily used on iPhone and iPad. The App Store is the only place to get it. Before purchasing, check the developer, Shadow Launch Technology Limited, and app ID 932747118. Refer to the App Store listing for system requirements, compatibility, and purchase availability. The one-time purchase covers the client app, not a network service plan. This site does not provide, sell, or recommend servers or subscriptions; the setup steps assume you already have your own configuration.
Verify the official App Store listing Read the guide