Slow speeds after connecting with Shadowrocket should not automatically be blamed on the app or protocol. This guide assumes you already have a provider and subscription. Start with consistent test conditions, then compare nodes, routes, protocols, and your local network one at a time. You’ll learn to distinguish latency, throughput, and connection failures, keep reproducible test records, and decide whether to check your configuration, switch networks, or contact your provider.
Establish a baseline: low latency doesn’t mean fast downloads
A latency test measures response time using a particular probe; throughput measures how much data can be transferred over time. They measure different things. A fast response in the node list doesn’t prove that the route to your destination, sustained transfer rate, or evening performance will be better. One timeout doesn’t prove a node is consistently unavailable, either.
On Home, check the current connection status, selected node, and Global Routing. Record the test method, and don’t rank results from different probe methods together. Authorization to establish a connection doesn’t mean the remote service has been verified with a complete request.
- Pause high-bandwidth transfers on other devices and apps, and choose the same destination page or test resource for each run.
- Keep Global Routing, the node, and the access network constant. Run each set of tests three times and record the range, not just the fastest result.
- Record “slow to open,” “slow after transfer starts,” “stalls mid-transfer,” and “won’t open at all” as separate symptoms.
- Change only one variable per round. After switching, reconnect and repeat the same request to avoid interference from an existing connection.
Large-file tests use data. On cellular, check your plan allowance first. The number of tests suggested here is a troubleshooting method, not a performance benchmark or speed guarantee.
Layer 1: Compare existing nodes and rule out a single-node issue
On Home, run latency tests on your existing nodes. Keep the test method consistent, note consecutive results, and verify them with a real request. If just one node keeps timing out while others reach the same destination, first check that node’s address, port, credentials, and server status. If all nodes have trouble, look for shared factors instead of changing settings at random.
| Observed result | What it may indicate | Next step |
|---|---|---|
| One node repeatedly times out | The issue may be isolated to that endpoint or the route to it | Check the address, port, and service status provided by your provider |
| Latency is stable, but transfers are slow | The endpoint responds, but throughput may still be limited | Compare sustained transfers using the same resource |
| All nodes are slow at the same time | A shared route or local network issue may be involved | Keep the node fixed and switch between Wi-Fi and cellular |
| Only one website is slow | The issue may be specific to the destination service or route | Check which rule matches the request and its actual outbound route |
A region or label in a node’s name doesn’t prove its actual route; two differently named nodes may share an exit. Treat node labels as identifiers, not evidence that routes are independent. If the subscription needs updating, use the update action for the existing Subscribe item. Get the subscription URL from your provider, then check whether the selected node changed after the update.
Takeaway: Keep one node as a repeatable baseline
Choose one existing node that can reliably complete the same request and use it as your baseline. After changing any setting, test against the same destination again. If the baseline slows down too, check for shared factors first.
Layer 2: Track route conditions over time and distinguish congestion from destination limits
Bottlenecks can occur between your device and the node, or between the node and the destination service. If all requests slow down at certain times, shared route load may be a factor. If only one site is slow, consider destination-side rate limits, content delivery routes, or a service issue. A single speed test can’t identify exactly where congestion occurs.
Use the same device, node, and destination, and record one set of results during the problem and another during a quieter period. If you use different resources, file size, cache hits, and remote limits can all change the results, making comparisons less useful. Don’t run multiple speed tests at once; they compete for the same bandwidth.
- Time: Record the local time and time zone so your provider can compare them with service logs.
- Access network: Note whether you used Wi-Fi or cellular, and whether you switched networks during the test.
- Test details: Record the node label, protocol, and destination hostname. Don’t include passwords or the full subscription URL.
- Metrics: Record latency, number of timeouts, time until the page starts responding, and sustained transfer speed separately.
- Units: Check whether the reading is in Mbps or MB/s. Using decimal units, 8 Mbps is about 1 MB/s; actual transfer rates are also affected by protocol overhead.
If speeds repeatedly drop at the same time under the same conditions, send your records to your provider and ask about endpoint load and route conditions. Repeatedly changing DNS or importing the same subscription again won’t directly resolve remote congestion. If a speed-test target works but a service website doesn’t, troubleshoot the actual service request.
Layer 3: Verify protocol and transport settings instead of guessing
When entering details manually via Home → Add Server, or checking an existing node, make sure the protocol, port, credentials, transport, and TLS settings match the information from your provider. A port is just an endpoint setting: use 443, for example, only if your provider specifies it. Don’t replace every node’s port just because 443 is commonly used for HTTPS.
| Protocol | Check first | Speed troubleshooting notes |
|---|---|---|
| Shadowsocks | Address, port, encryption method, password | A mismatched method or password can cause requests to fail; an open port alone isn’t enough |
| VMess / VLESS | UUID, transport, TLS, and provider-specified Host and path | VMess and VLESS aren’t interchangeable by switching types alone; transport settings must match the server |
| Trojan | Password, TLS, Server Name | Fix domain or certificate validation errors in the configuration; don’t disable validation to force a connection |
| Hysteria2 | Authentication details, TLS, UDP reachability | Based on QUIC; connections may fail or become unstable if the access network restricts UDP |
| WireGuard | Keys, endpoint, address, and routing-related settings | Uses UDP; also check whether the server receives traffic and whether the return path works |
Hysteria2 may perform better under some packet-loss or high-latency conditions, but results depend on the end-to-end route and server configuration. That doesn’t mean it will be faster on every network. Don’t guess bandwidth settings or copy another protocol’s port, credentials, or transport settings.
Error: connection refused
Cause: The destination endpoint or a device along the route actively refused the connection. The port may not be listening, or an access policy may be blocking it.
Fix: Check the address and port. If the same endpoint keeps returning this error, ask your provider to confirm the service status.
Error: i/o timeout
Cause: A read or write operation didn’t complete in time. This error alone can’t distinguish congestion, filtering, or an unresponsive server.
Fix: Note which stage timed out, keep the node fixed while switching access networks, and retest with your baseline node.
These are examples of errors that may appear in connection logs; not every protocol uses the same wording. Keeping the surrounding log context is more useful than copying only the last line. Remove authentication details and private browsing records before sharing logs.
Check the routing path: make sure the slow request actually uses the test node
In Home → Global Routing, Proxy, Direct, and Config determine how requests are routed. For a node comparison, you can temporarily select Proxy after confirming the purpose and data costs, then restore your original setting when testing is done. Config depends on the active configuration and matching rules in Config. Results with Direct don’t measure node throughput.
If you use Scene, check its associated settings too. Don’t assume the selected node in the node list is handling the request. Rules are matched in order; checking which rule matched the destination request is more direct than repeatedly switching nodes.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXYThis explains what the rules mean; you don’t need to replace your existing configuration: DOMAIN-SUFFIX matches domain suffixes, IP-CIDR matches IP ranges, GEOIP matches based on IP geolocation data, and FINAL handles requests that didn’t match an earlier rule. example.com is an illustrative domain; actual configurations may also use custom policy names.
- If the destination matches
DIRECT, switching proxy nodes usually won’t change the outbound route for that request. - If the destination matches
REJECT, check the reject rule instead of treating the failure as a slow route. - If most of the wait occurs during domain resolution, check for resolution errors and whether the DNS server is reachable. Don’t mistake a DNS issue for insufficient bandwidth.
- Before changing the configuration, save a restorable copy. Adjust only relevant entries, then remove test changes you no longer need after verifying the result.
Layer 4: Switch local networks to rule out Wi-Fi and connection triggers
Keep the node and destination fixed, switch from Wi-Fi to cellular, reconnect, and test again. If cellular works but Wi-Fi doesn’t, the issue is likely somewhere in the Wi-Fi network—wireless quality, the router, its upstream connection, or network policies—but this alone can’t identify the faulty device. If the node or Global Routing changes during the switch, restore the original test conditions first.
- Check the local baseline: Compare performance before and after connecting on a destination you can access directly. If it’s slow without a proxy too, troubleshoot the access network first.
- Check Wi-Fi quality: Retest near the router and pause tasks using heavy upstream bandwidth. A saturated upload can also increase response times.
- Check authentication: If public Wi-Fi requires a web-based sign-in, complete it before trying the connection again.
- Check connection triggers: Go to Settings → On Demand and review the trigger conditions. If the connection is triggered again during a test, note when it happens and check whether it matches your settings.
- Check active connections: In the system VPN settings, confirm which connection is actually active. Otherwise, a connection-state change may look like the same tunnel has become slow.
Common questions and what to include when asking for help
Latency is low. Why does the video keep buffering?
A latency probe doesn’t measure sustained throughput to the video service. Keep the node and Global Routing fixed, compare loading for the same video, and check which rule the request actually matches. If only that service has a problem, note its destination hostname and when the issue occurs.
It got slower after I updated my subscription. Do I need to re-enter every node?
First check whether the selected node, protocol, or port changed after the update, then compare with the details you saved before updating. Don’t delete all your settings right away. If you have questions about the subscription content or validity, check with your provider.
Hysteria2 is unstable only on Wi-Fi. How can I verify the cause?
Keep the node settings unchanged, reconnect over cellular, and repeat the same request. If the issue occurs only on that Wi-Fi network, note any UDP-related errors and connection times. This narrows down the possibilities, but doesn’t by itself prove that the network is blocking UDP.
It’s still slow after restarting my phone. What information should I send when asking for help?
Include the time and time zone, access network, node label, protocol, Global Routing setting, destination hostname, and three comparison results. Include redacted error context, but don’t send passwords, keys, UUIDs, or the full subscription URL.
After troubleshooting, restore your original Global Routing and On Demand settings and keep useful test records. For a single-node issue, check the endpoint first; for recurring issues at a particular time, compare route conditions; for a protocol-specific issue, verify transport settings; and if only one access network is affected, continue checking the local network. A one-time client purchase is not a network service plan; buying the app again won’t change the bandwidth or load of your existing route.