How to Fix Slow Shadowrocket Speeds: Check Nodes, Routes, Protocols, and Your Local Network

At a glance

This guide is for when Shadowrocket connects but web pages load slowly, videos buffer, or download speeds fluctuate. Using your existing provider and subscription, start with a fixed test target and check routing, then compare nodes, routes, protocols, and your local network. Change one variable at a time to identify reproducible symptoms and likely causes instead of replacing your entire setup based on a single latency test.

1. Identify what is slow

Turning on the connection does not mean every request is routed through the proxy, nor does it guarantee enough bandwidth at the proxy exit. A slow page load, repeated video buffering, and persistently slow downloads can involve DNS, connection setup, or sustained throughput. Describe the specific symptom first so your comparisons are meaningful.

App request Rule match Node connection Route transmission Destination response

This sequence shows where to investigate; it is not a fixed processing order for every protocol. DNS may be involved in rule matching and destination resolution, and caching can change load times between first and repeat visits. A slow response from one website does not necessarily mean the entire proxy route is slow.

Choose a web page or download you’re authorized to access and that has relatively stable content. Use the same target for every comparison; don’t compare speed test results from different websites.
Record the time, local network type, node name, protocol, Global Routing status, and symptoms. Use labels such as A and B for node names in your notes.
Pause system updates, cloud sync, and other bandwidth-heavy tasks. Repeat the same action three times, recording initial load time, transfer speed, and any interruptions each time.
Distinguish a cold start from repeat visits. A slow first DNS lookup or handshake followed by a much faster second visit is different from consistently slow data transfer.

4 layers

Check nodes, routes, protocols, and your local network separately

3 runs

Suggested number of repeated tests per set in this guide

÷ 8

Theoretical conversion from Mbps to MB/s, before overhead

For example, 80 Mbps is theoretically about 10 MB/s. This is a unit conversion, not a measured Shadowrocket speed or performance guarantee. Latency measures wait time; download speed measures data transferred per unit of time. They cannot be converted directly.

2. Check routing and connection status first

In Home, check the selected node and connection switch, then review Global Routing. Proxy routes eligible traffic through the proxy policy; Direct connects directly; Config routes traffic according to configuration rules; Scene determines behavior based on scene settings. Confirm how the test request is actually routed instead of relying on the status bar icon alone.

Config: Open the active configuration in Config and check rule order and the matched policy. Selecting a node does not guarantee that a domain uses it.
Proxy: Use it briefly as a comparison to see whether the target improves over the proxy route. Restore the original Global Routing setting afterward to avoid changing how other apps connect.
Direct: Compare how the target performs over your local network without the proxy. If the target cannot be reached directly, failure does not prove that your local broadband is slow.
Scene: Check which scene conditions and routing behavior are active. To reduce variables, temporarily compare using an explicit Config or Proxy setting.

The following is a rule syntax example, not a complete file to replace your existing configuration. example.com is a sample domain, and PROXY must refer to an available proxy policy. Rules are generally matched in order, with FINAL at the end as a fallback.

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

DOMAIN-SUFFIX matches domain suffixes, IP-CIDR matches IP ranges, and GEOIP matches based on IP geolocation data. If the target is incorrectly matched to DIRECT, fix the rule before changing protocols. If Proxy works but Config is slow, check the rules, DNS, and policy selection first. For more on routing, see Proxy Modes.

3. Node checks: availability and signs of load

A node is a specific server endpoint in your existing configuration. Low node latency only means that a test request had a short round trip under specific conditions; it does not reveal congestion at the server’s exit, account-level speed limits, or restrictions imposed by the destination website. A node may handle short requests successfully while sustained downloads slow down due to load or throttling.

In Home, confirm that you selected the intended node, and check that its address, port, and protocol match the information from your provider. Don’t change every port to 443; use it only if the server is actually listening on that port.
If you already have multiple nodes, keep the local network, Global Routing setting, and test target the same. Switch only between nodes A and B, and record three rounds of results.
Check the traffic and expiration details for your existing subscription. After updating it in Home, confirm whether the node parameters have changed. Get subscriptions and nodes from your provider.
If only one endpoint keeps having issues, report its label, the time of the problem, and any error to your provider. If multiple endpoints share an exit or relay, don’t treat them as fully independent comparisons.

Takeaway: Isolate one issue before changing settings

If node A keeps failing while node B works on the same network and target, save A’s error details and check its service status first. Changing DNS, MTU, or every protocol setting globally would undermine a comparison that already works.

4. Route checks: Compare times and network paths

A route is the transmission path from your device to the endpoint, from the endpoint to the exit, and from the exit to the destination. The region in a node’s name does not describe the entire path or guarantee low latency or high bandwidth. If the same endpoint slows down in the evening and improves off-peak, shared-link congestion may be involved, but that alone does not identify the affected network segment.

Comparison	What to do	What it can help isolate
Same node, different times	Record three results each in the morning and evening, keeping the target and local network unchanged	Check for congestion that repeatedly occurs at certain times
Same node, different connections	Switch between Wi-Fi and cellular, then reconnect	Identify differences in local access or the carrier’s route
Same network, different targets	Visit two existing test targets separately, keeping the node unchanged	Distinguish general transfer issues from a single target’s response
Same target, different existing endpoints	Switch only the node; don’t also change the protocol or routing	Check whether the issue is tied to a particular endpoint or shared path

If you have reliable packet-loss test conditions, distinguish ICMP probes from actual application traffic. Intermediate routers may limit probe responses, so high packet loss at one hop does not prove that application traffic is being lost there at the same rate if the final destination responds normally. More useful signs include persistent failures at the destination, repeated transfer stalls, and whether those symptoms can be reproduced under the same conditions.

Don’t switch nodes, change DNS and protocols, and restart your router all in one test. After each comparison, restore the baseline before changing the next variable. Otherwise, even if speeds improve, you won’t know which step helped.

5. Protocol checks: Verify transport conditions, not just the name

Shadowsocks, VMess, VLESS, Trojan, Hysteria2, and WireGuard have different server parameters and transport requirements. Changing protocols does not mean editing the type field of an existing node to another name. A valid comparison requires a matching configuration explicitly provided for your existing server.

Shadowsocks: Check the server address, port, encryption method, and password. Changing the encryption method won’t fix mismatched parameters.
VMess / VLESS: Check the transport method and its associated fields as well as the identity parameters. If using WebSocket, Path and Host must match the server requirements.
Trojan: Check the password and parameters such as the TLS server name. A failed TLS handshake is a connection setup issue; don’t mask it by relaxing certificate verification.
Hysteria2: It is based on QUIC and requires UDP connectivity. It may work better in some high-latency or packet-loss conditions, but if the network restricts UDP, a usable connection may not be established at all.
WireGuard: It uses UDP. Check the Endpoint, keys, and server configuration. If the tunnel connects but some large requests stall, investigate the path MTU; don’t treat an arbitrary MTU value as a universal speed boost.

For example, if the server is configured for UDP 443, confirming that TCP 443 is reachable does not prove that Hysteria2 will work. The port number is the same, but the transport layer is different. TCP-based and UDP-based traffic can also behave differently on the same network.

Error: connection refused

Cause and fix: The connection to the destination port was actively refused. The port may be incorrect, the service may not be running, or an intermediate device may be rejecting the connection. First verify the address and port supplied by your provider, then check the service status. Repeated speed tests won’t fix a refused connection.

Error: i/o timeout

Cause and fix: A network operation did not complete within the time limit. This may happen during resolution, connection setup, or data reading. Check the surrounding error details, then compare the same node over a different local connection to narrow down the cause. Don’t assume the password is wrong.

Error: TLS handshake timeout

Cause and fix: The TLS handshake did not complete in time. The cause may involve the route, server load, or handshake parameters. First check the system time, TLS server name, and server configuration, then see whether the failure persists on another local network.

These are examples of errors that may appear during network troubleshooting. Actual logs may include a prefix, destination address, or more detail. Use them to identify the stage where a failure occurred; they do not mean Shadowrocket displays exactly the same message on every platform.

6. Local network checks: Wi-Fi, DNS, and automatic connections

Local network issues can affect every node. First compare Wi-Fi and cellular on the same device before investigating the router. If only one device is affected, check for other VPNs, filtering tools, power-saving settings, and background downloads on that device instead of resetting the entire network straight away.

Check Wi-Fi signal and congestion: Repeat the test near the router and, if possible, compare different bands. Higher-frequency bands aren’t always faster at every distance; compare stability from the same location.
Check DNS behavior: If web pages take a long time to open initially but downloads are fine afterward, check DNS settings and resolution failures. Save the current configuration first, then compare system DNS with your existing custom DNS. Don’t change multiple DNS options at once.
Check the clock and network sign-in: Make sure the system date and time are correct and that you’ve signed in to the public Wi-Fi network. Without network sign-in, every node may time out and TLS connections may fail.
Check automatic reconnection: In Settings → On Demand, review any automatic connection conditions. If you disconnect manually for a comparison, confirm that the connection isn’t immediately triggered again. Restore the original settings when testing is complete.
Establish a fresh baseline: After switching between Wi-Fi and cellular, reconnect and run three comparisons. This prevents the recovery time from an interrupted old connection from being counted as steady-state speed.

Takeaway: Compare networks before reinstalling repeatedly

If the same device, node, and target work over cellular but consistently fail over Wi-Fi, focus first on the Wi-Fi connection and its upstream route. Keep a record of this difference before changing router or client settings.

7. FAQs and troubleshooting notes

Why does video still stutter when latency is only a few dozen milliseconds?

A latency test is not a sustained bandwidth test. Choose one video and resolution, compare continuous playback on the same node, then try another node you already have. If short requests are stable but long transfers repeatedly stall, note throughput fluctuations and when they occur.

Will switching to Hysteria2 definitely make it faster?

Not necessarily. First confirm that your server provides Hysteria2 parameters and that your local network allows the required UDP traffic, then compare using the same target and time period. If only UDP-based protocols fail while your existing TCP configuration works, investigate the UDP path instead of continually increasing bandwidth settings.

It’s still slow after updating the subscription. Should I keep refreshing it?

Updating a subscription syncs configuration; it doesn’t directly increase server bandwidth. Update it once, check whether the node address, port, or protocol changed, and then test against a fixed target. If the parameters are unchanged and the connection works, investigate node load, the route, and your local network.

Config is slow, but Proxy works. What should I change?

In Config, first check which rule and policy match the target, especially earlier DOMAIN-SUFFIX and GEOIP rules and the final FINAL rule. Then check whether domain resolution affects the match. Don’t delete all the rules; back up the configuration and fix only the item that is clearly wrong.

When reporting an issue to your provider, a minimal set of reproducible conditions is usually more useful than saying “all nodes are slow.” Don’t include subscription links, identity keys, or passwords in public reports. Redact them before sharing screenshots or logs.

When it happens: Date, exact time and time zone, whether you’re on Wi-Fi or cellular, and whether it occurs only at certain times.
Configuration: Node label, protocol, Global Routing status, and configuration in use. Don’t submit a full subscription link or any keys.
Steps to reproduce: What type of target you opened, how long you waited, and where it stalled, with notes from three repeated attempts.
Comparison results: Whether switching nodes or local networks helped, whether Direct provides a valid comparison, and the exact error message.

After troubleshooting, restore any temporary changes to Global Routing and On Demand, and keep a record of conditions that reproduce the issue consistently. If you still can’t identify the cause, use the troubleshooting guide to check the connection and configuration. This site does not provide, sell, or recommend nodes or subscriptions; get related configurations from your provider.