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

First, distinguish protocols, transports, and routing rules

A node type describes how the client communicates with the server; a transport describes how that data is carried; routing rules decide which route a request takes. These layers are related but not interchangeable. For example, VLESS can use different transports. Selecting VLESS does not automatically determine the WebSocket path, TLS settings, or server port.

Get a subscription or the complete parameters from your provider, then keep the specified protocol combination. Changing a node’s Type from VMess to Trojan at the same address does not convert the server to Trojan. Even if both configurations use port 443, that only means the port is the same; it says nothing about their authentication methods or handshakes.

• Protocol layer: Shadowsocks, VMess, VLESS, Trojan, HTTP, SOCKS5, Hysteria2, and WireGuard each have their own authentication and communication requirements.
• Transport and security layers: TCP, UDP, WebSocket, QUIC, and TLS must be enabled and combined as specified by the server.
• Routing layer: Rules in Global Routing and Config select the route; they do not change the protocol a node uses.

Quick reference: fields for seven protocols

Use this table to check fields, not as a configuration template. Providers may combine authentication, transport, and certificate details in a single share link, so check each field after importing. Ports are shown for illustration only: Trojan commonly uses 443, and WireGuard deployments commonly use 51820/UDP. Neither is a required fixed value.

Shadowsocks, VMess, and VLESS: different authentication and encryption

Shadowsocks: match the encryption method

Shadowsocks requires the server address, port, encryption method, and password. The encryption method is not a speed setting; the client and server must use the same one. Copying the password but leaving a different method selected will usually prevent a successful connection. If the server also requires a plugin or additional transport, the client must support it and be configured accordingly. Matching the four basic fields may not be enough.

VMess: check the transport as well as the UUID

VMess uses a UUID for identification, while the transport and TLS settings affect how the connection is established. If your provider uses WebSocket, check the path and Host as well. TLS SNI and the WebSocket Host may serve different purposes; don’t swap them just because both are domain names. VMess also depends on accurate system time. If authentication fails, first enable automatic time setting on your device, then check the parameters.

VLESS: authentication is not encryption

VLESS does not encrypt content by itself; protection depends on the outer security layer and the complete setup. A valid UUID does not mean the connection is protected by TLS or that all server-required parameters are present. After importing VLESS, check TLS, transport, and any additional fields against your provider’s configuration. Don’t remove settings just because they’re unfamiliar.

Trojan, HTTP, and SOCKS5: the port alone doesn’t tell you whether TLS is configured correctly

Trojan typically relies on TLS for a secure connection, with a password for proxy authentication. The connection address can be an IP, but certificate validation may still require the correct domain and SNI. If the certificate name doesn’t match, check the domain and SNI provided by your service provider and your device’s time. Disabling certificate verification should not be treated as a routine fix.

HTTP and SOCKS5 are general-purpose proxy interfaces. A regular HTTP proxy connection is not encrypted by default. When you visit an HTTPS site, HTTP CONNECT can carry the site’s TLS connection, but that is separate from whether TLS is enabled between your client and the proxy. SOCKS5 does not encrypt content either, and a username and password are not a substitute for transport encryption.

• HTTP: Check whether a username and password are required, and whether the proxy connection itself uses TLS. Don’t confuse a website’s HTTPS with the proxy’s TLS setting.
• SOCKS5: TCP working does not mean UDP will work. UDP association requires support from the client, server, and network in between.
• Trojan: Even on port 443, the password and certificate settings must be correct. An open port only shows that a service responds; it does not confirm successful authentication.

Hysteria2 and WireGuard both use UDP, but for different purposes

Hysteria2 is based on QUIC, which runs over UDP. Its performance depends on UDP reachability, packet loss, congestion control, and bandwidth settings. If the network blocks UDP, an accessible TCP port on the same server does not mean Hysteria2 will work. Set bandwidth according to your actual connection and your provider’s guidance; a higher value does not automatically make it faster.

WireGuard is an encrypted IP tunnel, not a proxy protocol that uses a username and password to log in. Keep the Private Key on your device; the Peer Public Key identifies the remote peer. These keys are not interchangeable. Endpoint is the remote address and port; the tunnel address is the virtual address assigned to your device. Do not enter the public server IP as the tunnel address.

• Hysteria2: If authentication succeeds but the connection keeps timing out, first check whether the current network allows UDP traffic on the target port, then verify TLS and obfuscation settings.
• WireGuard: If the handshake gets a response but some pages hang, check routing, DNS, and MTU. A successful handshake alone does not prove the route to a website is working.
• For both: Switching between Wi-Fi and mobile data can help identify local network restrictions. Record the results for the same configuration, and avoid changing multiple settings at once.

Don’t assume the two are equivalent just because they use UDP. Hysteria2 is designed for proxy traffic, while WireGuard creates an IP tunnel; their import fields, address assignment, and routing boundaries differ. This guide does not rank speeds or present unmeasured network performance as a fixed percentage.

From Add Server to Home: check and test your configuration

The steps below assume you already have your own provider and configuration. A subscription can make it easier to update node parameters in one place; manual setup is useful for checking an individual entry. Subscription updates may overwrite remotely managed fields. Before troubleshooting manually, keep a copy of the original configuration and, if needed, make a separate entry to edit.

1. Confirm the type

   In Home, open an existing node’s edit screen, or tap the “+” in the upper-right corner to open Add Server and check Type. Select the type specified by your provider, such as Shadowsocks, VMess, VLESS, or Trojan. Don’t guess based on the node name.

2. Check authentication

   In Add Server, check Address, Port, and the authentication fields for the selected Type. Don’t include spaces in a UUID. Passwords are case-sensitive. Never share your WireGuard Private Key.

3. Check transport settings

   Check TLS, SNI, and any WebSocket path and Host required by the configuration. Only enter options explicitly provided by your service provider. Don’t copy fields from another node if they weren’t specified.

4. Test the connection

   After saving, return to Home, select the node, and connect. Temporarily use Global Routing → Proxy to test the same destination. Note any timeout, authentication failure, or certificate error, then restore your previous routing mode.

5. Check for updates

   If you use a subscription, go to Config → Subscribe, select the subscription entry, and update it. Then return to Home and check whether the nodes have changed. Get the subscription link from your provider; don’t use a client configuration file URL in place of a node subscription URL.

For example, https://example.com/sub?token=xxxx is an obvious placeholder showing that a subscription URL may contain query parameters. Real links often include access credentials. When sharing troubleshooting screenshots, hide the entire link and QR code, not just the server name.

Global Routing: distinguish protocol issues from rule issues

If the same node reaches a destination under Proxy but fails under Config, check the rules and policy routing first instead of rebuilding the node. Config routes traffic according to its rules; domains that don’t match a rule are not necessarily sent directly. The final behavior depends on subsequent rules and FINAL.

Scene in Global Routing applies behavior based on configured scenarios; it is not another proxy protocol. For troubleshooting, also check Settings → On Demand. If automatic connection conditions are enabled, a connection may start again after you disconnect manually. Record the original settings before temporarily turning them off, then restore them after testing.

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

The rules above illustrate the structure; they are not a complete configuration to use as-is. example.com and 192.0.2.0/24 are examples. PROXY must refer to a valid policy in your configuration. DOMAIN-SUFFIX matches a domain and its subdomains; IP-CIDR matches an address range; GEOIP checks an IP against a geographic database; FINAL handles requests not matched by earlier rules. Rules are generally evaluated in order. no-resolve prevents this IP rule from triggering a domain lookup.

Protocol selection and connection troubleshooting: FAQs