Shadowrocket Protocols: Shadowsocks, VMess, VLESS, Trojan & Hysteria2 Explained

At a glance

Shadowrocket supports several connection protocols. When adding a server, use the details provided by your service provider rather than guessing based on a protocol’s name or expected speed. This guide is for users who already have service details: identify the protocol, authentication and transport; check the corresponding fields in Add Server; then distinguish connection issues from Global Routing rule issues. Get subscription links from your service provider.

Supported protocols: check authentication and transport requirements first

Shadowsocks, VMess, VLESS, Trojan, HTTP, SOCKS5, WireGuard and Hysteria2 each have their own configuration. They are not different names for the same set of settings: the client’s Type must match the protocol used by the server. Changing an existing entry’s Type from Shadowsocks to Trojan will not change the server’s protocol or make the connection faster.

Common protocol settings to check
Protocol	Key settings to check	Common point of confusion
Shadowsocks	Address, Port, Password and encryption method	The connection can still fail if the encryption method does not match, even when the password is correct
VMess	Address, Port, UUID, encryption settings and transport parameters	A UUID is not a regular account password; the transport must also match
VLESS	Address, Port, UUID, and the transport and security settings required by the server	The protocol itself does not encrypt the payload, so the associated security layer still matters
Trojan	Address, Port, Password, TLS and server name	The address used to connect and the name used for certificate validation may differ
HTTP / SOCKS5	Address, Port, and any username and password required by the server	HTTP and SOCKS5 use different handshakes and are not interchangeable
WireGuard	Private Key, Peer public key, Endpoint, tunnel addresses and routing parameters	An address and password alone are not enough to configure it
Hysteria2	Address, Port, authentication details, TLS and bandwidth-related settings	Uses QUIC and requires the network to allow the relevant UDP traffic

The fields shown in Add Server vary with Type, and field groups and labels may differ between app versions. The table describes the settings to check; it does not mean every Type displays the same fields. If the service details do not include an advanced option, keep the imported value rather than applying settings from another protocol.

Bottom line: match the supplied settings before testing the connection

If your subscription imports successfully, start by connecting with the imported configuration. Change a field only after confirming it differs from your provider’s details, and keep the original entry for comparison.

Shadowsocks, VMess, VLESS and Trojan: key differences

For Shadowsocks, check the encryption method and Password. VMess and VLESS usually identify users with a UUID and may use different transport options. Trojan uses password authentication with TLS. A protocol name describes only part of the connection: establishing a connection also depends on the server’s open port, transport settings and certificate requirements.

Shadowsocks: The encryption method must match the server; a similarly named option is not a substitute. Keep any plugin or other additional settings included in the service details.
VMess: In addition to the UUID, check the server’s encryption and transport settings. An incorrect device clock can also affect authentication, so enable automatic time setting in the system settings.
VLESS: The UUID identifies the user; it does not automatically encrypt the connection. Configure TLS, any other security mechanisms and transport settings according to the server details.
Trojan: Don’t check only the Password. The server name, certificate validity and device clock can also affect the TLS handshake.

Don’t mix up Address, SNI and Host

Address is the server address the client connects to. SNI indicates the server name during the TLS handshake. With transports such as WebSocket, Host may be part of the application-layer request. These values may be the same in some configurations and different in others. Don’t change them all to the same IP just to make them match.

For WebSocket transport, check Path and Host as well. Slashes and capitalization in Path may matter. If the handshake fails, check these fields first instead of disabling certificate validation. Disabling validation weakens authentication and is not a routine fix.

Hysteria2, WireGuard and HTTP/SOCKS5: what to know

Hysteria2 and WireGuard both involve UDP, but they serve different purposes and use different configurations. HTTP/SOCKS5 are proxy protocols; choosing one of these Types does not automatically encrypt the entire connection. First confirm what the server supports, then check whether the current network allows the required traffic.

Hysteria2: This QUIC-based transport generally requires UDP connectivity. If your provider specifies authentication details, obfuscation or bandwidth settings, check them against the supplied values. Increasing the bandwidth setting does not increase the actual capacity of the connection. If UDP is blocked, changing the authentication password alone will not fix a timeout.
WireGuard: WireGuard creates a tunnel using keys and Peer settings. The local Private Key and the remote Peer’s Public Key are different and cannot be swapped. Endpoint specifies the remote address and port; tunnel addresses and routing ranges determine how traffic is handled inside the tunnel. For manual setup, get the complete configuration rather than copying only Endpoint.
HTTP / SOCKS5: Use these types to connect to the corresponding proxy service. Whether authentication is required depends on the server. Standard HTTP proxies and SOCKS5 do not provide encryption for the entire connection; confirm separately whether an HTTP proxy uses TLS. SOCKS5 UDP support also depends on the server and network, so working TCP does not guarantee working UDP.

Don’t assume a protocol is faster just because it has lower latency. Short connection tests, sustained downloads, video playback and UDP applications create different loads. Server load, packet loss, routing paths and provider speed limits all affect results. This guide does not rank protocols without specifying test conditions or treat any protocol as the default for every network.

Add Server setup: four checks using your service details

Manual setup is useful when you have the complete connection details. If you only have a subscription link, import it using Subscribe; don’t enter the subscription URL as a protocol’s Address. A subscription is a way to obtain configuration details, while VMess and Trojan are protocols used by individual server entries.

Check your details

Get the protocol name, server address, port and authentication details from your service provider. If they provide a subscription link, import it as a subscription. If they provide individual connection details, add the server manually.
Choose the type

Go to Home → tap “+” in the top-right corner → Add Server → Type, then select the protocol listed in your service details. To add a subscription, select Subscribe, enter your subscription link and save. Don’t infer the Type from the port number.
Enter each setting

Enter Address, Port and the protocol’s authentication details, then check any additional settings such as TLS, SNI, transport and Path. If the supplied port is 8443, enter 8443; don’t change it to 443 out of habit.
Save and test

After saving, return to Home, select the entry and connect. The first time you connect, follow the system prompt to allow the VPN configuration. Check that the connection is established, then test a webpage you actually need to access. One latency result does not confirm that everything is working.

Subscription updates usually retrieve the entries provided by the server and may overwrite manual changes. For comparison tests, keep the original entry or save a separate test entry, and note which fields you changed. For subscription import and ongoing management, see the subscription guide. For update issues, see Subscribe update guide.

Protocols and Global Routing: connection type is not traffic routing

The protocol determines how the client connects to the selected server; Global Routing determines how traffic is routed. Even with correct Trojan or Hysteria2 settings, traffic will not go through the selected proxy as expected when the mode is Direct. When troubleshooting, first check Global Routing on Home, then check the active configuration in Config.

Config

Recommended

Traffic is handled according to the rules and policies in the current configuration. Only requests matched to a proxy policy use the corresponding connection. Direct and rejected traffic are also determined by the configuration; unmatched requests are not necessarily sent directly.

Best for: everyday traffic routing with a verified rules configuration

Proxy

Traffic handled by the client is routed through the proxy, which can help temporarily rule out standard routing rules. After switching, still check that the selected server is correct.

Best for: temporarily testing a server connection and separating rule issues from connection issues

Direct

Traffic handled by the client is routed directly. This mode does not test whether a proxy protocol works.

Best for: comparing with a direct connection on your local network

If you use Scene, first check which settings the current scene actually applies; Scene is not a connection protocol. Settings → On Demand controls when connections start based on conditions; it does not convert an entry from VMess to VLESS. Before troubleshooting, note the relevant toggle states so automatic connection behavior does not affect your observations.

DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

These examples explain rule syntax only: DOMAIN-SUFFIX matches domain suffixes, IP-CIDR matches IP ranges, GEOIP matches by IP geolocation, and FINAL handles traffic not matched by an earlier rule. The example range 192.0.2.0/24 is reserved for documentation. Check the actual configuration from top to bottom; processing stops at the first match. Don’t reorder existing rules just to group them by type.

FAQ: why won’t it connect when the protocol is correct?

Why does changing the Type fail, even when both use port 443?

A port is where a service listens, not an identifier for its protocol. Go to Home, open the entry for editing, restore the Type specified by your service details, and check the authentication and transport settings. Trojan, VMess and VLESS may all use 443, but their handshakes and authentication methods differ.

Latency test succeeds, but webpages won’t load. Should I re-enter the password?

First, check what the latency test measures; some tests confirm network-layer reachability without fully testing a request. Then check Global Routing and the selected entry on Home, followed by DNS and rule matching. Temporarily switch to Proxy for comparison, then restore the original mode. For more troubleshooting steps, see connection troubleshooting.

Hysteria2 times out on Wi-Fi but connects over cellular. Why?

Keep the same entry and settings, and repeat the test on each network. If the difference persists, check whether the original network restricts UDP, along with its gateway policies and routing path. Ask your service provider to confirm the server is working. Don’t change the port, password and bandwidth settings at the same time, or you won’t know which change mattered.

Can I change VLESS in a subscription directly to VMess?

Changing only the Type is not enough. Each protocol requires its corresponding server configuration; even a matching UUID does not mean they are compatible. Update the subscription first. If you need connection details for another protocol, get them from your service provider. Change only one field at a time, and only when you have confirmed it is incorrect, to avoid breaking a working entry.

Troubleshoot in this order: “Are the details complete? → Does Type match? → Do authentication and transport match? → Is the network reachable? → Are routing and DNS behaving as expected?” When reporting an issue, note the network type, selected protocol and whether the error occurs during connection or webpage access. Remove sensitive details. This is more useful for diagnosis than simply saying “the protocol is unstable.”