This guide is for people who have imported their own subscription into Shadowrocket and can connect, but are experiencing slow page loads or transfer speeds. Start by keeping the test target and Global Routing mode consistent, then check your local connection, protocol settings, network path, and server resources in turn. Change only one variable per test, and repeat each test to distinguish persistent bottlenecks from temporary fluctuations.
First, distinguish high latency, slow initial loads, and slow sustained transfers
“Slow” can describe at least three different problems: a long wait before a connection is established, a delayed first page render, or consistently low throughput after a file transfer begins. A latency test measures response time for a particular test method and target; it does not measure available bandwidth. Connectivity Test on Home can help assess reachability. A successful test does not mean every website or large file transfer will work normally.
Choose a fixed-size HTTPS resource you’re authorized to access as your test target, and use the same one each time. Run three tests in a row, recording the start time, time to first content, and steady transfer speed. The table below shows an example of how to record results; it is not a product test or a speed guarantee.
| Symptom | Example result | Check first |
|---|---|---|
| Low latency but slow downloads | Response time around 80 ms; sustained transfer around 300 KB/s | Network congestion, server speed limits, or destination site limits |
| Slow on the first load, then normal | About 5 seconds to load, then steady at around 5 MB/s | DNS, handshake, or connection setup |
| Transfers pause intermittently | Several seconds with no data in all three tests | Wireless interference, packet loss, or network switching |
Use consistent units when comparing results: 8 Mbps converts to about 1 MB/s in theory, while actual transfers are also affected by protocol overhead. Don’t compare Mbps on a speed test with MB/s on a download page as if they were the same, and don’t assume the server with the lowest latency will deliver the highest throughput.
Layer 1: Keep your local network and test conditions consistent
The quality of your local connection affects every check that follows. Full Wi-Fi bars mean the device has a strong wireless signal; they don’t prove that your router’s uplink, home broadband, or current network egress is free of congestion. Pause photo syncing, system updates, and other bandwidth-heavy tasks before comparing results.
-
Record the current setup
On Home, note the current server and Global Routing selection. Then check whether Settings → On Demand is enabled. If you need a baseline with the connection off, temporarily disable automatic connection first so it doesn’t turn back on during the test. Restore the original setting afterward.
-
Establish a baseline
Disconnect Shadowrocket and test the same fixed resource three times over your current network. If it’s also slow, check your router, wireless interference, and broadband connection before changing protocol settings.
-
Keep the mode consistent
Return to Home, open Global Routing, and check whether the current mode is Proxy, Direct, Config, or Scene. To isolate the effect of rules, you can temporarily switch to Proxy, reconnect to the same server, and test again. Restore the original mode afterward.
-
Try a different connection
Keep the server and test target unchanged, and run tests on both Wi-Fi and cellular. After switching, wait for the network to stabilize and reconnect; don’t switch during a transfer. Check your cellular data allowance before using cellular.
If the same server works normally on cellular but remains slow on Wi-Fi, the issue is more likely related to that Wi-Fi connection, its egress, or its path to the server. This does not by itself prove the server is at fault. If both connections are slow, continue checking the settings and network path. On Demand controls when a connection is established; it does not increase bandwidth.
Layer 2: Check protocol settings one by one—don’t guess at TLS changes
Incorrect settings are more likely to cause connection failures, handshake errors, or repeated retries, sometimes appearing as a page that takes a long time to load. Compare the current server’s edit screen on Home with the configuration provided by your own service provider. For subscription servers, update the subscription and test again first. Before making manual changes, record the original values so you can avoid mistaking overwritten settings for test results after an update.
| Protocol or setting | What to check | Common pitfall |
|---|---|---|
| Trojan and TLS | Address, port, Password, SNI, and certificate requirements | The connection address and SNI may differ; use the values in your provider’s configuration |
| VMess / VLESS | Identity settings, transport type, and—when applicable—Host, Path, and TLS | Resolving the server name doesn’t mean all transport settings are correct |
| Shadowsocks | Encryption method, Password, port, and any plugin settings required by the server | The Password can be correct and still fail if the encryption method doesn’t match |
| Hysteria2 / WireGuard | Authentication or key, address, and port settings that match the server | Both rely on UDP, so how your current network handles UDP can affect the connection |
Enter the port exactly as specified. For example, if the server configuration says 8443, don’t change it to 443 just because 443 is a common TLS port. The port number alone doesn’t indicate speed. For TLS servers, keep certificate verification enabled; turning on Allow Insecure is not a general fix for slow speeds. If you encounter certificate errors, also check the system time on your iPhone or iPad.
If the connection log includes one of the English error messages below, use its meaning to narrow down the cause. Full messages can differ by connection stage, so don’t conclude the server is at fault based on a single word.
Error: i/o timeout
Cause and next steps: A read or write operation did not complete within the time limit. The issue may involve your local network, the route, or the server. Note the connection stage before and after the error, then switch networks without changing the server and test again.
Error: connection refused
Cause and next steps: The destination or an intermediary actively rejected the connection. This can happen if the port isn’t listening or access is denied. Check the address and port first, then ask your own service provider to confirm that the service is available.
Error: certificate verify failed
Cause and next steps: TLS certificate verification failed, possibly because of the hostname, certificate chain, or system time. Check SNI, the system date, and your provider’s settings. Keep verification enabled and fix the underlying issue.
Layer 3: Use cross-tests to pinpoint congestion and packet loss
Here, “route” means the network path between your device’s network and the server. It may include the access network, interconnection between networks, and intermediate links. Path quality can change over time. A successful connection doesn’t rule out congestion, and a slow result from one destination doesn’t prove the entire path lacks bandwidth.
- Same server, different connection: Keep the server and resource fixed, and switch only between Wi-Fi and cellular. If the difference is consistent, the route from each network’s egress to that server is worth investigating.
- Same connection, different time: Run three tests during a quieter period and three during the time when the problem usually occurs. If speeds drop mainly at certain times, treat congestion as a possibility to investigate rather than immediately changing protocols.
- Same server, different destinations: Test two separate, fixed resources. If only one is slow, consider destination-site limits, regional routing, or the route between the server and that destination.
- Same connection, different servers: Choose another available server from your own subscription, keeping the resource and test method unchanged. Don’t run multiple downloads at once, as that adds competition for bandwidth.
If web pages load but video or large files pause repeatedly, focus on packet loss and throughput consistency, not just minimum latency. For protocols that rely on UDP, if switching to a different network fixes the issue, ask your provider to check UDP reachability for that network. Don’t change MTU, DNS, and transport settings in bulk; changing several options at once makes the results hard to interpret.
Layer 4: Check server resources, plan limits, and destination bottlenecks
After checking the first three layers, assess the specific server. Reachability doesn’t guarantee sufficient egress bandwidth, capacity for concurrent users, or a good route to the destination. Normal latency with low sustained throughput may involve server load, plan speed limits, data allowances, or destination-site restrictions. The client alone generally can’t accurately measure server-side details such as CPU load or egress utilization.
- Check the account information provided by your own service provider for the expiration date, remaining data, and any agreed speed limits. Don’t repeatedly refresh the subscription to try to bypass restrictions.
- After updating your existing subscription, make sure you’re still testing the same server. A changed server name or address can make the before-and-after results incomparable.
- On the same network, compare two servers already included in your subscription. If only one is consistently slow across multiple destinations, send your provider the test results for that server.
- If multiple servers are slow for just one website, keep the results showing that other destinations work normally, and focus on the destination site and the relevant egress route.
When sharing test results, include the time and time zone, Wi-Fi or cellular, protocol, Global Routing mode, destination type, all three results, and any error messages. Don’t share the full subscription URL, Password, private key, or credentials. Cover them in screenshots before sharing. App purchase receipts and network route status are separate kinds of information; purchase status cannot tell you whether a route is speed-limited.
Common questions: low latency, automatic connections, and restoring settings
Why are downloads slow when latency is only a few dozen milliseconds?
A latency test measures the response to a specific probe, not sustained throughput. Choose a large, fixed resource and test it three times, then compare with another destination. Make sure Global Routing mode and the selected server haven’t changed before deciding whether bandwidth or destination limits may be involved.
Will enabling On Demand make the connection faster?
Settings → On Demand controls when a connection is made; it doesn’t increase route bandwidth. If the delay happens while reconnecting after a network switch, first reconnect manually on the same network and test again. Don’t confuse reconnection time with steady download speed.
Proxy works normally, but Config is slow. Should I keep using Proxy?
You don’t need to change your long-term setup yet. Note the affected domain, confirm the actual outbound selection in the request log, and check Config for rules that match earlier and the FINAL rule. Correct the relevant rule or policy, restore Config, and test the same destination again.
Which settings should I restore after testing?
Restore the original Global Routing mode, selected server, and Settings → On Demand state. If you changed any parameters, restore them using your notes. Keep useful comparison results, and don’t save several unverified changes because of one unusually fast test.
The goal isn’t to find a switch that seems faster; it’s to reproduce the difference and identify which network, server, destination, or time of day causes the issue. If the evidence is still inconclusive, save your configuration and test notes, then share only the essential information with your own service provider. That’s more useful for diagnosis than clearing your configuration and importing it again.