Latency after connecting to Shadowrocket, the time it takes a website to load initially, and sustained transfer speed are three different metrics. This guide is for users who already have their own service provider and subscription, can import a configuration, but are experiencing slow access. Keep test conditions consistent, then check the node, route, protocol settings, and local network in turn. Use connection logs to identify where the problem occurs.
1. Tell high latency, slow initial loads, and slow transfers apart
Connectivity Test on Home checks connectivity and response time using the selected test method; it does not measure route bandwidth. Results can vary with the test address, method, and website you visit. A lower latency in the list does not guarantee smooth video playback or faster large-file transfers.
Before you begin, describe the symptom: Are all websites slow, or just one domain? Is the initial load delayed, or does loading stall halfway through? Does it happen all day or only at certain times? Don’t update a subscription, change DNS, switch protocols, and change networks all at once. Even if things improve, you won’t know which change helped.
| What you observe | Check first | What this can tell you |
|---|---|---|
| Slow on the first load, then normal | DNS, connection setup, TLS handshake | Caching may affect the second result |
| Pages load quickly, but large files transfer slowly | Route throughput, congestion, destination throttling | Low latency does not mean high bandwidth |
| Only one website is slow | Rule matching for that domain and the destination service | This alone does not mean the entire node is down |
| All requests time out | Local connectivity, node reachability, authentication settings | First confirm that a connection can be established; then investigate speed |
Keep units consistent, too. 8 Mbps is about 1 MB/s, before protocol overhead. If one page shows Mbps and another tool shows MB/s, you can’t compare the numbers directly. For each test, record the unit, time, and destination.
2. Set a consistent baseline and confirm the route in use
In Shadowrocket, Home is for connecting and selecting a node, Config is for configuration files, and Settings is for app preferences. When troubleshooting speed, first confirm the selected node and Global Routing, then check the active configuration. The system VPN indicator only means a tunnel is established; it doesn’t mean every request goes through the selected proxy node.
-
Record the current settings
On Home, note the selected node and current Global Routing value. In Config, confirm which configuration file is active. Save any relevant original settings, but don’t include passwords or full subscription URLs in your notes.
-
Keep the routing mode consistent
Go to Home → Global Routing. Use Proxy to compare proxy routing and Direct to compare direct access; Config routes traffic according to its rules. If you’re using Scene, first check the policy associated with that scene. Don’t treat results from different modes as one test set.
-
Check automatic connections
Go to Settings → On Demand and review the existing conditions. If you need to disconnect manually during testing, you can temporarily turn off On Demand. Note the original setting so the system doesn’t reconnect automatically and invalidate the direct-access comparison.
-
Repeat the same test
On Home, run Connectivity Test three times without changing the test method, and record each result. Then visit the same destination and note the initial load and sustained transfer. Don’t run multiple high-traffic tasks at the same time.
-
Restore the original settings
Restore temporary changes after each comparison. When testing is complete, return Global Routing, the configuration file, and On Demand to their original settings. Don’t leave diagnostic Proxy or Direct settings in place.
3. Check nodes and routes: change one variable at a time
A node is a connection endpoint. The route is the actual path from your current network to that endpoint and then to the destination service. A region label in a node name doesn’t describe the full route or its current load. The same node can perform differently on home broadband and cellular data, often due to the access network, route congestion, or UDP availability.
- Compare only nodes you already have: On the same Wi‑Fi network, with the same Global Routing mode and destination, switch from existing node A to existing node B. Keep everything else unchanged and record connectivity and sustained transfer performance for each.
- Account for time of day: If speeds drop only in the evening, repeat the same tests at another time. A single result can’t distinguish temporary congestion from a persistent issue.
- Compare destinations: If other destinations work on the same node and only one service is slow, check the rules for that destination and the service status. Don’t assume the whole node is unavailable.
- Check for subscription changes: On Home, pull down to refresh your own subscription, then check the selected entry again. Subscription contents may change the address, port, or entry, so earlier notes may no longer apply.
This is an example of how to record results, not data measured by this site: for the same destination and time period, node A on Wi‑Fi has three response times of 80 ms / 85 ms / 82 ms but transfers at only 0.5 MB/s. Node B responds in 120 ms / 125 ms / 122 ms and transfers at 3 MB/s. This illustrates why response time and sustained throughput need to be judged separately; ranking nodes by lowest latency alone can be misleading.
If all existing nodes are slow on Wi‑Fi but work normally on cellular data, focus on the local network. If only one node fails on both networks, check its endpoint and settings. When reporting an issue to your own service provider, include the time, access network, a redacted node identifier, and the error text. That’s more useful for diagnosis than simply saying “it’s slow.”
4. Check protocol settings: confirm the connection before optimizing
Don’t change Type at random to “speed things up.” Server configurations for Shadowsocks, VMess, VLESS, Trojan, Hysteria2, and WireGuard aren’t interchangeable. Use only protocols supported by the server with complete settings provided. Changing the protocol name on an existing entry usually makes the connection fail.
| Protocol | What to check | Common misdiagnosis |
|---|---|---|
| Shadowsocks | Address, port, encryption method, password | An authentication mismatch mistaken for a slow route |
| VMess / VLESS | UUID, transport, TLS, Host, Path | A transport or path mismatch prevents the connection from being established |
| Trojan | Password, port, TLS, SNI | Incorrect SNI mistaken for a general timeout |
| Hysteria2 | Authentication, TLS, SNI, UDP reachability | The access network restricts UDP; repeated retries don’t help |
| WireGuard | Key, Endpoint, address, Allowed IPs, MTU | Handshake succeeds, but routing or large transfers remain problematic |
The port must match your existing configuration. If the server uses 8443, don’t replace it with 443 just because that port is common; the port number doesn’t indicate speed. Check TLS SNI and certificate validation against the server’s requirements. Don’t hide a settings error by disabling certificate validation.
Hysteria2 and WireGuard rely on UDP. If a connection fails on one Wi‑Fi network but the same entry works on cellular data, check the network conditions first; one failure doesn’t prove the protocol is unsuitable. There’s no single “best” MTU for every network either. Change it only when there’s a clear sign—such as small requests working while large transfers stall—and make one change at a time, following your existing configuration instructions and keeping the original value.
Error: connection refused
Cause and fix: The destination or an intermediate device explicitly refused the connection. The port may not be listening, or an access policy may be blocking it. Check Address and Port, and ask your own service provider to confirm the endpoint status. Repeatedly changing DNS usually won’t resolve a refused connection.
Error: i/o timeout
Cause and fix: An operation didn’t complete in time. The issue may involve the route, the destination’s response, or UDP reachability. Use the connection stage shown in the error to guide your checks, and compare Wi‑Fi with cellular data using the same entry. Don’t change the password based on a timeout alone.
Error: tls: handshake timeout
Cause and fix: The TLS handshake didn’t complete in time. Possible causes include packet loss, endpoint status, or handshake settings. First check the port, TLS, and SNI, then compare different access networks. Disabling certificate validation is not a general-purpose fix.
These are examples of error text that may appear in connection logs; the surrounding message and context may differ. Keep the full relevant log lines and distinguish a failed connection to the endpoint from a failed request to the final destination. Before sharing, remove authentication details, subscription tokens, and any personal access records that aren’t needed.
5. Check your local network, DNS, and rule matching
Start local network troubleshooting with the smallest possible changes. Keep the node the same and compare Wi‑Fi with cellular data from the same location; then retry near the router on the same Wi‑Fi network. If a public Wi‑Fi network requires web-based sign-in, complete that step first. Weak signal, other devices using upload bandwidth, or router congestion can all slow connections. Reinstalling the app won’t fix these issues.
The diagram above is a simplified troubleshooting flow; DNS resolution may be involved at several stages. When Global Routing is set to Config, check the rule order in the active file under Config and use the connection logs to confirm which policy was actually used. Rules are generally evaluated from top to bottom, and the first match affects the request’s route. A common testing mistake is assuming a website uses a proxy when it actually matches Direct.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYThis snippet illustrates matching syntax; it is not a complete configuration you can use as-is. DOMAIN-SUFFIX matches a domain suffix; IP-CIDR matches an IP range, and no-resolve in the example means not to trigger a domain lookup for that rule; GEOIP checks an IP against a geographic database; FINAL handles requests that haven’t matched an earlier rule. The policy referenced by PROXY must also be available in the active configuration.
- Only domain-based access is affected: Check whether DNS resolution fails and whether the result makes sense for your current network. Opening an HTTPS site directly by IP address isn’t a reliable workaround; its certificate and virtual host may depend on the domain name.
- Config is slow, but Proxy works: Focus on the destination’s rule match, DNS path, and policy selection rather than immediately switching nodes.
- All network activity is slow: Check for concurrent transfers, such as system updates or cloud sync, on your device or the same network, then run the test again.
- Slow only in one Wi‑Fi location: Check signal strength and interference first. If you switch bands, keep the destination and node unchanged so you can tell whether the wireless link made a difference.
6. Narrow down the cause using comparison results
By the end of troubleshooting, you should be able to describe the problem in terms of a specific condition, rather than having a long list of temporary changes. For example, “UDP connections time out only on my home Wi‑Fi with the same node and destination” is more useful than “I changed a lot of settings and it’s still slow.” Unless you have evidence of a damaged configuration, there’s no need to delete the subscription or rebuild every rule first.
The test shows only a few dozen milliseconds of latency. Why does video still stutter?
Connectivity Test response time doesn’t measure sustained throughput to a video destination. On Home, keep the node unchanged, confirm Global Routing and the rule matched by that destination, then observe sustained loading. If only that service stutters, check its route and any server-side limitations.
Why does switching to cellular data fix the problem?
This shows that the same configuration can work under at least one other access condition. Keep the node and protocol settings unchanged, then check Wi‑Fi sign-in, signal strength, concurrent traffic, and UDP availability. Don’t change the entire configuration at once.
It got slow right after I updated my subscription. Should I delete it and import it again?
First check the selected entry on Home, then verify its updated address, port, and protocol settings, and confirm that Global Routing is still set to the same mode. If an existing entry changed, find out what changed first. Deleting and importing it again may remove your notes without fixing an endpoint issue.
The connection turns back on every time I disconnect. How can I test direct access?
Go to Settings → On Demand and review the conditions. Temporarily turn it off, then disconnect manually. Restore the original setting after comparing local networks, and don’t mistake an automatic reconnection for a failed disconnect.
What information should I include when reporting an issue?
Include the time, Wi‑Fi or cellular network, Global Routing mode, a redacted node identifier, protocol type, three Connectivity Test results, and the relevant error lines. Don’t post a full subscription URL, password, UUID, or private key in public feedback.
Restore the routing mode, On Demand, and any other settings changed during troubleshooting, then test the original destination again. If the issue is resolved, keep a record of the change that helped and your comparison results. If it persists, list the layers you’ve ruled out and continue investigating the endpoint, route, or local network.
Getting the App and Purchase Information
Shadowrocket is a closed-source commercial app sold as a one-time purchase through the App Store, primarily for iPhone and iPad. Check the App Store listing for system requirements, compatibility, and purchase availability. Buying the app does not include a network service plan. This site does not provide, sell, or recommend nodes or subscriptions. If you need to verify the app, start with the authenticity check guide; for basic connection steps, see the tutorial.
Verify the App View the Tutorial