Shadowrocket
Protocol Guide & Selection
Match the protocol to your server first, then compare transport, speed and battery use.
This reference is for users who already have their own subscription or server details and need to check protocol types and settings. If you’re adding a server or connecting for the first time, follow the main steps in Getting Started, then return to the relevant section for an explanation of the differences. The tutorials also provide step-by-step instructions for the checks covered here.
Connection layers and troubleshooting order
Separate the protocol, transport, security layer and rules to avoid changing multiple variables at once.
Protocol type is not a speed setting
In Add Server, choosing Type specifies the format the client and remote server use to exchange data—it does not select a speed tier. The client must use a type supported by the server and the matching authentication details. A single address may expose several ports, but each port can run a different service. Changing a Shadowsocks entry to Trojan does not make the server switch protocols. Start by confirming which protocols your existing server supports, then compare the available options.
A complete entry usually contains four kinds of information: the address and port locate the service; the protocol and authentication establish the session; TCP, WebSocket or a UDP-based transport carries the data; and security layers such as TLS handle the relevant encryption and identity checks. Some protocols provide encryption themselves, while others rely on an external security layer. Some use only a few fields, while others require a matching transport path. Two configurations with the same protocol name but different transports are not interchangeable just because the address and password match. When importing a subscription, check that these additional details were retained.
What happens to an app request
When Shadowrocket is enabled on iPhone or iPad, iOS routes the relevant traffic to the network extension, and the app handles it according to the current settings. In Global Routing, Config applies the rules in the active configuration; Proxy sends covered requests through the proxy path; Direct uses a direct path. These options control routing—they do not fix protocol authentication or add capabilities to the server. If a request already matches DIRECT, changing the remote protocol usually won’t change where that request goes.
DNS resolution, rule matching, the client-to-server connection and the server-to-destination connection are separate points of failure. A page may fail to load because name resolution failed, TLS verification failed, authentication was rejected or the destination is unreachable. Connectivity Test reports only the result of its specific test; it cannot confirm that every destination, port or UDP app is working. Record which step failed instead of reducing the entire connection to “connected” or “slow.”
| Layer | What to check | Common misconception |
|---|---|---|
| Service endpoint | Address, Port and reachability | If the address resolves, the port must be reachable |
| Protocol authentication | Type, Password, UUID or key | The same port means the same authentication method |
| Transport and TLS | Transport type, path, SNI and certificate | Every protocol requires only one password |
| Routing and DNS | Global Routing, rule matches and resolution results | Every request uses the selected entry |
Compare performance under repeatable conditions
Protocols can affect speed and battery use, but route distance, server load, wireless signal, destination service and traffic type often matter more. For a fair comparison, keep the device, network, destination and test window consistent. First observe how long a short page takes to open, then check the stability of sustained transfers. A single latency measurement can confuse DNS caching or connection reuse with a protocol advantage; peak speed on a large download can hide the cost of frequent wake-ups and short connections. Recording the conditions is more useful than ranking protocols in the abstract.
For battery use, focus on active radio time, background keepalives, retries and transfer efficiency. A lightweight encryption algorithm doesn’t guarantee lower power use, and repeated failed reconnects can consume more resources than a seemingly simple configuration. Test on the same network rather than switching between Wi-Fi and cellular while drawing conclusions. To understand why a request uses a particular route, see the three Global Routing modes. If you’re just getting started, return to Getting Started and verify each step in order.
Shadowsocks
The fields are relatively straightforward; the key is matching the encryption method, credential format and server capabilities.
Design background and key trade-offs
Shadowsocks is designed for encrypted proxy connections. A typical configuration includes a server address, port, encryption method and password. Unlike a full virtual network tunnel, it doesn’t require users to configure interface addresses and a complete set of routes; instead, the client forwards relevant requests to the remote server. The short list of fields is easy to check by hand, but that doesn’t mean all methods are interchangeable. Protocol versions, encryption methods and extensions can change compatibility requirements. When you receive an entry, check the full method name rather than relying on the general label Shadowsocks.
Common AEAD methods provide confidentiality and authenticate messages to detect tampering. Newer protocol designs may change session handling, replay protection and key formats, so a plain-text password won’t work with every method. Methods that require an encoded key of a specific length need credentials in exactly the required format. This guide doesn’t assume a method is faster or more secure based on its name alone. The available choices depend first on the remote implementation and current app support, then on testing with your device and network.
Address, Port, Method and Password
Enter a domain name or IP address for Address and the service’s listening port for Port; both must come from the same valid set of server details. Don’t include a webpage path in the domain, or paste a full subscription URL into the server address field. Method must match the remote server exactly. Copy Password as provided, paying particular attention to leading or trailing spaces, line breaks and full-width characters. If a subscription contains entries with the same display name, don’t assume they’re identical. Compare their addresses, ports and methods to avoid editing a different, outdated entry.
Some existing configurations also include a plugin or additional transport parameters. These aren’t required for every Shadowsocks connection. Add them only if the remote server explicitly uses the corresponding capability and the current app supports those settings. Don’t copy TLS, a path or Host from someone else’s screenshot on the assumption that more layers mean greater reliability. If an import has unknown or missing fields, confirm the compatible format with the source of the original details instead of guessing at parameters one after another.
TCP, UDP and behavior on mobile devices
Web browsing usually relies mainly on TCP, though apps may also use UDP-based protocols. Which traffic a Shadowsocks entry can handle depends on whether the client, remote server and intervening network all support the required forwarding. A webpage loading successfully doesn’t prove the UDP path works; conversely, a real-time app failing doesn’t prove the password is wrong. First test a regular webpage, then test a destination that actually requires UDP and check the relevant remote port and network policies.
On iOS, a straightforward connection setup may work well for everyday short requests, but latency and throughput still depend on the actual route. During sustained transfers, encryption, wireless signal and server capacity all affect battery use; for occasional access, connection setup and radio wake-ups may matter more. If a poor network causes repeated timeouts, changing the encryption method may not help. First distinguish a connection that never establishes from one that connects but transfers slowly. Then decide whether to check endpoint reachability or sustained transfer conditions.
When to use it and where troubleshooting stops
If your existing server offers only Shadowsocks, use the matching type and import the original details in full; there’s no need to switch just for a different protocol name. If the same server offers several compatible options, use the one with fewer fields as a baseline for diagnosing basic issues. On failure, check DNS, port, Method and Password first, then confirm UDP support and any additional options. If changing networks fixes the issue, investigate the network conditions rather than repeatedly resetting credentials. Check routing rules separately, so requests that match DIRECT aren’t mistaken for Shadowsocks test results.
VMess and VLESS
Identify the authentication protocol, transport and security layer separately; a UUID is only one part of the configuration.
The two protocols solve different problems
VMess includes user authentication and data protection mechanisms in its design; UUID is commonly used as the user identity. VLESS is a more streamlined protocol that typically relies on a separate security layer for data protection. VLESS itself does not provide the same built-in encryption semantics as VMess. Even when both use the same kind of user identifier, they are not interchangeable types. The client’s Type must match the protocol the server actually listens for; the presence of a UUID alone doesn’t determine the right choice.
These protocols often appear alongside settings such as TCP, WebSocket and TLS, which can make it easy to confuse the protocol with its transport. Think of them as a layered combination: UUID identifies the user, the transport determines how data is exchanged, and TLS provides the corresponding secure channel. If the server accepts only a specific combination, a correct UUID won’t help when the path or security layer doesn’t match. These combinations illustrate the concept; check the app’s current interface and the remote server’s documentation for the available options.
Authentication fields and time requirements
Copy the UUID exactly; don’t replace it with a display name, ordinary password or subscription identifier. Credentials in a subscription URL are used to retrieve configuration, while a server’s UUID is used to connect to that service. Some older VMess configurations also include additional authentication parameters; values from an old example aren’t universal. Compare each field if it’s included in the server details. If you were given only a link, first check whether import preserved all the fields rather than making up values.
VMess authentication has time-related requirements, so a significantly incorrect device clock can cause connection problems. Check that the system date and time are set correctly, then retry the same entry—but don’t assume every failure is caused by the clock. VLESS has fewer fields, but that doesn’t mean TLS or other associated checks can be ignored. With either protocol, an incorrect user ID, a port pointing to the wrong service, a mismatched transport path or an incompatible security layer can cause the connection to close quickly. The time it takes to fail usually isn’t enough to identify the cause.
WebSocket, Host, Path and TLS
With WebSocket, Path is the route the server uses to handle the connection. Preserve its leading slash, capitalization and any required query string. Host may be used to route the HTTP request, while SNI in TLS selects the name during the handshake. They may match or differ, depending on how the service is deployed. Don’t change both to Address for the sake of consistency. Address can identify the connection endpoint, while Host and SNI represent names at different layers; only the remote deployment details can determine the right combination.
TLS certificate verification must match the expected server name. If you see a certificate error, check SNI, the device’s date and time, certificate validity and the connection address first. Don’t hide the error by disabling verification. VLESS configurations that use additional security mechanisms or specific transport options also require support on both the app and remote server. Don’t copy fields from an unrelated configuration. A successful import only means the client could read some of the information; it doesn’t prove that the full combination can connect or that the remote server has enabled those capabilities.
Speed, battery use and how to compare
Adding TLS on top of WebSocket introduces handshake and encapsulation overhead, but that doesn’t mean it will always be slower in everyday use. Connection reuse, endpoint location, route quality and remote server load can offset or amplify the difference. For frequent short requests, compare the first page load with subsequent loads. For sustained transfers, check whether speed remains stable. Don’t compare an initial handshake with a reused connection. On iOS, assess battery use under the same network conditions; repeated connection retries are often more important than the number of fields.
If your existing server offers both VMess and VLESS, choose the option with clear settings, current app support and a well-maintained remote server—not simply the one with the newer-sounding name. For troubleshooting, keep one complete entry fixed and check Type, UUID, transport, Path, Host and TLS in order. Change only one field at a time, and only when it differs from the original details. If the imported list is missing entries, see the subscription import and empty-list checklist to separate configuration retrieval issues from protocol connection issues.
Trojan and TLS checks
Along with password authentication, the certificate name and handshake requirements determine whether the connection can be established.
Trade-offs in a TLS-based design
Trojan runs a proxy session inside a TLS connection and uses password authentication to identify the user. Keep the outer TLS layer separate from the authentication inside it: TLS establishes a secure channel and verifies the server’s identity, while the password authenticates access at the protocol layer. A successful TLS handshake doesn’t mean the password is correct; a correct password can’t fix a certificate name mismatch. Compared with a configuration where you only check an encryption method, Trojan requires closer attention to how the domain, certificate and endpoint match.
This design uses the established TLS ecosystem, but also depends on certificate validity periods, name verification and handshake negotiation. It isn’t the same as an ordinary webpage connection, and an address that supports HTTPS isn’t automatically a Trojan server. The remote server must actually run the corresponding service and have the required authentication configured for the client to establish a full session. You need complete details for an existing server, not a configuration pieced together from a website address and a familiar port.
What Address, Password and SNI do
Address identifies the network endpoint, Port specifies the service port, and Password must match the remote authentication settings. SNI sends a target name during the TLS handshake; the server may use it to select a certificate and connection path. Even when connecting to an IP address, you may still need a domain name for SNI. Conversely, using a domain for Address doesn’t mean you can ignore the original configuration requirements. If the server details specify SNI, keep it as provided rather than replacing it with the server name shown in the app.
Certificate verification generally requires a trusted certificate chain, a certificate within its validity period and a certificate that covers the name being verified. If verification fails, check the device’s date and time and the server name, then confirm that the server has the correct certificate installed. If only the endpoint has changed, use the server configuration details to confirm the relevant fields instead of disabling verification in the client. Skipping verification weakens server identity checks; it won’t fix an incorrect password or guarantee that you’re connected to the intended service.
The limits of handshakes, app requests and UDP
A successful TLS handshake confirms only one part of the connection. The client still needs to authenticate with Trojan, the remote server must connect to the destination, and the response must make its way back. If the handshake succeeds but a page won’t load, check authentication and remote access next. If it times out before the handshake, check name resolution and endpoint reachability first. If only certain sites fail, also check rule matches and DNS results. Breaking the connection into stages avoids blaming every problem on the certificate or repeatedly changing a password that is already correct.
Trojan’s UDP forwarding requires support from both the client and server, and actual behavior also depends on the transport. A TCP webpage loading doesn’t prove that real-time traffic will work; with some transport setups, packet loss can cause noticeable delays. Test with the actual app and its traffic rather than relying on a single webpage. For entries with additional transport layers, check the original configuration; the basic Trojan field list won’t cover every variant.
Assessing speed and battery use on iOS
A TLS handshake requires network round trips and processing, so the initial connection over a long-distance route may involve more noticeable waiting. Whether later connections reduce the overhead depends on the session and implementation. During sustained transfers, route quality, congestion and remote server performance often matter more than the first handshake. For battery use, stable connections and fewer retries usually help, but long-lived keepalives also keep the wireless radio active. TLS alone doesn’t mean high power use, and it’s not guaranteed to outperform other protocols on every network.
If your existing server offers a stable Trojan configuration with the certificate name, password and transport details in place, it’s a valid option to test. Keep the destination and network consistent: first check whether the session establishes reliably, then assess sustained transfers and background behavior. If a connection fails after an update, check whether the subscription includes any changes to the certificate name or endpoint. For update steps, see how to refresh a subscription manually or automatically; don’t guess at new parameters instead of syncing the configuration.
HTTP and SOCKS5
A general-purpose proxy interface is not an encrypted tunnel. Check name resolution and UDP support separately.
What general-purpose proxy protocols are designed to do
HTTP proxies were designed to relay HTTP requests. For HTTPS destinations, they typically use CONNECT to create a byte stream to the specified destination. SOCKS5 provides a more general proxy negotiation mechanism that can specify a destination address and port, without being limited to web traffic. These protocols are often used with existing internal networks or managed proxy endpoints. Their fields may look simple, but security and capabilities depend on the actual deployment. “Supports proxying” does not automatically mean “provides encryption.”
Distinguish a regular HTTP proxy from an HTTPS proxy. The former describes the basic protocol used between the client and proxy; the latter adds TLS to that connection. Accessing an HTTPS website doesn’t automatically protect all negotiation between the client and an HTTP proxy. The basic SOCKS5 protocol also doesn’t encrypt the entire connection. If your network requires confidentiality, check the security layer on the existing endpoint rather than relying on HTTPS in the destination URL.
Username, Password and permitted destinations
Address and Port identify the proxy endpoint. Enter Username and Password only if the remote server requires that authentication. Leaving authentication blank and entering incorrect credentials can produce different results; don’t assume just any account credentials work as the proxy password. An HTTP proxy may restrict which destination ports CONNECT can reach, or allow access only to specific destinations. A webpage loading successfully doesn’t prove that email, real-time communication or other ports will work. Before troubleshooting, check the access scope of the existing proxy so that policy restrictions aren’t mistaken for an app problem.
SOCKS5 can negotiate different authentication methods, but the client and server must support the same one. When importing, check that the type is recognized as SOCKS5; don’t infer it from the port number alone. Common ports are conventions, and a service can use another port. A familiar port can also run a completely different service. If the connection is refused, first check the address and listening service; if authentication fails, check the relevant account. Avoid changing the port, type and password at the same time, or you’ll make the problem harder to reproduce.
| Item | HTTP | SOCKS5 |
|---|---|---|
| How it works | HTTP request forwarding or CONNECT | General-purpose proxy negotiation and destination connection |
| Encryption built into the protocol | Plain HTTP does not provide TLS | The basic protocol does not provide encryption |
| UDP | Standard CONNECT is not general-purpose UDP forwarding | The protocol defines UDP ASSOCIATE, but both sides must support it |
| Destination restrictions | CONNECT ports or destinations may be restricted | May be limited by authentication, address policies and forwarding capabilities |
Where DNS resolution happens
Proxy negotiation may carry a domain name or an already-resolved IP address, which affects which side performs name resolution. The exact behavior depends on the client settings, rule requirements and how the protocol is used. Choosing SOCKS5 alone doesn’t mean DNS is always handled remotely. If configuration rules need an IP address to match, a related lookup may still happen locally. During troubleshooting, check whether the domain resolves, whether the result is reasonable and whether the proxy can reach the destination. Changing one DNS address won’t necessarily solve all of these issues.
SOCKS5 defines UDP ASSOCIATE, but the remote server may not have it enabled, the network may block the return path, or the client may not be configured to use it. Standard HTTP CONNECT should not be treated as general-purpose UDP forwarding. If webpages work but a real-time app doesn’t, first confirm whether the app relies on UDP and what the remote server explicitly supports. Repeatedly changing the username won’t fix missing forwarding capabilities; these issues occur at different layers.
Speed, battery use and limitations
Less encapsulation may reduce some processing overhead, but it won’t eliminate congestion, authentication delays or remote restrictions. Brief tests on iOS can produce conflicting results because of caching or differences in the destination. Keep the destination fixed and record connection setup separately from transfer performance. Use an existing HTTP or SOCKS5 endpoint only for the services it explicitly supports; don’t assume it can replace any tunnel protocol. For more on name resolution, see DNS and DNS over HTTPS settings, then use your current rules to determine where requests are handled.
WireGuard
A tunnel built with keys and virtual network addresses is not configured like a standard proxy with a password.
How a tunnel protocol differs from a proxy entry
WireGuard is designed to create a streamlined encrypted network tunnel. It uses a fixed set of cryptographic algorithms and identifies peers with public keys. It handles network-layer packets, so its configuration includes concepts such as interface addresses, peer keys and routing ranges—not just a proxy password. How WireGuard entries work in Shadowrocket also depends on the app’s traffic interception and rules. Don’t assume every option from a standalone tunnel configuration maps directly to a field in the app without checking.
Unlike protocols that use a username or UUID, WireGuard needs the local private key and remote public key to form the correct pairing. The remote side must also know the corresponding local public key and assign suitable addresses and reachable ranges. An Endpoint alone, or just the remote public key, isn’t enough for a complete connection. If you have a configuration file, first identify which details belong to Interface and which to Peer. Import them using an option supported by the current app, and keep the original file for comparison.
Keys, Endpoint and address fields
PrivateKey is a local secret; never share it in a public screenshot or support post. PublicKey in Peer usually refers to the remote public key, and the two must not be swapped. Some configurations also include PresharedKey, an additional shared secret that must match on both sides. This guide doesn’t show sample keys, to avoid confusing an illustration with usable credentials. When describing a problem, share only whether a field is present, whether import failed and the type of error. Never share real keys.
Endpoint is the remote address and UDP port used to reach the peer. Address usually refers to the address assigned to the local side of the tunnel; they serve different purposes in different address spaces. DNS specifies name resolution, while AllowedIPs in WireGuard associates address ranges with the peer and routing. If the remote server allows only one internal subnet, expanding the range on the client won’t add forwarding capabilities. The server-side routes, forwarding and return path must still be in place.
UDP, Keepalive and mobile networks
WireGuard typically uses UDP, so the network must allow data exchange between the client and the relevant Endpoint port. If it works on Wi-Fi but not cellular, the cause may be the UDP path, a changed address or network mapping—not just an invalid key. First check for a successful handshake, then test whether the actual traffic works. A handshake doesn’t guarantee that DNS, destination routing and the return path are correct. When accessing an internal subnet, check whether it overlaps with the current local network.
PersistentKeepalive helps maintain network mappings when needed, but a lower interval isn’t always more reliable. Frequent packets can increase wireless activity and battery use, and enabling it when it isn’t needed may offer no benefit. Set it according to the existing deployment requirements and observed idle disconnects; don’t apply one value to every situation. Also test behavior after the device locks, switches networks or wakes again. A successful test with the screen on doesn’t prove background stability.
MTU and when it matters
MTU indicates the size of packets an interface can carry. If encapsulated packets exceed the path’s capacity and the necessary feedback doesn’t return, you may see a successful handshake and small requests but larger responses that stall. This is one possible cause, not the first setting to change whenever things are slow. Check the route, DNS and routing first, then make limited adjustments based on the remote server’s guidance and record the original value. Setting MTU too low can increase fragmentation and packet count; setting it too high may leave the original problem unchanged.
If you need to access a clearly defined internal subnet and an administrator has provided a complete WireGuard configuration, its address and peer model can suit that use case. For general proxy traffic, confirm that the remote server actually provides the required forwarding rather than just a tunnel into an internal network. Speed and battery use still depend on wireless conditions, packet size, Keepalive and traffic volume. A valid setup requires a working handshake, routes, DNS and destination responses—not merely a tunnel protocol name in the configuration.
Hysteria2
QUIC-based transport needs a working UDP path, and bandwidth settings must reflect the actual connection.
Design trade-offs for unstable network paths
Hysteria2 uses a QUIC-based transport designed to handle data over high-latency or lossy paths. QUIC runs over UDP but can provide reliable streams, so “uses UDP underneath” doesn’t mean “application data is never guaranteed to arrive.” That doesn’t mean every weak network will get faster: protocol design can’t overcome an unreachable or heavily rate-limited UDP path, or an overloaded endpoint. Before choosing it, confirm that your existing server supports Hysteria2.
Don’t assume Hysteria2 is compatible with similarly named earlier protocols. Check the import format and authentication fields against the current app. Some configurations also include obfuscation or other extension parameters; use these only if the remote server enables the same mechanisms. Extra options aren’t general-purpose performance switches. Adding them on one side changes the connection and may cause it to fail. The app saving an entry doesn’t mean the remote server accepts that combination; test the full session.
Authentication, TLS and server names
Start by checking Address, Port, authentication details and TLS-related names. Authentication must come from the same existing configuration; don’t substitute credentials from a subscription URL. If the import process splits the details across fields, check that all of them were parsed. SNI and certificate names still matter: switching to QUIC doesn’t make certificate verification irrelevant. An incorrect device clock, a name mismatch or a misconfigured certificate can interrupt the connection before or after authentication.
If the remote configuration requires a specific obfuscation type and password, preserve them as provided and confirm that the current app supports those options. Don’t cycle through every obfuscation mode just because the network isn’t working; that can add new problems to the original one. Changing ports also requires the server to listen on the new port—clients can’t create a new endpoint on their own. If the source of the configuration is clear but the fields aren’t fully explained, get the missing details before comparing performance. Otherwise, you may be testing a misconfigured entry.
Bandwidth settings are not speed test results
Some configurations include settings for upload, download or congestion control. These describe sending behavior or expected network conditions; they don’t guarantee real-world speed, and higher values aren’t always better. Values above the connection’s sustainable capacity can increase congestion, packet loss and variation; values that are too low can restrict throughput. If the app offers automatic negotiation or a default, start with the server’s guidance. Adjust only after observing a repeatable issue and understanding the setting, and record every change.
Available cellular bandwidth varies with signal, location and network load. A short speed test’s peak may not be a suitable long-term setting. A Wi-Fi link’s advertised rate also isn’t the same as usable bandwidth to the server. Compare sustained throughput, not just the highest moment; upload capacity matters too because acknowledgements and control traffic need network resources. If a bandwidth change increases battery use or instability, restore the original value and verify the test conditions.
Performance checks and failure patterns on iOS
On some lossy paths, a suitable transport and congestion control may improve sustained transfers, but the result depends on both implementations and the network. Using more of the available capacity may also increase radio activity, processing and battery use; high throughput doesn’t automatically mean lower power consumption. Check short-page load time, long-transfer stability and reconnection after idle separately, comparing with other available entries under the same conditions. A single latency measurement doesn’t show how a QUIC session behaves overall.
If it fails only on one type of network, keep the entry unchanged and switch to another network available to you to see whether the UDP path is involved. If it fails on every network, check the address, port, authentication, certificate and additional parameters in order. If regular webpages work but one real-time app doesn’t, determine whether the issue is app traffic forwarding or whether QUIC was established in the first place. Hysteria2 is worth testing when it’s already available as a working option; it isn’t a universal fix that works without the right conditions.
Choosing for a specific use case and troubleshooting layer by layer
Start with the conditions you can verify and follow consistent checks to narrow down the issue.
Narrow down options using verifiable criteria
For everyday browsing and app use, start with an existing configuration that has complete settings and establishes sessions reliably. Then compare initial response and sustained transfers. For access to an internal subnet, focus on WireGuard addresses, routes and peer permissions. For UDP-dependent traffic, confirm that the protocol, remote server and current network all support the required forwarding. You can test existing options such as Hysteria2 on a weak network, but this doesn’t replace checking endpoint reachability. The remote server’s actual capabilities—not the protocol name—set the limits of your choices.
When battery life matters, observe idle connections, background retries and network changes over a normal usage period. On Demand controls when the connection starts; rules control where traffic goes. They’re related to protocol choice, but they’re not the same thing. Comparing protocol overhead is meaningful only when the right requests use the right path and the connection remains stable. If retries keep failing, resolve the cause first. A protocol with fewer fields may leave the same network problem untouched.
| Use case | Check first | What to compare |
|---|---|---|
| Short pages and everyday apps | Authentication, DNS and rule matches | Initial response, subsequent responses and reconnects |
| Sustained transfers | Remote server load and sustainable connection capacity | Stable throughput, variation and device temperature |
| Real-time interactive apps | UDP forwarding and two-way reachability | Latency variation, packet loss and recovery time |
| A defined internal subnet | Addresses, routes and return path | Destination reachability, overlapping subnets and DNS |
First confirm that the request actually uses the entry you’re testing
Under Config, rule order determines how requests are matched. The following is a Shadowrocket .conf rule snippet, not a complete configuration: domain suffixes go to PROXY, the listed private subnets go to DIRECT, and FINAL specifies the policy for everything else. Before using it, confirm that the policy references in your current configuration are valid and understand how FINAL affects traffic. Don’t replace your entire configuration just to test one domain. Save the original settings and test with the smallest possible scope.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
FINAL,PROXYIf the same request works under Direct but fails under Proxy, continue checking the remote connection; this doesn’t provide a final diagnosis of the whole network, as the two paths may use different DNS results and endpoints. If it fails under Config but works under Proxy, check rules and DNS association first. For the locations of Home, Config, Data and Settings, see the guide to English interface terms so you don’t look for protocol options on the wrong screen.
Keep a minimal troubleshooting record for each failure stage
First check whether the subscription was retrieved successfully and whether the entry is complete. Then check whether the address resolves and the port is reachable. Next verify Type, authentication and transport, followed by TLS and names. Only then check destination access and app capabilities. If the list itself is empty, the protocol connection stage hasn’t started; troubleshoot subscription retrieval or parsing first. If the handshake succeeds but there’s no destination response, check the server-to-destination path, destination restrictions and return traffic instead of repeatedly importing the same subscription.
Record the network type used on the device, the Global Routing setting at the time of failure, the selected protocol, whether the subscription was just updated and the reproducible failure stage. Keep the error category and field names with sensitive details removed. Don’t include real passwords, keys or full subscription URLs. Change one field with a confirmed mismatch per test and record its original value; if the change doesn’t help, restore it before checking the next layer. To compare networks, keep the server entry fixed. To compare entries, keep the network and destination fixed. This reduces interference from other variables.
When to stop changing settings and check the basics
If every protocol fails on the same network, check the device’s network, DNS and system permissions first. If only one entry fails, check its authentication and remote server status. If only one destination fails, check the rules and the destination itself. Don’t turn every issue into a protocol selection problem. For related questions, see the FAQ. To establish a connection for the first time, follow Getting Started and recheck permissions and switches. App availability, purchase and compatibility are covered on the App Store information page; check the App Store listing for pricing and system requirements.