The protocol selected in Shadowrocket must match the configuration for a server you already have; changing Type cannot turn one service into another. This guide is for users who already have their own connection details or subscription and want to understand the fields in Add Server. It explains the differences between protocols, transports, and TLS, outlines the required details for each protocol, and provides a consistent way to determine whether an issue is caused by settings, the network, or routing rules.
1. Understand protocols, transports, and rules
Shadowrocket supports multiple connection protocols, but support does not mean that every combination of settings will work. The server must support the selected protocol, and the address, port, authentication details, and transport options entered in the app must match. This guide assumes you already have your own provider and subscription; it explains client fields but does not provide or recommend connection services.
Go to Home → tap “+” in the upper-right corner → Add Server. Type sets the protocol for the entry. Options such as TLS and WebSocket apply to other layers of the connection and should not be confused with Type. The three layers below answer: how authentication works, how data is transported, and which requests use the connection.
| Layer | Common settings | What to check |
|---|---|---|
| Protocol and authentication | Shadowsocks、VMess、VLESS、Trojan | Type, Password or UUID, and any additional protocol-specific fields |
| Transport and security | TCP、UDP、TLS、WebSocket、QUIC | The server's transport method, certificate name, path, and other settings |
| Traffic routing | Global Routing and rules in Config | Whether requests use DIRECT, a proxy policy, or REJECT |
For example, port 443 does not prove that an entry uses Trojan or TLS; it is simply where the server listens. A server may also use 8443 for TLS. Follow the existing configuration instead of guessing the protocol from the port. English terms below help identify settings; the fields and available combinations may vary, so check what the app actually displays.
2. How Shadowsocks, VMess, VLESS, and Trojan differ
These four connection types are often mistaken for interchangeable options simply because they use the same address. In practice, one domain can host different services, and a correct address alone does not guarantee successful authentication or transport. Check Type first, then credentials, and finally transport options to avoid changing unrelated settings.
| Protocol | Key characteristics | What to check in Add Server |
|---|---|---|
| Shadowsocks | Establishes a proxy connection using an agreed encryption method and password. TCP and UDP availability also depends on the configuration and server. | Address, Port, Method, and Password. If the existing configuration includes additional parameters such as obfuscation, those must match too. |
| VMess | Uses details such as a UUID for authentication; the transport layer can use different combinations depending on the server configuration. | Address, Port, UUID, encryption options, and any TLS, WebSocket, or other settings required by the existing configuration. |
| VLESS | Uses a UUID for authentication; the protocol itself does not encrypt the transported data, so security depends on the transport configuration. | Address, Port, UUID, and the TLS, transport, and other extension settings specified by the server. |
| Trojan | Typically uses password authentication over a TLS connection. The certificate name may differ from the connection address. | Address, Port, Password, and TLS settings—especially the SNI required by the server. |
UUID, Password, and TLS are not interchangeable
- Shadowsocks: Check Method and Password together. Copying only the password while keeping the Method from another entry may prevent the connection from working.
- VMess and VLESS: They are not interchangeable Types, even though both use UUIDs. If the existing configuration specifies WebSocket, check the path and Host as well as whether TLS is enabled.
- Trojan: Even with the correct Password, an incorrect SNI can cause the TLS handshake to fail. Check the domain and certificate details supplied by the server; disabling certificate verification is not a routine fix.
- TLS: The connection address locates the server, while SNI indicates the server name during the TLS handshake. They may be the same, or the existing configuration may specify different values.
Bottom line: check the complete configuration, not just the protocol name
If a connection fails, compare the entry's Type, port, credentials, TLS, and transport options with the original configuration. Don't just change Type or copy the SNI, Host, or path from another entry.
3. HTTP/SOCKS5, WireGuard, and Hysteria2
HTTP/SOCKS5 are proxy protocols, WireGuard is a key-based tunneling protocol, and Hysteria2 is based on QUIC. They differ in authentication, underlying transport, and troubleshooting. No protocol is always the fastest regardless of server conditions and your local network.
| Type | Transport characteristics | Details you need |
|---|---|---|
| HTTP/SOCKS5 | HTTP proxies commonly use CONNECT to establish a TCP tunnel. SOCKS5 can negotiate TCP and also defines a UDP relay mechanism; actual support depends on both ends' configuration. | Address, port, and any Username and Password required by the server. Check separately whether the HTTP proxy connection itself uses TLS. |
| WireGuard | Carries an encrypted tunnel over UDP and uses key-based authentication rather than standard account credentials. | Your Private Key, tunnel address, the peer's Public Key, Endpoint, and any configured routing ranges or other parameters. |
| Hysteria2 | Based on QUIC, which uses UDP as its underlying transport, and uses TLS. The network must allow the required UDP traffic. | Address, port, authentication details, and SNI. If the server uses obfuscation, you'll also need the matching obfuscation settings. |
Assess behavior based on protocol characteristics, not the name
- HTTP/SOCKS5: If the server requires authentication, don't leave Username or Password blank. A SOCKS5 label alone does not guarantee UDP support; both the server and client must be configured for it.
- WireGuard: Don't enter your Private Key as the peer's Public Key. The tunnel address is not the server address; the host and port in Endpoint identify the peer.
- Hysteria2: Being able to open a regular webpage over TCP does not prove that UDP is available. If the current network restricts UDP, repeatedly changing the password won't fix the underlying transport issue.
- Protect your credentials: Treat UUIDs, Passwords, Private Keys, and full subscription URLs as sensitive information. When troubleshooting, record whether fields match, but don't share their complete values.
Bandwidth, packet loss, server load, and network policies all affect performance. A single Connectivity Test cannot establish protocol performance unless tests use the same network, time window, and comparable server conditions. Lower latency does not necessarily mean faster sustained download speeds.
4. Add a server and check existing connection details
Keep all details from the existing configuration whenever possible. Manual setup is suitable for entries with a small number of clearly sourced settings; a subscription can manage a group of entries you already have. Subscribe is a way to import and maintain connection details, not a transport protocol like Shadowsocks or Trojan. Each entry in a subscription still has its own Type.
-
Gather the connection details
Get the protocol, address, port, and authentication details from your existing configuration. For VMess or VLESS, also check whether TLS, the transport method, Host, and path have specified values.
-
Open Add Server
Go to Home → tap “+” in the upper-right corner → Add Server → Type, then select the protocol that matches the original details. Don't guess from the address name or port.
-
Enter the details and save
Enter Address, Port, and the fields required for that Type. Check that copied values have no extra spaces at either end. After saving, return to Home and make sure the new entry is selected.
-
Set up a subscription
If you already have a subscription, go to Home → “+” → Type → Subscribe, enter your own URL, and save. Then update the subscription from Home. Updating refreshes entries from the remote content, so keep a separate record of any parameters you changed manually.
-
Test the connection
Run Connectivity Test from Home, then enable the connection and visit the destination you need. Record separately whether the test completed, the connection was established, and the destination was reachable; these are three different results.
5. Global Routing does not change an entry's protocol
The protocol determines how a connection is established; Global Routing determines which path requests take. Switching to Proxy does not turn Shadowsocks into Trojan, and switching to Config won't fix an incorrect UUID. Troubleshoot whether the entry works separately from whether a destination matches the expected rule.
Config: follow the rules in your configuration
RecommendedUse the rules in the current configuration to select a policy. Recommended for everyday use with an existing configuration whose rules you've checked. The resulting route depends on the matching rule and its policy; it does not mean all other traffic will always use DIRECT.
Best for: routing traffic by destination when rules are verified
Proxy: check the proxy route
Route requests handled by the client through the proxy. This can temporarily isolate rule-matching issues. If a destination becomes reachable after switching, check the policies and rules in the original configuration rather than assuming the protocol is at fault.
Best for: briefly troubleshooting routing and policy selection
Direct: check the direct route
Route requests handled by the client directly. If a destination is reachable this way, it does not prove that the newly added proxy entry has authenticated successfully or can transfer data.
Best for: comparing against direct access on your current network
Scene in Global Routing applies settings for different situations. When checking results, confirm which scene is active and what settings it uses. Settings → On Demand controls connections triggered by conditions; it does not convert one protocol to another. If a connection starts automatically, check this setting separately.
Checking rules in Config mode
In Config, check which configuration is currently in use. Rules are generally evaluated from top to bottom; when a rule matches, its associated policy is applied. FINAL handles requests that did not match an earlier rule. The examples below are rule text, not server settings or app screens.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYDOMAIN-SUFFIXmatches a specified domain suffix and its subdomains; it does not select a protocol type.IP-CIDRmatches a destination IP range. The example uses a documentation address range, andno-resolvemeans this rule does not trigger an additional DNS lookup.GEOIPchecks the destination IP against geographic location data; a webpage's language alone cannot tell you whether the rule matches.PROXY,DIRECT, andREJECTare policy keywords for proxying, direct access, and rejecting traffic, respectively. Routing policies and Type are separate settings.
6. Common issues after adding a protocol
Change only one category of settings at a time, and keep a record of the original values. The answers below focus on using the client: changing protocols is no substitute for checking the configuration, and a single timeout does not automatically mean the server is at fault.
Why won't the connection work after I change the Type to VLESS?
Go to Home, open the entry's edit screen, and check Type first. The server must actually support VLESS and provide the matching UUID and transport settings; sharing the same address is not enough. If your original details specify VMess, switch back to VMess and check each existing setting.
Why does Trojan still fail if the password is correct?
In the entry's edit screen, check Address, Port, and TLS settings—especially whether SNI matches the existing configuration. Then check the device's Settings → General → Date & Time. A significantly incorrect system time can affect certificate validity checks; don't simply disable certificate verification.
Why does Hysteria2 time out when regular websites load?
First, make sure the server address, UDP port, and authentication details match your existing configuration. Then test again on another network you're authorized to use. TCP access to regular websites does not prove that UDP required by QUIC is reachable. Record what happens on each network separately.
Why did my manual changes disappear after updating a subscription?
Go to Home and compare the same entry before and after the update. Subscription updates reload remote content, so check the settings at the source of your existing configuration. To troubleshoot locally, create a separate manual entry and record the differences rather than assuming a temporary change has fixed the remote configuration.
Does a Connectivity Test result mean my settings are correct?
Not necessarily. Check which test method is in use, then enable the connection and visit the destination you need. If only some destinations fail, check Home → Global Routing and the matching rules in Config. A test result alone cannot confirm that every protocol feature, UDP relay, or website will work.