Shadowrocket is available for iPhone, iPad, Mac, Windows, Android, and Linux. The iPhone and iPad app is available on the App Store for a one-time payment of $2.99; check the App Store listing for system requirements. The Mac (Apple silicon and Intel), Windows, Android, and Linux versions are free and available from this site’s download page. This guide helps users with an existing provider configuration identify protocols, check settings, and troubleshoot connection issues. It does not provide, sell, or recommend proxy servers or subscriptions.
First, distinguish protocols, transports, and rules
When adding a server from Home, the Type field in Add Server specifies the protocol used between the client and the remote server. Names such as Shadowsocks, VMess, VLESS, and Trojan define how the two ends authenticate, encapsulate, and exchange data. They are neither website categories nor speed tiers. Enter the type specified by your existing configuration; switching the Type for the same address at random will not make the connection work.
Transport is a separate layer. For example, a VMess or VLESS configuration may also include settings for WebSocket, gRPC, or TLS. Recognizing the protocol name alone does not mean you have all the required parameters. Rules determine which policy handles a request; changing a rule does not convert one protocol into another.
Check Type first, then verify the transport settings
Port 443 alone does not identify a connection as Trojan or confirm that it uses TCP. Check the protocol name in your existing configuration first, then verify the port, transport, authentication details, and TLS settings separately.
How Shadowsocks, VMess, VLESS, and Trojan differ
These four configuration types commonly differ in how they authenticate and where encryption is applied. The table highlights what to identify and verify; it is not a set of ready-to-use connection settings. Address and Port must match your existing configuration. Even if 443 is a common server port, do not substitute it without checking.
| Type | Design | Check first |
|---|---|---|
| Shadowsocks | An encrypted proxy protocol. The client and server must use compatible encryption methods and key details. | Address, Port, Method, Password, and any additional options specified in the configuration. |
| VMess | Uses details such as a UUID for authentication. The protocol handles data protection and can also be combined with an outer transport and TLS. | UUID, device time, transport, and related settings such as TLS, Host, and Path. |
| VLESS | A lightweight authentication protocol that does not encrypt data on its own; connection protection depends on the security layer used with it. | UUID, transport, TLS, or other security settings specified in the configuration. A UUID alone is not enough. |
| Trojan | Typically uses password authentication over a TLS connection. Certificate and server name validation must be configured correctly. | Password, Port, TLS Server Name, and the name covered by the server certificate. |
The Shadowsocks Method is not a freely selectable strength setting. If it does not match the server’s method, the client usually cannot decrypt the traffic. A VMess UUID is not a server address; copy every character and enable automatic time syncing on the device. Otherwise, a clock mismatch can cause authentication failures that may be mistaken for a rules issue.
“The protocol itself does not encrypt” in VLESS does not mean every VLESS connection is unprotected; check the security layer actually used. Do not hide Trojan certificate errors by disabling validation. First check the device time, Address, and TLS Server Name, then confirm that the configured domain has a valid certificate. The connection address, TLS Server Name, and WebSocket Host serve different purposes. They do not always need to match, and should not be substituted for one another blindly.
How to identify HTTP, SOCKS5, WireGuard, and Hysteria2
These names refer to different proxy or tunneling mechanisms. HTTP and SOCKS5 are not “weaker versions” of another protocol, and WireGuard is not a Type where you can enter any proxy password. Identify a setup from all the fields in your configuration, not just the server domain.
- HTTP: Commonly used for HTTP proxying and CONNECT tunnels; it may require a Username and Password. The term HTTP proxy does not guarantee that the connection between the client and proxy server is encrypted with TLS. HTTPS on the destination website and encryption on the client-to-proxy connection are separate things.
- SOCKS5: A general-purpose proxy protocol that can support TCP connections and UDP forwarding. A username and password are authentication details, not traffic encryption. UDP availability also depends on the server and current configuration; the Type alone does not tell you whether it works.
- WireGuard: A UDP-based encrypted tunnel that requires a paired key setup and tunnel network parameters. Check the meaning of Endpoint, the client Private Key, peer Public Key, tunnel address, and Allowed IPs. An address and password alone are not enough to establish this kind of tunnel.
- Hysteria2: Based on QUIC and dependent on UDP, with matching authentication and TLS settings also required. If the network blocks the required UDP traffic, access to TCP 443 on the same host does not prove that Hysteria2 will work.
Hysteria2 is not automatically faster on every network, and WireGuard does not automatically route every request through the tunnel. Performance depends on path quality, server limits, UDP reachability, and rule selection. This guide does not choose a route based on protocol name. Start by restoring a verifiable connection with the protocol and settings in your existing configuration.
Enter your existing settings in Add Server
The steps below use the Home and Add Server labels from the iPhone / iPad app; layouts may differ on other platforms. Before entering settings manually, gather the complete protocol type, address, port, authentication details, and transport parameters. If you already have a subscription, use its complete configuration to avoid missing TLS or transport settings when copying values manually.
-
Open the Add Server screen
Go to Home → tap “+” in the top-right corner → Add Server. Check Type first, then select the matching option—such as Shadowsocks, VMess, VLESS, or Trojan—from your existing configuration. Don’t guess based on the name.
-
Enter the basic settings
Enter Address and Port, then add the Password, UUID, or key details required by that protocol. Use the port from the original configuration; do not change every entry to 443.
-
Check additional settings
Check any settings present in your configuration, such as TLS, Server Name, transport, Host, and Path. Keep the leading slash and letter case in Path exactly as specified. Don’t guess at settings that weren’t provided.
-
Save and test
After saving, return to Home, select the entry, and connect. Note the test destination, current Global Routing mode, and any errors, then test a webpage as well. A latency number alone does not confirm that everything is working.
To import a subscription, go to Home → “+” → Type → Subscribe, enter your existing subscription URL, and save. Then update the subscription from Home. A subscription is a way to retrieve a collection of configurations, not a traffic protocol alongside VMess or VLESS; each entry still has its own Type. Troubleshoot subscription update failures separately from connection failures for saved entries.
- Treat subscription URLs and authentication details as sensitive. Redact tokens, Passwords, Private Keys, and similar details when asking for help.
- If settings change after an update, compare them with the original configuration details. Do not identify a protocol from the entry’s display name alone.
- A share-link prefix can help identify a protocol, but it does not replace checking the imported Type and complete settings.
After confirming the protocol, check Global Routing
Global Routing on Home determines how requests are assigned a policy. Config manages configuration files, while Settings manages app preferences. The protocol establishes a connection to the server; the routing mode determines which requests use it. Check these separately. The comparison below covers Shadowrocket routing settings, not protocol speeds.
Config: Use the rules in your configuration
RecommendedThe rules in the current configuration file determine which policy is used. In Config, confirm which file is selected, then check the rule order and final policy. “Recommended” here means a practical way to verify everyday routing against your existing rules, not a recommendation for any particular route.
Best for: Checking where a specific website and other requests are routed when you already have rules configured.
Proxy: Check the proxy path
Routes connections handled by this mode through the proxy. Use it to distinguish a server connection issue from a rule-matching issue. Restore the original mode after testing so a temporary diagnostic setting does not become your final routing setup.
Best for: Checking whether the proxy path works when the same destination fails under Config.
Direct: Check the direct connection
Connections handled by this mode go directly to their destinations. A webpage loading in this mode does not prove that the proxy protocol works; it only shows the result of the direct connection path.
Best for: Checking the basic network and direct access—not for confirming proxy authentication.
Global Routing may also show Scene, which applies settings based on a scene. Check which scene is currently active and its routing configuration; Scene is not simply another name for Proxy. Settings → On Demand controls conditions for connecting on demand, not protocol options. During troubleshooting, note whether it affects connection behavior, as a network change may alter the conditions for your test.
For example, the rules below use DOMAIN-SUFFIX to match a sample domain and FINAL for requests that do not match. PROXY must refer to a valid proxy policy in the current configuration. Rules do not create a server or fill in any protocol authentication details.
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECTDOMAIN-SUFFIXmatches a domain suffix. Confirm that the requested domain actually falls under that suffix.IP-CIDRmatches an IP range, whileGEOIPmatches using an IP geolocation database; neither is a proxy protocol.FINALis a fallback rule. A broad match placed earlier may prevent more specific rules below it from being reached.
Troubleshooting: Check the symptoms before changing protocols
The following are troubleshooting steps, not results from device testing. Change one variable at a time and note whether the failure occurs during parsing, connection, TLS, authentication, or rule selection. Changing Type, port, and rules repeatedly without keeping records makes results impossible to compare.
Can I change VMess to VLESS for the same address?
Don’t switch the value in Add Server → Type and assume all the other settings will still work. The server must provide an entry point for the selected protocol. Check Type, Port, UUID, transport, and security settings in your existing configuration, then save and test each entry separately.
Trojan shows a certificate error. Should I disable validation?
First check that automatic time is enabled on the device. Then compare Address, Port, and TLS Server Name in Add Server, and confirm the name matches a valid certificate. Keep certificate validation enabled; correct the settings or certificate issue before trying again.
Why does Hysteria2 time out when a TCP test succeeds?
Hysteria2 requires a UDP path. First confirm the UDP port and authentication details in the configuration, then test on a network that allows that UDP traffic. A successful TCP test does not mean the QUIC handshake will succeed.
There’s a latency reading, but webpages won’t load. What should I check first?
Go to Home → Global Routing and check the mode, then confirm which entry is selected. If the destination works under Proxy but fails under Config, check the matching rules, DNS, and policy in Config first. A latency result does not mean the full request to the destination website succeeded.
A subscription update failed. Do I need to recreate every entry?
First distinguish a failed subscription fetch from a connection failure for a saved entry. Update the existing subscription from Home and note the error; check whether the URL has expired and whether the network can reach it. If existing entries can still be tested, there is no need to delete all your configurations straight away.
What to record after troubleshooting
After a test, keep enough configuration details to reproduce it rather than just noting that a protocol “works.” The same protocol can use different transports, and a successful connection does not mean the rules are routing as expected. To retest later, use the same destination and routing mode.
- Configuration: Record the Type, port, transport, and whether TLS is enabled. Do not include sensitive authentication details in public notes.
- Routing: Record the Global Routing mode, current Config, and the policy expected to match the test request.
- Network: Record whether you used Wi-Fi or cellular data, and whether the issue only occurs on the UDP path.
- Results: Record the exact error and the stage where it occurred. Avoid vague descriptions such as “fast,” “slow,” or “connects.”
For help understanding configuration fields, read the protocol guide. To identify keywords such as DOMAIN-SUFFIX and IP-CIDR, see the quick reference. Enter your existing configuration accurately first, then use the rules to check where requests go—a repeatable approach to working with multi-protocol configurations.