Official Manual · Protocol Reference
Shadowrocket
Protocol Settings & Selection
Check which protocols the server actually supports, then verify the transport, authentication and certificate settings. A protocol name does not guarantee speed or battery life.
- Shadowsocks
- VMess / VLESS
- Trojan
- HTTP / SOCKS5
- WireGuard
- Hysteria2
This reference is for users who already have their own subscription or server details. To add a configuration for the first time, allow a VPN configuration and connect, follow the steps in the Getting Started guide. Return here when you need to understand fields, compare transport options or troubleshoot a protocol. We do not provide, sell or recommend nodes, subscriptions or connection services.
Shadowrocket is a closed-source commercial app for Apple platforms, primarily used on iPhone and iPad. It is available exclusively on the App Store. Check the App Store listing for system requirements. The one-time app purchase is not a service plan; buying the app does not provide a server address or authentication details. See the App Store download guide to verify the official listing, developer and app ID.
- Choose fromprotocols supported by the server
- Use parameters fromyour existing configuration
- Test methodchange one setting at a time
01 / Understand the layers
What protocols, transports and rules do
Start by separating four different questions
Choosing a protocol in Add Server determines how the client exchanges authentication and application data with the server. Entering an address and port determines where the connection goes. Choosing TCP, WebSocket or another transport determines how the data is carried. TLS determines how that connection verifies the server's identity and protects data. These settings are related, but they are not interchangeable. Changing Type to a different name does not make the server support another protocol.
Rules & Routing are a separate decision. When Global Routing is set to Config, the client uses the current configuration to decide which policy handles a request. Only after the request is sent through a proxy does the selected server's protocol come into play. Correct rules do not guarantee valid server authentication, and a reachable server does not mean every domain matches the intended policy. When troubleshooting, record which route was selected separately from whether that route could connect. This helps avoid repeatedly changing unrelated settings.
Keep server address, identity and destination domain separate
The server address is the first destination the client connects to; it can be a domain name or an IP address. TLS Server Name is generally used to verify the server's identity and provide the name during the handshake. WebSocket Host and Path belong to the request for that transport. These values may be the same in some configurations and different in others. Don't replace them all with the same domain just because each field accepts one. Check each value against the original parameters, including capitalization and path structure.
The website you ultimately visit is another destination entirely. The proxy server connects to it; its name does not therefore belong in the client's Server Name field. Likewise, DNS resolution when connecting to the server may follow a different path from resolution for a website after the proxy is established. If a page will not load but Connectivity Test returns a result, first check which part the test covers. That result alone does not prove that every lookup and request succeeded.
Use routing modes to narrow down what to check
In Global Routing, Config, Proxy and Direct help compare rule-based routing, the proxy route and a direct connection. “Proxy” does not guarantee that every type of system traffic follows the same route; check local network settings, exclusions and app behavior against your actual configuration. Switching modes is a diagnostic step, not a fix for an incorrect password, certificate or port. When troubleshooting is done, restore the mode you normally need so a temporary test does not become a permanent setting.
| Layer | What it determines | Common checks |
|---|---|---|
| Rules | Which policy handles a request | Config, rule order, final policy |
| Protocol | Authentication and data format | Type, password, UUID, keys |
| Transport | How protocol data is carried | TCP、UDP、Host、Path |
| TLS | Outer-layer encryption and identity verification | Server Name, certificate, device time |
The following snippet belongs in the Rule section of a .conf file. It illustrates routing order; it is not server configuration and cannot replace a subscription. The first rule matches a domain and its subdomains, the second matches the corresponding address range, and the last catches requests that did not match earlier rules. PROXY in the example must refer to a proxy policy that actually works. Before copying the rules, confirm the policy names and their intended use in your current configuration.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXYRules are evaluated from top to bottom, and matching stops at the first hit. Placing a broad rule too early can prevent a more specific rule from taking effect. While troubleshooting a protocol, avoid changing this order at the same time; otherwise, a successful or failed request may be affected by both the route and the transport, making the cause unclear. For more keyword details, see Rule Keywords and Matching Order. For your first connection, follow the steps in the Getting Started guide.
Record the original settings, then change one variable at a time. Similar names do not make fields interchangeable, and a test result does not verify the entire request path.
02 / Symmetric-key proxy
Shadowsocks: match the method and password
Designed to use fewer session layers
Shadowsocks combines proxy forwarding with symmetric encryption. The client and server exchange data using an agreed method and key material. Unlike designs that first establish a standard TLS session and then carry proxy authentication, a basic Shadowsocks configuration usually centers on the address, port, encryption method and password. Fewer fields do not mean they can be entered arbitrarily: together, they determine whether the server can recognize the data, and any mismatch can stop communication early.
This context helps clarify what Shadowsocks does and does not provide. It handles proxy requests; it does not automatically create a complete private address network, and encryption in the name does not imply website certificate validation. When a website uses HTTPS, the website connection handles its application-layer security. The client-to-proxy connection is handled according to the specific Shadowsocks method. Distinguishing these layers prevents the assumption that choosing a protocol means certificate checks or website warnings can be ignored.
Method is not a speed setting you can change independently
When importing an existing configuration, check the encryption method first. Methods differ in authentication, key derivation and data encapsulation; don't replace one on the client just because another name looks newer. AEAD methods provide confidentiality and integrity together, but key formats and handshake conventions can still differ across protocol generations. Use the method specified by the server. For available options, refer to the types shown in the app and the server details you already have.
The password field is not always ordinary, arbitrarily short text. Some methods require an encoded key in a specific format; others derive a key from a password. Do not remove trailing equals signs, add spaces or decode encoded text before pasting it back. When entering details manually, check for leading or trailing whitespace, full-width punctuation and line breaks. When importing from a QR code or share link, inspect the parsed fields rather than relying only on the profile name. A profile name can be changed freely; it tells you nothing about the authentication material.
A working TCP connection does not confirm the UDP path
Web requests and real-time apps may use different transports. A reachable TCP port on the server does not mean UDP forwarding is enabled on the same port, or that the current network allows the relevant traffic in both directions. If web pages load but voice or another real-time feature does not work, check whether the server supports UDP forwarding, then check the client settings and network path. Don't assume the password is at fault: with an incorrect password, even basic proxy requests usually fail.
Some existing configurations also include extra transport or obfuscation parameters. These are not required by every Shadowsocks server, so don't copy them from a different configuration. If an imported subscription works but a manually recreated entry does not, compare the method, password, address, port and additional fields in both records instead of repeatedly switching Global Routing. The server must support these features; a client toggle cannot add server-side support.
Understanding performance trade-offs on iPhone
The actual processing cost of Shadowsocks depends on the algorithm, device hardware and amount of traffic. Fewer outer handshakes may help with short-lived connections, but a real webpage also involves DNS lookups, responses from the destination and requests for multiple resources. Protocol layer count alone cannot predict page load time. During long transfers, throughput may instead be limited by server bandwidth, wireless signal or the destination site. Changing methods won't automatically improve performance if encryption is not the bottleneck.
Battery comparisons should account for connection behavior and wireless conditions. With a weak signal, retransmissions and an active wireless radio can matter more than algorithm differences. Frequent tests and subscription refreshes also increase activity. For a fair comparison, use the same network and task, with roughly the same screen state, and distinguish an idle connection from a continuous download. An app's share of battery use in a particular system report is not a protocol power rating; the reporting period and background tasks may differ.
Keep Shadowsocks when the server explicitly provides a supported method, the settings are straightforward and real-world requests work as expected. If something needs fixing, first make the parameters match, then check DNS and transport. If you are unsure about a share link's prefix, encoding or password, see Share Links and Subscription Formats to identify what you have. Don't enter an entire share link as the password or use a subscription URL as the server address.
03 / Authentication and encapsulation
VMess and VLESS: similar fields, different conventions
The same UUID does not make them the same protocol
VMess combines identity authentication, data encapsulation and its own security handling; configurations commonly use a UUID to identify the user. VLESS uses a lighter protocol-layer design and does not provide the same payload encryption mechanism as VMess, so it typically relies on an outer secure transport to protect the connection. Because their designs differ, keeping the same UUID and changing Type from VMess to VLESS will not make the server recognize the new protocol.
Both are often combined with other transports, which is one reason their settings screens have more fields. The protocol handles authentication and data format; the outer transport carries the data; TLS and similar mechanisms protect the relevant connection. A deployment may support only one particular combination. If your existing details specify a protocol and transport, preserve them. If all you have is an address, port and UUID, you may not have enough information to reconstruct the configuration. Check the original configuration for the remaining details.
Verify identity first, then check transport settings
Preserve every UUID character and hyphen. Don't enter a profile name, subscription group or server domain in its place. VMess configurations may also include a security method and legacy compatibility fields; extra authentication parameters in older material are not defaults to copy into every new configuration. Don't add values just to match an old screenshot. Use the current server details and the fields available in the app. If they do not line up, first confirm that the source details are for the same protocol type.
For a WebSocket connection, Path is the path the server accepts, usually including its leading slash; Host is the request's host information. Whether the path is case-sensitive or includes a query string depends on the deployment. Clearing the path or keeping only its last segment may cause the server to return a regular webpage instead of establishing the proxy transport. If the address resolves and the port is reachable but the connection closes quickly, first check whether this layer matches the server settings.
Check the TLS setting, Server Name and certificate validation separately. When connecting by domain, the server address and certificate name may match. When connecting to a specified address, Server Name may still need to be the domain covered by the certificate. A successful TCP connection is not a reason to skip identity verification, and disabling validation does not fix a name mismatch. If the original configuration includes additional security mechanisms or conditions such as Flow, confirm that both ends support the combination rather than inferring it from the protocol name.
Outer transports affect connection costs
WebSocket adds an encapsulation layer suited to certain service architectures and can work with existing HTTP entry points, but adds a handshake and frame processing. Direct TCP may involve fewer layers, but requires different conditions at the server entry point and along the network path. There is no universally best option for every device. A complete, stable configuration is usually more practical than one with fewer theoretical layers that frequently fails.
In lossy conditions, stacking multiple reliable transport layers can increase waiting and buffering; the actual impact also depends on connection reuse and server implementation. WebSocket does not automatically mean slow, and VLESS does not automatically mean lower battery use. On iPhone, handshake overhead differs between one long-lived connection and repeatedly creating many short ones. Recovery after a network change also affects how long the wireless radio stays active. Compare repeated tests of the same task instead of ranking protocols by name.
Pinpoint the stage where the failure occurs
If all requests fail, first confirm that the selected SERVER entry is the one you are editing, then check the protocol, port and UUID. If some sites work and others do not, check rule matching, DNS and the destination site separately. If the problem occurs only after changing networks, try stopping and reconnecting to see whether an old session failed to recover. Don't immediately rewrite identity fields: the fact that the same configuration worked before is useful evidence when troubleshooting.
VLESS's lighter protocol layer does not make the entire connection cost-free. TLS, transport, reconnections and application requests still affect speed and battery use.
Manual setup should not become a process of guessing fields. A more reliable approach is to import a known-complete original entry, keep it as a working baseline and see how each value maps to the app. If a subscription update changes fields, compare the records before and after the update instead of mixing selected values from the old entry into the new one. Keep routing settings in configuration files separate from server entries. For details on their structure, see What Each .conf Section Does.
04 / TLS identity verification
Trojan: password authentication inside TLS
Establish a secure connection before exchanging proxy details
Trojan uses TLS to establish a protected connection, then carries authentication and proxy requests inside it. Because it combines standard secure transport with a proxy protocol, a correct password is only one requirement: the certificate, name and outer connection must also match. This order matters. If the TLS handshake fails, changing the proxy password usually won't help. If the handshake succeeds but authentication is rejected, repeatedly changing the certificate name won't fix an incorrect password.
This design differs from protecting proxy payloads directly with a symmetric key. TLS requires the server to provide a verifiable identity and negotiates the parameters needed for the connection. It protects the client-to-server segment, but does not replace HTTPS validation by the destination website or guarantee everything that happens between the server and that site. When reading an error, first distinguish a proxy server certificate issue from a destination website certificate warning in the browser. They concern different connections.
Server Name should match the certificate
The server address directs the connection to the right entry point. Server Name is generally used in the TLS name indication and certificate validation. If an existing configuration connects to an IP address but specifies a domain for TLS, that may be intentional: the server could provide its certificate for that domain. Changing it to the destination website's name will not help. Check which names the server certificate covers and what the original configuration requires, rather than choosing the most familiar domain.
Certificate validation depends on the expiry date, trust chain, name and device time. If the device date is significantly wrong, a valid certificate may be reported as invalid. The client may also reject a replaced server certificate or a missing intermediate certificate. For a certificate error, check automatic date and time, server settings and certificate status first. Allowing insecure connections is not a routine fix: it changes the assumptions behind identity verification instead of restoring the correct configuration.
Check the password and additional settings individually
A Trojan password is server authentication material, not a device passcode or App Store purchase credential. Paste the complete value and make sure there is no trailing line break. If the password contains special characters, encoding in a share link may affect how it appears. Check the actual field after importing; don't manually encode text that has already been escaped. A profile name containing Trojan does not confirm that the link contents and the client's Type are correct.
Some existing deployments include extra transport options, which must be supported by the server as well. Don't add WebSocket, change Path or enter an unknown negotiation value without instructions. If the outer entry requires a particular host, path or handshake condition, leaving one out may cause another service to receive the request. A regular webpage loading at the same domain only confirms that the website is reachable. It does not prove that the proxy authentication path or port is configured correctly.
Trade-offs in handshakes, connection reuse and background activity
A TLS handshake involves cryptographic processing and network round trips, so establishing a new connection has a cost. An established connection can carry subsequent data; how it is reused depends on the protocol and implementation. For occasional web browsing, connection setup time may be more noticeable than sustained throughput. During long playback or transfers, the handshake accounts for only part of the task. A single Connectivity Test result cannot predict a full video session or all-day battery use.
On iOS, background network activity also depends on app tasks, system scheduling and the current network. Repeated disconnects and reconnects can increase the number of handshakes; keeping many requests active for long periods can keep the wireless radio working longer. A sensible configuration manages connections according to actual needs rather than always keeping them on or always disconnecting. On Demand controls when a connection is triggered; it does not change the Trojan password or certificate, nor does it eliminate handshake costs.
When the server provides a valid certificate, a specified password and complete settings, Trojan is an option whose identity checks can be managed through standard TLS verification. When choosing it, consider whether certificate maintenance can be verified and errors can be diagnosed by layer. Don't treat the presence of TLS as a quality rating. Certificate and DNS failures can look similar at first; see Troubleshooting DNS Resolution Failures to identify the stage where the problem occurs.
05 / General-purpose proxy interfaces
HTTP and SOCKS5: forwarding does not mean an encrypted connection
Two approaches developed for app proxying
HTTP proxies were originally designed to relay HTTP requests and can also use the CONNECT method to create a tunnel to a specified destination. SOCKS5 provides a more general proxy negotiation mechanism, letting the client give the server a destination address and port. Supported commands and authentication methods depend on both ends. Both can act as proxy entry points, but their request semantics and handshake formats differ. The same address and port do not make an HTTP entry compatible with SOCKS5.
These protocols are commonly used in networks managed by the user or on servers that explicitly provide a general-purpose proxy interface. Their focus is forwarding, not automatically providing the same connection-level protection as modern encrypted tunnels. Confirm separately whether TLS is used, how authentication works and which destinations are allowed. An HTTP proxy that permits CONNECT may still restrict ports or access, so loading a webpage does not prove that every app and destination can use that entry point.
An HTTPS website is not the same thing as a secure proxy
When you access an HTTPS website through an HTTP proxy, the CONNECT tunnel can carry the website's own TLS connection. This may protect the website content end to end, but it does not encrypt the proxy handshake and other metadata between the client and the proxy just because the destination uses HTTPS. Evaluate “TLS for the website connection” separately from “TLS for the connection to the proxy.” Choose the type specified by your existing configuration.
SOCKS5 itself is not encrypted transport either. Username and password authentication identifies the user; it does not automatically provide confidentiality for authentication data or subsequent traffic. Setting a password does not mean the entire connection is encrypted. Avoid sharing sensitive authentication details as ordinary notes when you do not know the network conditions. Whether the connection is suitable for your use depends on the underlying network, outer protection and server access controls.
Authentication, DNS and UDP are separate concerns
An HTTP proxy may require a username and password or impose other access restrictions; SOCKS5 has its own authentication negotiation. If authentication fails, first confirm that the required method is supported by the current configuration, then check the values themselves. A reachable TCP port does not mean authentication succeeded; reachability is only an early connection step. A server's explicit authentication rejection differs from a timeout: check identity settings for the former, and the address, port and network path for the latter.
Where a destination domain is resolved affects reachability and troubleshooting. SOCKS5 can carry a domain or an IP address in a request, but which is used also depends on the client's DNS strategy and the source of the request. The protocol name alone does not tell you that every lookup happens on the server. If some domains fail but direct IP access works, check the resolution path and results. When testing with an IP instead of a domain, remember that HTTPS certificate names and virtual hosting may behave differently.
SOCKS5 defines mechanisms related to UDP, but a particular proxy entry may not enable or allow UDP forwarding. Ordinary HTTP CONNECT should not be treated as a general-purpose UDP tunnel either. For real-time apps, first confirm that the original service details include the required capability. If web pages work but real-time features do not, switching back and forth between HTTP and SOCKS5 is not a default fix. Each requires different server support, and switching incorrectly can introduce new handshake failures.
Deciding whether to keep a general-purpose proxy
These general-purpose interfaces offer clear semantics and are already available in many managed environments, making them suitable for existing network designs. Their limitations are that security, authentication and forwarding scope may need to be supplied by other mechanisms. When choosing, first identify whether you need to handle a few web requests, route a specific app or cover a broader range of traffic. Then check what the server actually permits. A short protocol name is no guarantee of speed or battery savings.
On iPhone and iPad, actual costs also depend on the number of connections, server response and wireless network. Fewer proxy layers may simplify some tasks, but repeated failures and retries caused by destination restrictions can increase overall activity. Use the same destination and task for testing, and record DNS, authentication and content-loading results separately. A test result shown in the server list does not prove that the target service works. For common symptoms and next steps, see Frequently Asked Questions.
06 / Network-layer tunnel
WireGuard: understand keys, addresses and routes together
It is not just a proxy type with a different password
WireGuard is a network-layer encrypted tunnel that uses public-key identities and a fixed cryptographic design to establish peer connections. Unlike protocols that specify only a single proxy destination, it also involves tunnel addresses, peers and the ranges of addresses allowed through the tunnel. These address ranges and keys are essential parts of the network configuration, not unnecessary details. A server address and password alone are usually not enough to reconstruct a WireGuard configuration.
This design suits networks with a clearly defined tunnel plan, but both ends must agree on addresses and routes. When using WireGuard as an exit in Shadowrocket, distinguish the client's routing rules from the address restrictions in the WireGuard configuration. The first determines whether a request is sent to that exit; the second affects which traffic the tunnel accepts and forwards. When both layers impose restrictions, checking only one can lead to apparently conflicting results.
Private Key and Public Key are not interchangeable
The Private Key is the identity material for this device and should be kept secure. The Public Key lets the peer identify the corresponding identity. The client needs the server's public key, and the server must be configured with the public key corresponding to this client. Don't enter the server's public key as the local Private Key or assume keys are interchangeable because they look similar. If the configuration uses a Preshared Key, both sides must have the same additional shared value. Don't invent one or change it on only one side.
The tunnel address is not the server's public address. The former defines the internal tunnel network; the latter identifies the Endpoint that receives UDP traffic. Preserve the prefix length required by the original configuration. If you mistakenly enter a tunnel address as the Endpoint, the client may not be able to reach it from the current network. The port is also part of the Endpoint; don't infer it from a common example. If the existing configuration uses a domain, ensure it can be resolved before connecting.
Allowed IPs and keepalive limits
Allowed IPs describes the address ranges associated with a peer and contributes to routing and source restrictions; the exact behavior depends on the implementation. A range that is too narrow may leave some destinations outside the tunnel, while an overly broad range may conflict with the existing network plan. Don't replace the original value just to “make everything work.” For private address access, also check for overlapping ranges on the local network. Overlap can send traffic the wrong way, but it is not a key authentication failure.
Persistent Keepalive can maintain a network address translation mapping when needed, particularly when this device is behind a translating router and must receive traffic from its peer. It is not a universal setting where more frequent is always better. A very short interval increases idle traffic and may prevent the radio from sleeping on mobile networks. If the original configuration does not specify it, first check whether expiring mappings actually cause reconnection problems, then adjust based on the network rather than adding a fixed interval by default.
MTU and pages that stall partway through
Tunnels add encapsulation overhead, so the packet size supported by the actual path matters. An unsuitable MTU can sometimes cause small requests to work while larger responses or particular sites stall. Don't immediately replace the keys; check the path and encapsulation conditions first. Adjust MTU based on the original value and repeatable tests, making small changes and keeping a record. Copying a random value may hide the problem or cause fragmentation or efficiency issues on another network.
WireGuard uses UDP transport, so the network must allow the relevant traffic in both directions. Switching between Wi-Fi and cellular changes the endpoint and mapping state; recovery also depends on network policy. If UDP is unreachable, adding keepalive cannot make a blocked path work. First check the Endpoint, port and network conditions, then observe the handshake and actual traffic. A connected status in the client does not prove that routing through the tunnel works.
WireGuard's streamlined design can reduce processing overhead, but total device cost still includes userspace processing, wireless traffic, keepalives and application load. That does not mean it is always better than an application-layer proxy. If an existing network provides complete keys and address planning, use them as specified. Don't force an ordinary proxy share link into a WireGuard configuration. Choose based on server capabilities and network goals, not the number of fields or the protocol's reputation.
07 / QUIC and congestion control
Hysteria2: verify UDP before evaluating throughput
Transport designed for changing network conditions
Hysteria2 builds proxy transport on QUIC, which typically runs over UDP and combines secure handshakes with reliable transport capabilities. Its design focuses on managing data transmission as latency and packet loss change, not simply on reducing the number of password fields. UDP is the underlying transport; it does not mean that application data is unreliable. QUIC can provide reliable streams over UDP, so distinguish the underlying packets from the semantics of the application data.
This explains why Hysteria2 may be worth testing on some variable network paths, but also why it is not the default answer for every network. The network must allow the relevant UDP path, and the server must provide a Hysteria2 entry. If network policy blocks that path, changing a bandwidth value on the client will not make the connection work. If the destination site limits the service, a different congestion control method will not remove that limit.
Authentication, certificates and extra settings still matter
Basic settings include the server address, port, authentication material and TLS information. Match the authentication text to the original configuration. If the server uses a specific combined format, do not split it into a username and password yourself. Server Name must match the server certificate and deployment requirements, as described in the TLS section above. A device clock error, untrusted certificate chain or name mismatch can all cause the handshake to fail; increasing the send rate will not fix them.
Some configurations include extra obfuscation settings, which are needed only when the server enables the corresponding feature. An incorrect extra password may prevent the server from recognizing the initial data. Don't add the field to every Hysteria2 entry just because another one has it. Check the full set of parameters after importing, and confirm the share is actually for Hysteria2 rather than judging compatibility by a similar name. Different protocol generations may use different authentication and encapsulation conventions.
Bandwidth settings are not speed test results
Some configurations let you specify uplink and downlink bandwidth. These values may affect sending behavior or the relevant congestion control mode; they are not a speed guarantee from the server. Setting a very high value does not increase wireless or server capacity and may instead cause queueing, packet loss and retransmissions. Whether to enter a value and how it is negotiated with the server depend on the existing deployment and options available in the app. A sample value is not a best setting for every network.
To evaluate bandwidth settings, distinguish uplink from downlink and check whether other tasks are affected. A large file transfer may seem faster while webpages become noticeably slower; that can indicate queue buildup rather than an overall improvement. Cellular capacity changes with location and network load, so a fixed setting may not suit every condition. A safer approach is to keep the original configuration, make a conservative and testable change in one direction at a time, and repeat the same set of tasks.
Packet loss, network changes and battery use
QUIC's stream model can reduce some cross-stream delays, but cannot eliminate the cost of wireless packet loss or let a reliable stream bypass missing data. Congestion control adjusts sending based on feedback; both the server implementation and network conditions affect the result. “Runs over UDP” does not mean “always faster.” If UDP performs poorly on a particular network, a traditional TCP path may be more stable for actual tasks. Test rather than relying on slogans.
During sustained high-throughput use on iPhone, wireless activity and device temperature can become significant factors. Retransmissions caused by aggressive sending consume network activity, and frequent reconnections add handshakes. Compare battery use under the same signal, similar temperature and identical tasks. Do not compare a long speed test with another protocol sitting idle. A brief result during device heating or a network switch describes only those conditions; it does not establish a fixed battery ranking for protocols.
If Hysteria2 alone fails on a particular network while other confirmed entries on the same server work, first check UDP, the port and certificate, then verify authentication and extra settings. Don't change DNS, rules and bandwidth settings all at once, or you won't know what fixed the problem. If the connection succeeds but pages behave oddly, check destination resolution, rule matching and actual requests next. This section covers selection and diagnosis; it does not promise a connection speed or replace the server's own configuration details.
Establish a baseline with correct settings, then test sustained transfers. A higher stated bandwidth does not mean more usable bandwidth.
08 / Choose and verify
Choose from what you have, then test real tasks
Rule out combinations the server does not support
Start protocol selection by listing the entry types your server actually provides, not by comparing names. If you only have Shadowsocks settings, verify the specified method first. A complete WireGuard configuration is the starting point for discussing tunnel addresses and keys. A subscription containing multiple types does not mean every entry uses the same server, route or resources. Differences in test results may reflect the deployment as a whole, not the protocol alone.
Next, define what you need to do. For web browsing, focus on initial load, DNS and short-lived connections. For sustained transfers, focus on stable throughput and device temperature. Real-time apps also require confirmation of UDP or other forwarding capabilities. For access to an existing private network, address planning and routing may matter more than a single latency reading. Choose based on tasks you can verify, not a ranking that claims to cover every situation.
| Existing setup | Check first | Do not assume |
|---|---|---|
| Shadowsocks entry | Method, password, UDP support | The algorithm name determines overall speed |
| VMess / VLESS entry | UUID, transport, TLS, path | The same UUID works across protocols |
| Trojan entry | Password, certificate, Server Name | A reachable port means authentication succeeded |
| HTTP / SOCKS5 entry | Authentication, protection, forwarding scope | A password encrypts the entire connection |
| WireGuard configuration | Keys, Endpoint, addresses and routes | A successful handshake means every address is reachable |
| Hysteria2 entry | UDP, TLS, authentication, sending settings | Stated bandwidth equals actual throughput |
Use a repeatable test sequence
Save the configuration that currently works and confirm which SERVER entry is selected during testing. Keep the network, Global Routing mode and destination fixed, and stop unrelated high-traffic tasks. Start with a basic connectivity check, then open a real webpage or app, and only then test a sustained transfer. For each round, note whether it worked, whether the initial response was unusual and whether it stopped after a while. There is no need to chase a single lowest-latency result; repeatable behavior is more useful than an occasional best result.
For battery tests, separate idle connections from active use. Keep screen brightness, signal conditions and task duration roughly consistent, and monitor device temperature. System battery reports are a useful observation, not lab power meters; their reporting periods include other background activity, and percentages depend on total power use. If you cannot control these conditions, record only what you observed during the current task. Do not present it as an inherent property of a protocol.
Troubleshoot based on the stage of failure
If the connection cannot be established at all, first check server address resolution and the port path, then verify protocol type, identity settings and outer transport. For a clear certificate error, check the name, device time and trust chain. For an authentication rejection, check the password, UUID or key mapping. If only some destinations fail after connecting, check rule matching, DNS results and the destination itself. If the connection fails after running for a while, note whether it coincides with a network change, an expired mapping or sustained heavy traffic. Don't start over by re-entering the password every time.
Connectivity Test reflects only the test it runs; it cannot stand in for all real-world requests. If it returns a result but webpages will not load, compare different domains, then check DNS resolution and the final policy. If the problem occurs only in Config mode, compare it with a temporary Proxy mode to see whether routing rules are involved. Restore the original configuration afterward and keep only changes that have been shown to work. For step-by-step setup, return to the Getting Started guide. Avoid changing settings across multiple screens at once.
Keep records to prevent configuration drift
Subscription updates may change entry points, settings or profile names. If a problem appears after an update, first confirm whether an entry was replaced and which one is currently selected. Manually editing an entry created by a subscription may also mean your changes are overwritten by a later update. Keep troubleshooting notes that describe field types and symptoms without sensitive details. Do not post complete passwords, private keys or subscription URLs containing authentication information. Check screenshots for exposed details before sharing them too.
Keep a configuration that has a clear purpose, traceable settings and verified results rather than accumulating unexplained test options. The protocol defines the connection format, the transport carries it, TLS protects the relevant layer, and rules select the route. None of these layers replaces another. For purchase and restore questions, see Restore Purchases; for connection issues, see Frequently Asked Questions; for configuration structure, see the related articles. Keeping these roles distinct helps ensure that every change is supported by evidence.