If Shadowrocket is slow after connecting, keep the destination, server, and test time consistent, then compare Wi-Fi with cellular. Next, check the routing mode, existing protocol settings, route fluctuations, and server load. This guide is for users who already have a provider configuration or subscription. It distinguishes low connection latency, fast page loads, and sustained download speed, using one-variable-at-a-time tests to narrow down the cause rather than changing every setting based on a single Ping result.
1. Separate connection time, time to first byte, and sustained throughput
Start with this: a low Ping does not mean high bandwidth, and turning the connection on does not guarantee that a request is taking the expected proxy route. Before troubleshooting, note the current server on Home, the current mode under Global Routing, and the active configuration in Config. Keep a copy of the configuration, and change only one variable at a time.
If a page takes a long time to show content, the cause may involve DNS, connection setup, or the destination server's response. If the page loads quickly but large files download slowly, the issue is more likely sustained throughput. If video starts normally but stalls during playback, check for fluctuations, packet loss, or rate limits at the destination. These symptoms can overlap; do not assume they all mean the protocol is too slow.
- Choose one page or file you can access and test repeatedly. Use the same destination each time.
- Record connection time, time until the page starts to appear, and speed after the transfer stabilizes.
- Record whether you used Wi-Fi or cellular, the server name, the Global Routing mode, and the test time.
- Repeat each set of tests three times and record any failures. Do not keep only the fastest result.
2. Check the local network: compare Wi-Fi with cellular
Keep the same server, destination, and configuration; change only the network connection. If Wi-Fi is slow but cellular works normally, the difference is related to the local network or its route to the server, but that alone does not mean the router is faulty. Wireless interference, saturated upload bandwidth, network policies, and routing differences between carriers can all produce this result.
- Run three tests over Wi-Fi and record the results. Move closer to the access point to rule out a weak signal.
- Turn off Wi-Fi and confirm that cellular is active. Disconnect and reconnect Shadowrocket so the new connection uses the cellular route.
- Keep the server and destination the same, then run another set of tests. Downloads use cellular data, so check your data allowance first.
- Switch back to Wi-Fi and test once more. If the issue repeatedly occurs only on one access point, check that network for congestion or restrictions.
To check whether the regular network connection is working, choose a destination that is normally accessible directly, disconnect temporarily, and compare. Traffic will then use the system's regular network route. First, note and temporarily disable automatic connection conditions in Settings → On Demand to prevent an automatic reconnect during the test. Restore them afterward. Do not use a destination that cannot normally be accessed directly to diagnose the local network.
| Repeated pattern | Check first | Next step |
|---|---|---|
| Wi-Fi is slow; cellular works normally | Wireless quality, network congestion, route to the server | Try another access point on the same Wi-Fi network, keeping the server unchanged |
| Both networks are slow, but a direct-connection test works normally | Proxy route, server, or destination | Check the routing mode, then compare servers you already have |
| Both direct and proxy connections are slow | Local network activity, destination response | Pause background transfers and add a destination that can be accessed directly |
3. Check routing: make sure you are testing the same route
Check the current mode under Home → Global Routing. Config applies rules to requests; Proxy provides a proxy-route comparison; Direct provides a direct-connection comparison; Scene applies the selected scene, so check the specific scene when testing. Do not combine speed results from different modes into one average.
In Config, rules are evaluated in order. DOMAIN-SUFFIX matches domain suffixes; IP-CIDR and GEOIP handle the corresponding IP conditions; FINAL handles requests that did not match earlier rules. A page may look like a single destination, while its images or media use other domains and follow different policies. Checking the request log for the destination and matched policy is more reliable than checking only whether the home page opens.
- Before briefly switching to Proxy to compare the same destination, note the original mode. Restore the original setting when the test is done.
- If Proxy works normally but Config is slow, check the matched rule, policy group, and selected policy first. Do not immediately change protocol settings.
- Reconnect after changing modes or servers; existing long-lived connections can affect the results.
- If only the first page load is slow and subsequent transfers are normal, check DNS lookup and connection setup. Do not change DNS, rules, and servers at the same time.
4. Check protocol settings: verify parameters instead of treating a protocol change as a universal fix
On Home, open the edit screen for the current server and compare its address, port, and protocol settings with your existing configuration, one item at a time. A port is not a speed setting; changing an arbitrary service to 443 will not make it faster. The protocol, port, and server-side listener must match. A resolvable address does not prove that authentication and encryption settings are correct.
| Protocol | What to check | What to avoid |
|---|---|---|
| Shadowsocks | Server address, port, password, encryption method, and any configured plugin parameters | Changing the encryption method or password unilaterally |
| VMess / VLESS | User ID, transport method, and settings such as the server name when TLS is enabled | Guessing a transport method or path and changing it |
| Trojan | Password, port, and TLS server name | Disabling certificate verification to conceal a handshake problem |
| Hysteria2 | Authentication details, TLS settings, and whether UDP is reachable over the current network | Treating a configured bandwidth value as a route guarantee |
| WireGuard | Keys, peer address, port, and tunnel-related settings | Changing the MTU or replacing keys without confirming the cause |
Hysteria2 and WireGuard depend on UDP transport conditions. Actual transport for other protocols also depends on the configuration. If the same UDP configuration repeatedly times out on one Wi-Fi network but works over cellular, first check whether that network restricts UDP. Comparing protocols makes sense only if the server already provides another compatible configuration; changing the protocol name in the client alone is not enough.
5. Check the route and server: compare Ping, test times, and sustained transfers
Ping generally measures round-trip latency, not sustained throughput. Some servers do not respond to ICMP, so a Ping timeout can occur even when an application connection works. A TCP connection test covers only the connection stage on a specific port; it is not a file download test. When using Connectivity Test on Home, check the test method and destination first. Do not rank results from different methods as if they were directly comparable.
Route quality depends on the path from your network to the server and from the server to the destination. Server load can involve CPU usage, available bandwidth, connection count, or rate limits. A single client-side measurement usually cannot distinguish these causes completely, so record the result along with the time, network, and destination.
- Keep the server fixed and compare test times: Repeat the same test during the problem period and at another time. Slower results only at certain times suggest congestion or load, but do not prove which end is congested.
- Keep the destination fixed and compare servers you already have: Compare only configurations you already have and can use normally. If one server is consistently slow while others work normally, the issue is more likely limited to that server or its route.
- Keep the server fixed and compare destinations: If one destination is slow while others work normally, check for rate limits at the destination, route differences, or different matched rules.
- Observe sustained transfers: Record the stable transfer rate and the number of stalls. Low latency with frequent stalls can still indicate packet loss, retransmissions, or server queuing.
If all destinations slow down in the evening, the issue persists over cellular, and another existing server works normally, share the test records with your provider so they can check load and routing. This still cannot distinguish insufficient server resources from congestion at a shared exit; further server-side monitoring is needed. Do not choose a server solely because it is geographically closer or has the lowest Ping.
6. When errors appear: resolve connection failures before testing speed
Repeated errors may mean the test never reached a stable transfer stage. The examples below are common snippets from network logs. Exact wording depends on the underlying connection and source of the error, and not every protocol displays the same text. Refer to an example only if it appears in your own logs; do not infer a fault from an error that was not shown.
Error: i/o timeout
Cause and fix: A network read or write did not complete in time. The cause may be an unreachable destination, packet loss, or no response from the other end. Keep the server unchanged, compare Wi-Fi with cellular, and check whether the timeout occurs during connection setup or transfer.
Error: connection refused
Cause and fix: The remote end or an intermediate device rejected the connection request. This is not simply a bandwidth problem. Check that the address, port, and service are still valid, and ask your provider to confirm the service status on that port.
Error: certificate has expired
Cause and fix: Certificate validation indicates that the certificate has expired; an incorrect device clock can also cause this. Check the system date and time first, then ask the service maintainer to verify the certificate. Do not disable certificate verification as a way to improve speed.
If your subscription address or port was recently changed, find the relevant subscription on Home and update it, then check which server is selected. After updating, confirm that Config and Global Routing still match the original test conditions. Updating a subscription only syncs the existing configuration; it does not guarantee route performance and should not be another variable changed during repeated speed tests.
7. Common questions and restoring your settings
Why is my download slow when Ping is only a few dozen milliseconds?
Latency and throughput are different metrics. Keep the current server and destination, run a sustained transfer, and record the rate unit, stalls, and time of day. Then compare with another destination. Do not use Ping alone to rule out bandwidth limits or rate limiting at the destination.
Does slow Wi-Fi but fast cellular mean I chose the wrong protocol?
Not necessarily. Keep the protocol and server the same, switch networks, and reconnect. If the difference consistently returns, check Wi-Fi congestion, UDP restrictions, and route differences. Avoid changing the protocol and network at the same time.
Should I change the MTU or turn on every option?
Keep the original values first. Small requests working while large transfers stall is a clue, but does not prove an MTU problem on its own. Change one setting and retest only when you have parameters that match the current tunnel or a clear diagnostic reason.
Which settings should I restore after testing?
Restore the original server, Global Routing mode, and Config. In Settings → On Demand, restore the original automatic connection conditions, then reconnect and check your usual destinations. Keep the final working settings before deleting test records.
When reporting the issue to your provider, include the network, server identifier, protocol, test times, destination type, and repeated results. Before sharing screenshots or logs, hide subscription tokens, passwords, user IDs, and keys. If you still cannot distinguish a route issue from server load, say “client-side comparisons are inconclusive” rather than just “slow speed” to make further diagnosis easier.
- Lead with a reproducible observation, such as “the same server stalled on all three Wi-Fi tests, while all three cellular tests worked normally.” Do not present a guess as a confirmed cause.
- State whether you used Config or Proxy and whether you reconnected during testing, so both sides are comparing the same route.
- Keep the original error text and timestamp, but do not share a complete subscription link or authentication details.