This guide is for users who already have server parameters or a subscription URL from their own provider but are unsure which Type to choose under Add Server. You will learn to identify the core fields for Shadowsocks, VMess, VLESS, Trojan, Hysteria2, and WireGuard, then verify the address, port, credentials, transport, and TLS details.
First decide between subscription import and manual entry
The protocol types in Shadowrocket are not names for network routes. If your provider’s configuration says Shadowsocks, VMess, VLESS, Trojan, Hysteria2, or WireGuard, tap the “+” in the top-right corner of Home to open Add Server, then set Type to the matching protocol. Do not guess from the port number: 443 can be used by several configurations and does not identify the type.
If you already have a subscription URL, import it through Subscribe first. The subscription can populate the protocol type, server address, and transport parameters in the relevant entry, reducing errors with capitalization, paths, or certificate names compared with manual transcription. Manual entry is better when you have one complete set of parameters, need to verify a specific field, or have been explicitly told to enter the values yourself.
Import with Subscribe
RecommendedCreates server entries from an existing subscription and lets you refresh them from the same source later. Protocol and transport fields are usually included with each entry.
Best for: a complete subscription URL or multiple servers to maintain
Enter manually with Add Server
Enter Address, Port, Password, or UUID one by one, then verify additional settings such as Transport, TLS, and SNI.
Best for: one complete set of parameters or checking field mappings
Config file
Config mainly carries rules, DNS, and routing settings. It cannot replace the connection parameters required by a server protocol.
Best for: managing routing rules, not filling in missing server credentials
Confirm the source fields
Start with the provider’s documentation and locate the exact protocol name, Address, Port, and authentication details. If the protocol is not identified, ask the original configuration source instead of inferring it from the port.
Open the add-server screen
Open Home, tap the “+” in the top-right corner, and select Add Server. For a subscription import, set Type to Subscribe.
Paste the existing subscription
Enter your own URL in URL. It may look like
https://example.com/sub?token=xxxx; this is a dummy value and cannot be used to connect.Select the matching protocol
For manual entry, select the protocol explicitly named in the parameter sheet under Type, then fill in the fields shown for that type.
Save and test
After saving, return to Home, select the generated server entry, and use Connectivity Test to check reachability.
Common fields shared across the six protocols
The authentication method differs by protocol, but the verification order can stay the same: check the server address and port first, then the password or key, and finally the transport and TLS settings. Address should contain only a hostname or IP address—not https://, a path, or a port. Port must be the integer provided by the configuration source. Values such as 443 and 8443 are only examples; no single port works for every server.
| Field hierarchy | Common interface values | How to verify |
|---|---|---|
| Connection target | Address、Port | Compare the hostname and port character by character. Make sure there are no spaces, protocol prefixes, or web paths. |
| Authentication | Password、UUID、Private Key | Fill these in according to the protocol. They serve different purposes and cannot substitute for one another; do not change their capitalization. |
| Transport settings | TCP、WebSocket、gRPC、QUIC | Select only the Transport explicitly listed in the parameter sheet, then fill in Host, Path, or Service Name as required. |
| Security settings | TLS、SNI、Public Key | The domain, certificate name, and key must come from the same configuration; do not copy them from another server. |
Takeaway: identify the protocol before the port
Seeing 443 confirms only the destination port; it does not tell you to choose Trojan, VLESS, or another Type. Set the Add Server Type according to the protocol label supplied by the provider, then verify that protocol’s specific authentication fields.
Mapping fields for Shadowsocks, VMess, and VLESS
Shadowsocks: Password and Method must match
A Shadowsocks configuration usually includes Address, Port, Password, and Method. Method is the encryption method; the source may specify an AEAD method by name. The option in Shadowrocket must match the original configuration exactly. If Method is wrong, the port may still respond even though authentication cannot complete.
- Address: The server hostname or IP address.
- Port: The port actually listening on the server, not a web-service port.
- Password: Case-sensitive; check for spaces at both ends after pasting.
- Method: Must match the server configuration; do not substitute a similar-looking name.
- Plugin: Fill this in only when the parameter sheet explicitly provides a plugin and its options.
VMess: verify Transport in addition to UUID
VMess typically uses a UUID as the user identifier. A configuration may also include an alter ID, security options, TLS, and Transport. With WebSocket, also verify Path and Host; if another Transport is specified, open its corresponding fields and enter the required values. Copying only the UUID while omitting Path can leave Address and Port reachable but cause the connection test to fail.
- UUID: Preserve the hyphens exactly; do not convert it into an ordinary password.
- Transport: Select TCP, WebSocket, or the explicitly specified method.
- Host and Path: Common WebSocket fields; an empty value and the root path
/are not always equivalent. - TLS and SNI: Verify both when required by the configuration; do not enable TLS while omitting the server name.
VLESS: enter UUID, Flow, and the security layer separately
VLESS also commonly uses a UUID, but a VMess entry cannot be reused simply by renaming it. Map VLESS Flow, Transport, and the security layer to the original parameters again. Some configurations do not use Flow; in that case, leave the value empty as specified by the source. If Flow is explicitly provided, select the matching option. With Reality, you may also see Public Key, Short ID, and Server Name; all of these values must belong to the same server configuration.
- UUID: Enter it as the user identifier; do not mix its type with a VMess entry.
- Flow: Select it only when explicitly provided by the source; do not add a default value yourself.
- Transport: TCP, WebSocket, gRPC, and other options must match the server.
- Reality parameters: Verify Public Key, Short ID, and Server Name as one set.
How to identify Trojan, Hysteria2, and WireGuard
Trojan: focus on Password, TLS, and SNI
The core credential for a Trojan entry is usually Password, often combined with TLS. SNI or Server Name identifies the hostname covered by the certificate. It may match Address or may be specified separately by the configuration source. If the certificate name is wrong, the port may be reachable while the connection remains stuck during the handshake.
- Password: Copy the complete authentication string.
- TLS: Enable it according to the original configuration; do not infer it just because the port is
443. - SNI: Use the domain supplied by the configuration, not an arbitrary website address.
- Transport: If the configuration includes WebSocket or gRPC, also enter the corresponding Path, Host, or Service Name.
Hysteria2: based on QUIC, so check UDP reachability
Hysteria2 usually operates over QUIC. The connection target still consists of Address and Port, while authentication is commonly provided as Password. The configuration may also include SNI, an Obfuscation type, and an Obfuscation Password. Because it relies on UDP, the result can depend on whether the current network allows the relevant UDP port. Different results on Wi-Fi and cellular networks do not necessarily mean the parameters changed.
- Address and Port: The port must match the UDP port open on the server.
- Password: Must match the server’s authentication value.
- SNI: Enter the server name specified by the certificate configuration.
- Obfuscation: Enable it only when the source provides both a type and password; the two values must be used together.
WireGuard: understand the Interface and Peer sections
WireGuard uses a different field structure from the account-and-password protocols above. Divide the parameters into two groups: the local Interface includes Private Key and Address, while the remote Peer includes Public Key, Endpoint, and Allowed IPs. Endpoint usually consists of a hostname or IP plus a port. Allowed IPs determines which destinations are sent to that Peer; it is not the same as a Shadowrocket DOMAIN-SUFFIX rule.
- Private Key: The local interface private key; do not enter the server’s Public Key.
- Address: The address assigned to the tunnel interface, usually with a CIDR prefix length.
- Public Key: The remote Peer’s public key.
- Endpoint: The peer address and port;
vpn.example.com:51820is shown only as a format example. - Allowed IPs: Enter the ranges exactly as provided in the existing configuration.
- Reserved: If the configuration source provides three values, preserve their order.
Takeaway: identify the structure from the authentication fields
Password is common in Shadowsocks, Trojan, and Hysteria2; UUID is common in VMess and VLESS; Private Key and Peer Public Key point to WireGuard. Authentication fields are useful for verification only—the original configuration label remains authoritative for Type.
Why Transport, TLS, and the port must not be mixed up
The protocol defines authentication and data encapsulation, Transport determines how the data is carried, and TLS handles the encrypted handshake and server identity where applicable. These layers can be combined, so the same VLESS Type may use different Transports, and the same WebSocket transport may appear in different protocol entries. Once Add Server displays additional fields, continue comparing them with the complete provider parameters; do not stop after identifying the protocol.
WebSocket Path usually begins with /, while Host is the host field in the handshake request. gRPC commonly uses Service Name, and TLS commonly uses SNI. They all look like text values, but they are sent in different places. Putting Service Name in Path or copying Address directly into SNI works only when the original configuration happens to use the same value.
| Configuration item | What it controls | Common symptoms when incorrect |
|---|---|---|
| Port | Identify the server listening endpoint | Timeout, connection refused, or a connection to an unrelated service. |
| Transport | Determine the transport: TCP, WebSocket, gRPC, QUIC, or another method | The port is reachable, but the protocol handshake cannot complete. |
| Path / Service Name | Identify the relevant WebSocket path or gRPC service | The connection drops quickly because the server cannot match the endpoint. |
| TLS / SNI | Establish TLS and match the server name | Certificate name mismatch or handshake failure. |
| UDP | Carry Hysteria2, WireGuard, and related traffic | The same parameters behave differently on different access networks. |
Protocol connectivity and Global Routing are separate
The server protocol establishes the connection; Global Routing determines how traffic is handled after the connection is available. Config reads the active rule configuration; Proxy sends traffic through the selected server; Direct connects to the destination directly; Scene applies the settings for a given scenario. A successful server-entry test does not mean Global Routing will send every request through that entry.
In Config mode, Shadowrocket matches rules from top to bottom. Common keywords include DOMAIN-SUFFIX, GEOIP, IP-CIDR, and FINAL. A specific rule earlier in the list matches first, while FINAL handles requests that matched nothing above it. The examples below show rule syntax only; the domains and addresses are documentation examples:
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY- DOMAIN-SUFFIX: Matches by domain suffix, covering the specified domain and its subdomains.
- IP-CIDR: Matches an IPv4 address range;
192.0.2.0/24is a documentation-only example network. - GEOIP: Matches the result of an IP geolocation database, not the text of the domain name.
- FINAL: Receives requests that matched none of the preceding rules and is usually placed at the end.
Config
RecommendedRules in Config are matched one by one, allowing different destinations to use policies such as Proxy or Direct.
Best for: a verified rule configuration and daily per-destination routing
Proxy
Uses the currently selected server for all traffic, helping determine whether a problem is caused by a rule not matching.
Best for: temporarily eliminating the effect of rule-based routing
Direct
Requests connect directly to the destination without forwarding through the selected server.
Best for: confirming whether the local network can reach the destination by itself
Scene
Switches handling according to the configured network scenario; the result depends on the saved Scene conditions.
Best for: configurations that distinguish between different network environments
Takeaway: fix the routing mode before testing the protocol
When troubleshooting a new server, note the current Global Routing first, then use Proxy to test the entry itself. After confirming that the entry works, restore Config and continue checking the match order for DOMAIN-SUFFIX, IP-CIDR, and FINAL.
Troubleshoot failures by field layer
Different error types call for different starting points. If Connectivity Test immediately times out, check Address, Port, and reachability on the current network. If it fails quickly while the port appears responsive, check Type, Password, UUID, Method, and Transport. For TLS handshake issues, focus on SNI, device time, and the certificate relationship. Change one field at a time so you can identify which correction made a difference.
Verify Type
Return to the Add Server editor and confirm that Type matches the protocol explicitly named in the original configuration: Shadowsocks, VMess, VLESS, Trojan, Hysteria2, or WireGuard.
Check Address and Port
Remove extra protocol prefixes, paths, and spaces from Address, and confirm that Port was not altered by the browser or input method.
Check authentication
Compare Password, UUID, Method, Private Key, or Public Key character by character, paying particular attention to capitalization and hyphens.
Check transport and security
Verify Transport, Host, Path, Service Name, TLS, SNI, Flow, and the relevant Reality values.
Test with a fixed routing mode
Record the original settings, temporarily set Global Routing to Proxy, and use Connectivity Test to determine whether rule-based routing caused the difference. Restore the original mode afterward.
Check On Demand
Go to Settings → On Demand and check for conditions that automatically connect, disconnect, or switch behavior on the current Wi-Fi or cellular network.
The port is 443. Should I choose Trojan or VLESS?
You cannot choose by port. Return to the provider’s parameter sheet and look for the protocol name and authentication fields such as Password or UUID. If the source does not identify the Type, confirm it with the original configuration source.
Why are there multiple protocols after importing a subscription?
One subscription can create server entries with different Types. Open each entry to check its type; do not manually change every entry to the same protocol. Refresh updates from the original Subscribe source.
Connectivity Test succeeds, but requests are not going through the server?
Check whether the entry is selected in Home, then see whether Global Routing is set to Direct. If you use Config, also check whether DOMAIN-SUFFIX, GEOIP, or IP-CIDR rules assign the destination to Direct.
Hysteria2 stops connecting after switching networks?
First confirm that the network allows UDP traffic on the configured port, then verify Address, Port, Password, and SNI. If Wi-Fi and cellular networks behave differently, record the results separately and ask the original service configuration provider to investigate.
When should I enable On Demand?
Use it only when you need connections to trigger automatically according to network conditions. The path is Settings → On Demand. When first troubleshooting protocol parameters, note its current state so automatic actions do not interfere with manual testing.
Source and usage boundaries
Shadowrocket is a closed-source commercial application for Apple platforms, primarily used on iPhone and iPad. Availability on Mac, Apple TV, and Apple Vision follows the compatibility information on the App Store page; system requirements are as listed on the App Store page. The App Store is the only official source. The genuine product page lists Shadow Launch Technology Limited as the developer, the app ID as 932747118, and a one-time purchase model.
Buying the client does not include network service. This guide explains only how to map parameters from your own provider to Shadowrocket; it does not provide or recommend network services, servers, or subscriptions. If fields change after a subscription update, follow your own configuration source and do not copy the old entry’s Password, UUID, SNI, or keys into the new entry.
- Shadow Launch Technology Limited
- App ID 932747118
- One-time purchase
- General guidance for iPhone and iPad