Shadowrocket supports the seven connection protocol categories covered here, but changing Type does not convert an existing server to another protocol. This guide is for users who already have their own provider settings or subscription: identify the type in the table, check authentication, transport, and TLS separately, then distinguish connection issues from routing issues. The seven categories are this article’s classification, not the total number of types available in the app.
Seven protocols and their Add Server types
Check the protocol specified in your existing configuration, then go to Home → “+” in the upper-right corner → Add Server → Type and select the matching option. Don’t guess based on the port or server name: a service on port 443 could use different protocols, and may use TCP or UDP. Type determines how the client communicates with the server, so it must match the server configuration.
| Protocol category | Matching Type | Key features | Check first |
|---|---|---|---|
| Shadowsocks | Shadowsocks |
Establishes a proxy connection with a password and specified encryption method; both ends must use the same method. | Address, Port, Password, Method, and any plugin parameters required by the existing configuration. |
| VMess | VMess |
Identifies users with a UUID and can use different transport methods; protocol authentication and TLS are separate layers. | UUID, encryption options, transport method, and related settings such as TLS, Host, and Path. |
| VLESS | VLESS |
Uses UUID authentication; the protocol itself does not encrypt payloads. Link protection depends on the configured transport. | UUID, transport method, TLS, and any other handshake parameters required by the configuration. |
| Trojan | Trojan |
Typically connects over TLS and authenticates with a Password. | Password, Port, TLS service name, and certificate verification settings. |
| HTTP / SOCKS5 | HTTP / SOCKS5 |
Two distinct proxy protocols. Some servers require a username and password; the Type options are not interchangeable. | The protocol actually used by the server, Address, Port, authentication requirements, and whether TLS is explicitly provided. |
| WireGuard | WireGuard |
Creates a UDP-based tunnel using keys and peer settings, rather than the password model used by conventional proxies. | Local private key, peer public key, Endpoint, tunnel addresses, and routing ranges. |
| Hysteria2 | Hysteria2 |
Uses QUIC over UDP and requires matching authentication, TLS, and any optional obfuscation settings. | Address, Port, authentication value, TLS service name, and whether the UDP path is available. |
HTTP and SOCKS5 are grouped together here for a quick overview, but must be selected separately under Type. Hysteria2 also cannot be substituted for another protocol just because their names look similar. The available fields and combinations depend on the selected Type’s editing screen in the app.
Takeaway: choose Type to match your settings
If your existing configuration specifies VLESS, select VLESS and check its associated transport settings. Don’t switch to a more familiar protocol, and don’t assume the example port 443 is standard for every server.
Check authentication, transport, and TLS separately
A protocol name describes only part of a connection. Authentication specifies which credentials to use; transport determines how data is carried; TLS settings cover the handshake and certificate verification. Checking these layers separately can prevent repeated changes to unrelated fields when, for example, the UUID is correct but the connection still fails, or the address resolves but the handshake does not complete.
- Authentication: Shadowsocks Password must be paired with the correct Method. Copy VMess and VLESS UUIDs in full. A Trojan Password is not a UUID, and a WireGuard private key does not belong in a password field. Values may all look like strings of characters, but they are not interchangeable.
- Transport: If your settings specify WebSocket, check the corresponding transport option, Host, and Path. Preserve the leading slash and capitalization in Path exactly as provided. Address, Port, and UUID alone are not enough if additional parameters are required.
- TLS: The connection address may be an IP address or a domain name. SNI specifies the server name during the TLS handshake and does not always have to match the connection address; use the value in your existing configuration. WebSocket Host and TLS SNI belong to different layers and should not be assumed to match.
- Network: WireGuard and Hysteria2 rely on UDP. A working TCP connection does not prove that UDP is available on the same network; check the actual connection result for the protocol in use.
VLESS does not encrypt payloads by itself, but that does not mean every VLESS connection sends data in plaintext; the actual link also depends on settings such as TLS. Conversely, seeing HTTP or SOCKS5 does not prove that the entire connection is encrypted. Check the transport and security settings that are actually enabled, not just the protocol label.
Add and test using your existing settings
Manual setup is useful for checking settings one by one; importing a subscription adds entries in bulk from a configuration you already have. Either way, the entries must match the server’s actual settings. This guide covers using existing configurations only; it does not provide, sell, or recommend servers, subscriptions, or providers.
-
Check your settings
First confirm the protocol, server address, port, and authentication value. Then check TLS, transport, and any additional parameters. Use the port specified in your existing configuration; don’t assume 443 is the default.
-
Select a type
Go to Home → “+” in the upper-right corner → Add Server → Type. Select the protocol that exactly matches your existing settings, then return to the editing screen and fill in the corresponding fields.
-
Enter settings and save
Fill in Address, Port, and the authentication fields. If TLS or additional transport settings are required, check the corresponding options. After saving, return to Home and select the entry you just added.
-
Test the connection
On Home, check Global Routing, run Connectivity Test, and open a specific test destination. Record the destination, network, and error message. Change one setting at a time.
If you already have a subscription URL, go to Home → “+” in the upper-right corner → Type → Subscribe, enter your own subscription URL, and save. Then update that subscription from Home. After updating, check the selected entry again, as the remote configuration may have changed its address, port, or authentication details. Editing an individual entry and updating a subscription are different actions; a later update may overwrite local changes.
- A successful save only means the entry was stored; it does not mean the server has authenticated successfully.
- A latency test reflects only the result of that test method; it does not mean every destination is accessible.
- Before making changes, keep the original settings and adjust only one value at a time so you can identify what caused the change.
Protocols and Global Routing serve different purposes
The protocol determines how a connection is established; Global Routing determines how requests are handled by direct or proxy policies. Selecting Hysteria2 does not mean every request will use it. Global Routing on Home includes Proxy, Direct, Config, and Scene. Scene is for scene-based configuration—not an eighth connection protocol or an automatic speed-test result.
Config
RecommendedProcesses requests according to the active Config rules. The action for a matching request depends on the policy specified by the rule. Requests not matched by earlier rules are handled by fallback settings such as FINAL; don’t assume they will all go direct.
Best for: everyday use after checking your Config rules
Proxy
Routes intercepted requests through the proxy. Use this to compare results with Config and narrow down issues related to rule routing; it does not bypass server authentication or network conditions.
Best for: temporarily comparing proxy connection and rule-routing results
Direct
Processes requests directly. If a webpage loads in this mode, that does not prove the selected proxy entry works. To test a protocol connection, first make sure you know which path you are testing.
Best for: comparing direct access on your current network
In Config, DOMAIN-SUFFIX matches domain suffixes, IP-CIDR matches IP ranges, GEOIP matches categories in an IP geolocation database, and FINAL handles requests not matched by earlier rules. These are rule keywords, not protocol types in Add Server. When troubleshooting, first check which rule matched the request, then check which connection entry its policy uses.
Settings → On Demand controls when connections are triggered by conditions; it does not convert one protocol to another. During troubleshooting, note whether On Demand is enabled so an automatic connection or reconnection is not mistaken for a protocol change. See On Demand settings for details.
Common questions and troubleshooting steps
Start with your existing settings. Keep other options unchanged while you recheck Type, authentication, and transport, then check Global Routing and the destination request. Don’t keep switching protocols instead of finding the cause.
Can I change the protocol while keeping the same address and port?
Changing Type in the client alone cannot convert a server. Go to Home → the entry’s editing screen and make sure Type matches your existing settings. You can use a different protocol only if the server actually provides it, along with the corresponding settings. The same address and port do not prove that the server supports both protocols.
Why can’t I swap VMess and VLESS if both use a UUID?
A UUID is a credential format; it does not mean the handshake protocols are the same. Check Type first, then check transport, TLS, and Path. If the original configuration specifies VLESS, don’t copy the UUID into VMess and keep trying. Return to the original type and check for missing settings.
Why does Hysteria2 fail on Wi-Fi but connect on another network?
Test the same entry against the same destination on both networks and keep the error messages. Hysteria2 uses UDP, so differences in the network path may affect the connection. Then check the port, authentication, SNI, and any optional obfuscation settings. This alone does not establish that the server is at fault or that one protocol is always faster.
Why did an entry that used to work fail after a subscription update?
On Home, confirm that the expected entry is still selected, then open its editing screen and check the updated Type, Address, Port, and authentication details. Don’t simply copy the old password into the new entry. Compare it with the current settings you have and check whether Global Routing changed as well.
Does a connected status mean the protocol is configured correctly?
No. System connection status, server authentication, and access to a destination are separate steps. On Home, check Global Routing, run Connectivity Test, and test a specific destination. Only a real request that uses the expected entry and returns a result confirms that this particular path works; it does not prove that every network or destination will work.
Choose a protocol that matches the existing server configuration; don’t rank protocols by name. For help understanding fields, see the protocol glossary. To check the current configuration file and diagnostic options, see Config settings. Record protocols, transport, and rules separately so you have a clear reference for future updates and troubleshooting.