In Shadowrocket, go to Home → + → Type and select the protocol specified in your existing provider configuration. Then check the address, authentication details, and transport settings. This guide is for users who already have a configuration but need help distinguishing protocol names from terms such as TLS, TCP, and UDP. Start with the comparison table, follow the setup steps, then use Global Routing to tell a connection issue from a rules issue.
Protocol comparison: choose a Type, then check transport and encryption
On Home, open an existing entry to edit it, or tap + in the top-right corner to view Type. This selects the protocol used to communicate with the server; it is not a speed setting. Shadowrocket supports the protocols listed below. For optional fields and supported transport combinations, refer to the current app interface and your existing provider's configuration details.
| Protocol | Transport | Encryption and authentication | Check these fields |
|---|---|---|---|
| Shadowsocks | Can carry TCP and UDP; actual UDP support also depends on the server and network. | Uses a specified cipher and shared key. Common AEAD ciphers provide both encryption and integrity protection. | Address, Port, Password, and cipher must match the configuration. |
| VMess | Can use TCP and other transports, with WebSocket and TLS available in some configurations. | Identifies the user with a UUID. Protocol-level encryption settings and outer TLS are separate layers. | UUID, encryption options, transport, and TLS settings. |
| VLESS | Transport and the outer security layer depend on the server configuration. | Uses UUID authentication. VLESS does not encrypt the payload itself and typically relies on an outer layer such as TLS. | UUID, transport, TLS, and any additional fields required by the server. |
| Trojan | Typically uses a TLS connection; UDP forwarding depends on the implementation and server support. | Uses Password authentication, with TLS protecting the connection and verifying the server's identity. | Password, SNI, certificate verification, and the actual listening port. |
| HTTP / SOCKS5 | HTTP proxies commonly use CONNECT to establish a tunnel. SOCKS5 supports CONNECT and also defines UDP ASSOCIATE. | Basic HTTP proxies and SOCKS5 do not encrypt the client-to-proxy connection. A username and password are not the same as transport encryption. | Proxy type, address, port, authentication, and whether TLS is also configured. |
| WireGuard | A UDP-based network-layer tunnel configured with Peer and address settings. | Uses public-key cryptography and can also be configured with a Pre-shared Key. | Private Key, Peer Public Key, tunnel address, Allowed IPs, and MTU. |
| Hysteria2 | Based on QUIC and runs over UDP; the network path must allow the required UDP traffic. | Uses QUIC's TLS 1.3 security mechanisms, with authentication configured as required by the server. | Authentication details, SNI, port, and optional obfuscation settings. |
If your provider's details mention WebSocket, TLS, or QUIC, don't assume they are all Type options. WebSocket is a transport encapsulation, TLS is a security layer, and QUIC is a secure transport protocol based on UDP. These terms are not in the same category as names such as Shadowsocks and VMess. Confirm the protocol first, then match each layer's settings to avoid errors such as a failed handshake despite a correct address and password.
Understand the layers: address, authentication, and TLS are not interchangeable
On the edit screen, enter Address and Port first, then provide the authentication details required by the selected Type. Address is the connection target, Port is the server's actual listening port, and SNI specifies the server name during the TLS handshake. Even if Address is an IP address, SNI may need to be the domain on the certificate. Don't assume they should always be the same.
Shadowsocks Password, VMess/VLESS UUID, and WireGuard Private Key are different authentication fields and cannot be used interchangeably. In WireGuard, the local Private Key must correspond to the client public key registered with the server. Peer Public Key is the other party's public key. Entering the client's own public key as Peer Public Key will usually prevent the expected handshake.
- Cipher: The Shadowsocks cipher name must exactly match the server configuration. Don't copy the Password and then pick a cipher at random.
- Transport: With WebSocket transport in VMess or VLESS, Host and Path may also need to match. Preserve the capitalization of Path and its leading slash exactly.
- Certificate verification: If Trojan or another TLS configuration reports a certificate error, check SNI, the device's date and time, and the certificate's validity first. Don't use Allow Insecure as a routine fix.
- Protect sensitive settings: Treat Private Key, Password, UUID, and subscription tokens as sensitive. When troubleshooting, show only field names and values that have been masked.
In short: match the fields, don't guess from the name
Break the server details into four parts—connection target, authentication, transport, and security layer—then enter each one in the corresponding field. If a field isn't specified, check whether it's required instead of borrowing a value from another working configuration.
Add an entry: verify Type after manual setup or import
Add server entries on Home. Use Config to manage configuration files and rules, and Settings for app preferences. Adding a protocol entry and switching rule configurations are separate tasks: the first determines how to connect to the server; the second determines which policy handles each request. The steps below assume you already have your own provider's settings.
-
Check the protocol
Go to Home → + → Type and select the protocol explicitly listed in your configuration. Changing Trojan to VLESS won't make them compatible, and changing the port alone won't turn Hysteria2 into another protocol.
-
Enter the destination
Return to the add form and enter Address, Port, and the authentication details for the selected protocol. Use the actual port specified. If the configuration says 8443, don't change it to 443 just because TLS is enabled.
-
Match the transport
Check TLS, SNI, transport, and additional settings in the fields shown for the selected Type. Before saving, make sure there are no extra spaces in domain names or line breaks in Password, and that the UUID is complete.
-
Check imported entries
If you already have a subscription, go to Home → + → Type → Subscribe, enter your own subscription URL, and save it. After importing, open an entry and check its Type and key fields. A subscription update may overwrite manual edits, so keep the original settings for reference.
-
Test the connection
Return to Home, select the entry to test, and turn on the connection. Allow the VPN configuration if prompted by the system. First test a destination you know is reachable, then check whether the request uses the expected policy. A single latency result does not prove that every service will work.
If protocol fields change after a subscription update, first check whether the server settings changed too, then test again. A subscription distributes and updates configurations; it doesn't automatically guarantee that every entry's server is available. Record the original values before editing an entry so you can tell an original configuration problem from a local change.
Global Routing: check protocol connectivity and rule matching separately
Go to Home → Global Routing and check the current mode before investigating why a request isn't using the selected entry. Config, Proxy, Direct, and Scene are routing controls, not protocol names. Scene organizes routing behavior by scenario; check the settings for the active scene. It is not another type of encryption.
Config
RecommendedHandles requests according to the current configuration's rules and policies. A match may route to DIRECT, a proxy, or another specified policy. If no earlier rule matches, FINAL typically determines where the request goes.
Best for: everyday routing after checking your rules.
Proxy
Sends requests routed through the proxy path to the selected proxy policy, which can help reduce rule matching as a variable during testing. Restore the previous mode afterward; this test does not verify traffic from every app.
Best for: distinguishing a server connection failure from a rule mismatch.
Direct
Uses a direct connection. If a webpage opens in this mode, that doesn't prove the Trojan, WireGuard, or other protocol settings you just entered are valid—the request may not have gone through that server at all.
Best for: comparing against your local network's basic connectivity.
In the configuration file selected under Config, check rule targets and policy names in order. This snippet demonstrates syntax only; it is not a complete configuration. PROXY must refer to an available policy in your actual configuration. DOMAIN-SUFFIX matches domain suffixes, IP-CIDR matches address ranges, GEOIP uses an IP geolocation database, and FINAL handles requests that didn't match any earlier rule.
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXYSettings → On Demand controls when a connection starts automatically based on conditions; it doesn't fill in missing protocol settings. If you haven't verified the protocol yet, connect manually and confirm it works before configuring On Demand. This keeps automatic triggers separate from handshake issues while troubleshooting. For a full explanation of rule matching, see the routing section of the user guide.
Troubleshooting: narrow down protocol issues by symptom
On Home, select the entry you're testing. First note whether the failure occurs while establishing the connection, during the TLS handshake, or when opening the destination website, then check the connection log. A timeout only means that some step didn't complete in time; it doesn't by itself prove that the password is wrong or the protocol is unsupported. The steps below help isolate variables, but the same symptom can have different causes.
Hysteria2 times out while other entries work. What's different?
Check the Hysteria2 Address, Port, authentication, and SNI first, then see whether the current network allows UDP traffic to the server. Try the same configuration on another trusted network for comparison. A successful TCP connection doesn't prove that the UDP port for the same destination is reachable.
Trojan reports a certificate error. Should I just enable Allow Insecure?
First check on the entry's edit screen that SNI matches the certificate domain. Then check the device's date and time in system settings, and ask your provider to confirm the complete certificate chain. Allow Insecure weakens server identity verification and should not be enabled by default long term.
The VLESS UUID is correct. Why does the connection still fail?
Return to Home and open the entry. Check the transport, TLS, SNI, and any Host, Path, or other fields required by the server. UUID handles only part of authentication; it can't compensate for a mismatch in transport encapsulation or the security layer.
WireGuard completes a handshake, but some pages keep loading. What should I do?
Check whether Allowed IPs covers the destinations you expect, then check DNS and MTU. Don't increase MTU blindly; adjust it based on the server's recommendations and network path. Change one setting at a time and record the result to distinguish missing routes from packet-size issues.
Which protocol is always fastest? Can I just pick one?
Start by checking which protocols the server supports. Then compare connection success rate, response time, and sustained transfer under the same network conditions, to the same destination, and at roughly the same time of day. A protocol name can't tell you the quality of the connection, and a server that only supports Shadowsocks won't accept a Trojan connection.
Before sharing troubleshooting details, mask subscription URL tokens, authentication details, and keys. Include only the Type, transport, port, stage of failure, and what changed after switching networks. For further analysis, organize your notes using the connection troubleshooting section; this makes it easier to identify the cause than repeatedly changing every option.