How to Fix Slow Shadowrocket Speeds: Check Your Network, Protocol, Route, and Server

At a glance

If Shadowrocket is slow after connecting, keep the test conditions consistent and check four layers in order: your local network, protocol settings, the route, and the server. This guide focuses on iPhone and iPad and is for users with their own service and subscription who can connect but experience slow browsing or downloads. Learn to distinguish latency, bandwidth, and connection failures, and keep a reproducible troubleshooting log.

Start with consistent tests: low latency doesn’t mean fast downloads

First, distinguish between a long wait before a page opens and a low transfer rate once a download starts. The first may involve DNS, connection setup, or a TLS handshake; the second is more likely related to available bandwidth, packet loss, throttling, or the destination site. Connectivity or latency tests in Home show only the result of a specific probe at that moment. They don’t replace a sustained download test or prove that every app uses the same exit route.

A request passes through several stages. A low latency reading for a node doesn’t mean the destination website is close to that server; the route from the remote exit to the site may still be congested. Use the same website or file throughout your tests, and don’t compare results from different speed-test services directly.

Local accessRule evaluationProtocol connectionRoute transmissionServer exit

Keep the target consistent: Use the same HTTPS page or file that you’re authorized to access. A file of a few dozen MB is enough; keep cellular data usage in mind.
Keep the test duration consistent: Observe each test for about 30 seconds and repeat it three times. Record time to first display, sustained transfer rate, and any interruptions—not just a momentary peak.
Use consistent units: 8 Mbps is about 1 MB/s before protocol overhead. Mbps and MB/s are not interchangeable.
Change one variable at a time: For each round, change only the network, node, or routing mode. Pause cloud backups, system updates, and other large transfers while testing.

Layer 1: Compare Wi-Fi and cellular networks

If the same node is slow on Wi-Fi but works normally on cellular, check the Wi-Fi connection and its upstream route before changing protocols. If your iPad doesn’t have cellular service, compare using your own phone’s hotspot. A hotspot may also be throttled, so treat it as an alternative access path, not an absolute baseline.

Keep your current settings

In Home, note the current node and Global Routing mode. Keep a copy of the configuration in use in Config. Record the current Settings → On Demand state. If it’s enabled, you can temporarily turn it off during a controlled test to prevent automatic reconnection from confusing your check that the connection is off. Restore it afterward.
Check the local baseline

Disconnect Shadowrocket and confirm that the connection has stopped. Then open an HTTPS page that normally works without a proxy. If it also takes a long time to load or keeps disconnecting, check the Wi-Fi signal, router load, or broadband connection first.
Switch networks

Reconnect Shadowrocket and test the same node against the same target on both Wi-Fi and cellular. On iPhone, turn off Wi-Fi in Settings → Wi-Fi and confirm the status bar reflects the switch before starting the next test.
Narrow down the cause

If only Wi-Fi is affected, test again closer to the router and compare available 5 GHz and 2.4 GHz networks. If only one access network fails to connect, note the carrier and network type, then check UDP reachability at the protocol layer.

Layer 2: Check protocol settings and routing

In Home, open the current node’s edit screen and compare its settings with the original parameters from your service provider. Check the protocol type, server address, port, authentication details, and any required TLS, SNI, or transport options. Don’t change ports at random or disable certificate verification to “speed things up.” For example, if the service specifies TCP 443, verify that port; don’t swap it for UDP 443 just because another configuration uses it.

Shadowsocks, VMess, VLESS, Trojan, Hysteria2, and WireGuard have different connection requirements. Changing Type alone won’t make a server accept a different protocol. Hysteria2 is based on QUIC and requires UDP; WireGuard also uses UDP. On Wi-Fi networks that restrict UDP, they may time out or behave inconsistently. For other protocols, follow the underlying transport specified in your existing configuration rather than guessing from the protocol name.

Check	What to do	How to interpret the result
Global Routing	Check the current mode in Home. Config routes traffic according to configuration rules; Proxy is useful for temporarily testing the proxy route; Direct connects without a proxy.	If the same target works in Proxy but not in Config, check the rules and policy selection first. Restore the original mode after testing.
Rule matches	In Config, check the relevant DOMAIN-SUFFIX, GEOIP, IP-CIDR, and FINAL rules, and confirm that their associated policies exist.	The order of standard rules affects matching. A broad rule that matches too early may send traffic down an unintended route.
DNS and TLS	Record DNS resolution failures, certificate errors, and connection timeouts separately. Check the system time and the SNI required by the service.	A failure that occurs only when accessing a domain doesn’t necessarily mean there’s not enough bandwidth. Don’t use a bare IP address in place of an HTTPS domain to test: certificates and virtual hosts may differ.
UDP reachability	Test the same Hysteria2 or WireGuard configuration on both access networks.	A failure on only one network means that access path needs investigation; a timeout alone isn’t proof that the carrier is blocking traffic.

If the first page load is slow but the same page opens much faster the next time, look at DNS, connection reuse, and caching—but treat these as clues, not proof. Don’t change DNS, protocol, and node all at once, or you won’t know which change helped. Before editing a configuration, save a copy and change one field at a time.

Layer 3: Distinguish peak-time congestion from destination limits

Route congestion often shows up as normal performance during the day but slower speeds in the evening, a connection that succeeds but fluctuating transfer rates, or several destinations being affected at once. To verify, record results at different times using the same access network, node, and test target rather than relying on a single latency reading.

Test at different times: Try one round each at 09:00, 15:00, and 21:00. These are suggested times for logging, not a claim that congestion happens at the same hours everywhere.
Test different destinations: Using the same node, test two unrelated destinations that you’re authorized to access. If only one site is slow, check its service status, account limits, CDN routing, and app behavior.
Compare exit routes: If your existing subscription includes nodes in different regions or on different routes, compare them at the same time. Different names don’t guarantee different upstream routes, so interpret the results carefully.
Check sustained performance: A fast start followed by a steady drop may indicate throttling, an exhausted cache, or a change in congestion control. Check your provider’s traffic and bandwidth policies before drawing conclusions.

Don’t assume a route is good just because the destination is geographically close. The actual path, carrier interconnections, and server exit can all affect performance. If speeds drop only at certain times, give your provider the exact time, time zone, access network, and symptoms. That’s more useful for investigation than saying “it’s really slow at night.”

Layer 4: Check the node server and the exact error

If other working nodes in your existing subscription perform normally on the same access network while one node consistently fails, narrow the investigation to that node and its route. A node is a connection endpoint, not the entire route: the server may be online while its exit bandwidth is saturated, connection limits are reached, or a remote network is failing.

The messages below are examples of low-level errors that may appear during network diagnostics; they won’t necessarily show up in exactly the same form every time. Keep the full context and timestamp. A single error can narrow down the possibilities, but usually can’t identify the responsible layer on its own.

Error: connection timed out

Possible causes: The connection wasn’t established within the time limit. Possible causes include packet loss along the route, an unreachable port, restricted UDP, or an unresponsive server.

What to do: Keep the node settings unchanged and test again on Wi-Fi and cellular. If both fail, ask your provider to verify the address, port, and service status.

Error: connection refused

Possible causes: The connection was explicitly rejected, often because no service is listening on the target port or an intermediate device actively refused it.

What to do: Verify the server address and port rather than guessing at ports. Ask your provider to check the listener and access controls.

Error: certificate has expired

Possible causes: The certificate being checked has expired, or the device’s clock is wrong and is causing the validity check to fail.

What to do: Check the system date and time first, then ask your provider to verify the TLS certificate and SNI. Keep certificate verification enabled; skipping it is not a speed fix.

A successful subscription update doesn’t mean a node is currently working; it only confirms that the configuration was retrieved. Likewise, a failed update doesn’t necessarily explain why an existing node is slow. If you need to refresh it, update the existing subscription in Home and make sure its URL and access permissions are still valid. Don’t delete all configurations and reimport them as a substitute for troubleshooting.

Only one node is affected: Share its identifier, the exact error, and when it occurred. Ask about server load, maintenance, and port status.
All nodes are affected: Check local access, account status, and shared configuration first, then investigate whether the nodes use the same upstream route.
Before sharing diagnostic logs: Hide subscription URLs, tokens, passwords, private keys, and personal browsing records. Include only the fields needed for troubleshooting.

Common questions: The connection works, but performance is still slow

Latency is low. Why does video still buffer?

A latency test doesn’t show the available bandwidth to a video CDN. Test the same video at the same resolution and watch it play continuously, then try another destination you’re authorized to access. If only that platform is affected, check the route to its CDN and any platform limits. Don’t choose a node based on latency alone.

Switching Global Routing to Proxy fixed it. What should I do?

Note the original mode, then check the relevant rules and policies in Config. If Proxy works but Config doesn’t, the two modes may be taking different routes; that doesn’t prove the protocol itself is faster. Correct any rule mismatch, restore the original Config mode, and retest against the same target.

Will switching to Hysteria2 always make it faster?

No. You need a server that supports Hysteria2 and the matching parameters, and your access network must allow the required UDP traffic. Compare reachability and sustained transfer on the same network before deciding whether to use it. You can’t turn an existing node using another protocol into Hysteria2 just by renaming it.

It reconnects automatically after I disconnect. Will that affect troubleshooting?

Yes, it can interfere with direct-connection comparisons. Check the trigger settings in Settings → On Demand. If it’s safe to disconnect in your test environment, temporarily disable them and verify the connection state. Restore the original settings after testing; don’t forget any automatic connection requirements you had before.

Share your troubleshooting log: Keep only the details needed to reproduce the issue

After checking all four layers, you should be able to answer: “Which network, node, and mode are slow for which destination?” If you still can’t pinpoint it, return to one-variable-at-a-time comparisons instead of stacking supposed optimization settings. The same layered approach also applies to Mac, Windows, Android, and Linux, but don’t copy the iPhone/iPad system menu paths directly.

Environment: Device type, operating system, Wi-Fi or cellular, and any large background transfers.
Configuration: Protocol name, current Global Routing mode, a non-sensitive node identifier, and whether you recently updated your own subscription.
Symptoms: Time to first display, sustained rate and units, interruptions, exact error text, and timestamp.
Comparison: Which variable changed when performance improved, whether the result was consistent across repeated tests, and which settings you restored afterward.