Shadowrocket speed depends on the entire request path; low latency in Connectivity Test does not guarantee fast downloads. This guide helps users who can connect but experience slow access compare their local network, routing and protocols, route quality, and server load. Change one setting at a time, record the result, then decide whether to keep or revert it. We do not provide, sell, or recommend servers or subscriptions.
1. Tell Latency, Throughput, and Connection Failures Apart
“Slow internet” can mean at least three things: pages take a long time to load, downloads remain slow, or connections keep dropping. Slow page loads may involve DNS lookup, connection setup, or a remote server response. Slow downloads point more toward sustained throughput. Unstable connections call for checks for packet loss, network switching, or dropped connections. Describe what is happening before changing protocols.
This flow is a logical breakdown for troubleshooting, not a fixed sequence for packet handling. DNS lookups can happen at different stages. Connectivity Test on Home checks whether a test destination is reachable and reports timing based on the selected test method. It is not a substitute for a file download test and cannot confirm that every website or transport method is working properly.
- Long wait on first load: Note whether the first visit differs significantly from later visits, and check DNS resolution and connection setup.
- Consistently slow downloads: Use the same file from the same destination and observe it for at least 30 seconds. Don’t judge speed from the initial burst.
- Frequent stalls: Note whether they happen just after switching from Wi-Fi to cellular or waking the screen from a locked state.
- Only one site is slow: Check that site’s routing, resource servers, and account-level speed limits first. Don’t assume the client is responsible.
Keep units in mind: 8 Mbps is about 1 MB/s, before protocol overhead. Comparing Mbps on a speed test with MB/s in a download screen can make a normal difference look like a slowdown.
2. Establish a Baseline on Wi-Fi and Cellular
First confirm that the device has a working internet connection, then test the proxy route. Choose a baseline destination that is directly accessible on the current network; don’t use a destination that normally requires a proxy for a direct-connection comparison. Pause large transfers on other devices and avoid running multiple speed tests at once.
-
Record the Current Settings
On Home, note the selected server and Global Routing mode. In Config, note the active configuration. Change only one condition at a time so you can return to the same baseline after each test.
-
Pause Automatic Connections
Check Settings → On Demand. If automatic triggers are enabled, note them and temporarily turn off the relevant switches. Then return to Home, turn off the connection, and make sure it isn’t re-established during testing.
-
Test the Direct Connection
On Wi-Fi, visit the baseline destination and record load time, sustained download speed, and any interruptions. Repeat three times and keep all three results instead of selecting only the fastest.
-
Switch Networks
Turn off Wi-Fi and confirm the device is using cellular, then repeat the same test with the same destination. Keep an eye on data usage; don’t time the test while switching networks.
-
Reconnect
Return to Home, select the original server, and turn on the connection. Run Connectivity Test first, then test access to the same destination. Restore the original On Demand settings after completing all comparisons.
If Wi-Fi remains slow with the connection off but cellular is fine, check wireless signal strength, router upload usage, and local network quality first. If both networks work normally without a connection, but one slows down with the same server, investigate differences in the route from the access network to that server. This alone doesn’t prove server load is the cause.
3. Check Global Routing and the Rules Actually Applied
A slow connection doesn’t necessarily mean traffic is going through the selected server. Home → Global Routing determines the routing mode; rules in Config only affect traffic when that mode uses them. Check the mode before reviewing rules so you don’t edit a configuration that isn’t active.
| Mode | Why It Matters for Troubleshooting | What to Watch For |
|---|---|---|
| Proxy | Use it to compare the proxy route while reducing variables caused by routing rules. | Use only for a brief test, then restore the original mode. |
| Direct | Use it to observe the results of a direct connection. | This does not disconnect the system VPN and cannot replace a baseline test with the connection turned off. |
| Config | Routing behavior is determined by the rules in the current configuration. | Check the active configuration, rule order, and final policy. |
| Scene | Routing behavior depends on the configured scene. | Check which scene is actually triggered to keep test conditions consistent when the network changes. |
The examples below demonstrate rule syntax; they are not recommendations to replace your existing configuration. DOMAIN-SUFFIX matches a domain and its subdomains; IP-CIDR matches an IPv4 range; GEOIP uses an IP geolocation database; FINAL handles requests that did not match earlier rules. Rules are evaluated in order, so a broad rule near the top can prevent more specific rules below it from matching.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXYexample.comis a domain used for illustration, not a speed test destination.192.168.0.0/16is a private address range and does not include every private network.GEOIP,CN,DIRECTdoes not mean “all Chinese-language websites connect directly.” A domain’s language and the location associated with its server IP are not the same thing.- Check the destination domain and the policy actually applied in the request log. If switching to Proxy fixes the issue but returning to Config brings it back, check the rules and their policy targets first.
- A single webpage may request images, video, and scripts from multiple domains. The main domain working does not mean every resource takes the same route.
4. Verify Protocol Settings; Don’t Guess at Speed Tweaks
Open the edit screen for an existing server on Home and check its Type, server address, port, and authentication details. Parameters for Shadowsocks, VMess, VLESS, Trojan, Hysteria2, and WireGuard are not interchangeable. The protocol must match the remote configuration; changing Type alone is not a valid way to compare protocol speeds.
For example, if an existing configuration specifies port 443, first confirm which transport the remote server actually listens on. Reachability over TCP 443 does not prove UDP 443 is reachable, and using the same port number does not mean the same protocol is in use. Hysteria2 is based on QUIC and requires UDP. WireGuard also uses UDP, so network restrictions on UDP can affect connections and sustained transfers.
- TLS and server name: For configurations using TLS, check the server name and certificate requirements specified by the remote server. Don’t disable certificate verification to mask a configuration error.
- Transport path: If an existing configuration uses a transport such as WebSocket, its path and Host must match the remote settings. Being able to open a regular webpage does not mean the proxy transport endpoint is reachable.
- Hysteria2 bandwidth settings: If the configuration includes upload and download bandwidth values, set them according to the current network and the remote service’s instructions. Raising the values blindly won’t guarantee faster speeds; overly optimistic send rates can increase queuing or packet loss.
- WireGuard MTU: Keep a known working value to start. Consider a path MTU issue only if small requests work but large ones stall. For example, temporarily changing 1420 to 1380 can be a useful comparison, but 1380 is not a universal best setting.
- DNS: If domain access fails but a connection to an existing IP works, check the DNS settings actually used in Config. Don’t change DNS, rules, and protocol settings at the same time, or you won’t know which change made a difference.
5. Use Comparisons to Separate Route Quality from Server Load
Poor route quality and server load can both show up as slower speeds in the evening, so time of day alone isn’t enough to draw a conclusion. Keep the destination fixed, then hold the server constant while switching access networks. Next, hold the access network constant while switching to another server you already have. Repeat each test at least three times, leaving gaps between runs to avoid competing for bandwidth.
| What You Observe | Most Likely Cause to Check | Next Test |
|---|---|---|
| The same server is slow only on Wi-Fi | Local wireless conditions or the route from that access network to the remote server. | Retest closer to the router, then compare with cellular. |
| The same server is slow on both networks, but other existing servers work normally | That server’s ingress, egress, or resource limits. | Try two other destinations and compare different times of day. |
| All servers are slow when accessing the same site | The destination, its resource servers, or a route shared by all tests. | Keep the server unchanged and test a separate destination. |
| Connectivity Test is normal, but sustained downloads are slow | Limited throughput, packet loss, remote speed limits, or the destination’s response capacity. | Record sustained speed instead of comparing only test duration. |
| Frequent timeouts and highly variable results | Wireless interference, congestion, packet loss, or an unstable remote server. | Compare direct local connections first, then check the server route. |
Low latency means a short request has a fast round trip or connection setup; bandwidth, packet loss, and concurrency limits can still slow large downloads. Conversely, higher latency on a distant server does not necessarily mean sustained downloads will be slow. Two speed test screenshots taken without controlling the destination, time, and network conditions cannot prove that one protocol is always faster.
If performance degrades noticeably only during peak hours and the direct local baseline is normal, share the symptoms, time period, access network, and redacted test results with your own service provider. Server CPU, egress bandwidth, and connection counts are remote-side metrics; you can’t infer them from latency in the client alone.
- Keep the lowest, highest, and middle result from each set. Pay attention to the range of variation instead of recording only the best result.
- Video apps may cache content or automatically lower video quality, so smooth playback over a short period does not prove sustained throughput has recovered.
- A speed test destination may use a different route from your everyday destinations. Retest in the app where the problem actually occurs.
6. Start with the Error Type
The following are standard error strings that may appear when diagnosing network connections. The exact text depends on the request log; not every test will show the same message. An error describes the stage that failed, not the final root cause on the remote end. Recording the exact message and when it appeared is more useful than repeatedly toggling the connection.
Error: i/o timeout
Cause and next steps: A network read or write did not finish within the allotted time. Possible causes include an unreachable route, packet loss, or no response from the remote server. Keep the server fixed and switch between Wi-Fi and cellular, then verify the remote address, port, and transport. Don’t assume a timeout means insufficient bandwidth.
Error: connection refused
Cause and next steps: The connection request was explicitly rejected. This commonly happens when no service is listening on the destination port or an intermediate device actively refuses the connection. Check the address and port in your existing configuration and ask your service provider to confirm that the port is listening. Changing MTU usually won’t fix this error.
Error: no such host
Cause and next steps: The current lookup did not return the required domain record. The domain may be mistyped, or the DNS environment may be having problems. Check the server hostname, switch access networks and test again, then review the DNS settings in your current configuration. Don’t permanently hardcode an IP address without confirming it is correct.
If there’s no error and the only issue is low speed, continue with sustained throughput comparisons instead of looking for an error that isn’t there. Before sharing logs, redact passwords, Private Key values, authentication tokens, and subscription URLs. The protocol type, a redacted destination, port, network type, and time are usually enough to describe the issue.
7. Common Questions and Wrapping Up
Why are downloads slow when latency is only a few dozen milliseconds?
Connectivity Test and sustained downloads measure different things. On Home, keep the same server, use a fixed file, and observe it for at least 30 seconds. Check that you aren’t mixing up Mbps and MB/s, then test another destination to distinguish a single-site speed limit from a throughput issue on the route.
Why does Proxy work normally while Config stalls?
First, confirm that both tests use the same mode in Home → Global Routing. Then, in Config, check the order of DOMAIN-SUFFIX, IP-CIDR, GEOIP, and FINAL in the active configuration. Use the request log to confirm the policy actually applied; don’t delete all the rules.
Do I have to keep restarting my device when it stalls after switching networks?
Wait for the new network to stabilize, then turn the connection off and back on in Home so it can establish a connection over the new route. Check whether Settings → On Demand triggered an unexpected automatic connection. Only attribute the issue to network switching after you can reproduce it under consistent conditions.
Will switching to Hysteria2 always make things faster?
No guarantee. First confirm that your remote server supports the protocol and that all parameters are correct. Then check that your current network can carry the required UDP traffic. Different ingress and egress routes introduce additional variables, so keep the destination, access network, and test time consistent; the protocol name alone isn’t enough to judge performance.
Which settings should I restore after troubleshooting?
Restore the original Global Routing mode, active configuration, and On Demand settings. Undo any MTU or DNS changes that didn’t help. Finally, retest with your everyday app and record any change that worked along with its result, so temporary test settings aren’t left in place.
The goal of troubleshooting is a conclusion you can reproduce and verify, such as “direct local access is normal, but sustained downloads on the same server are slow on one access network,” not a vague claim that “the client is slow.” Keep that conclusion and address the relevant layer to avoid unnecessary changes.