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

At a Glance

A latency reading alone doesn’t mean transfer speeds are normal. Start by using the same test target and distinguishing between slow initial page loads, slow sustained transfers, and intermittent drops. Then check your local network, existing nodes, routes to the node, protocol settings, and rule matches. This guide is for users who already have their own provider and subscription. Change one variable at a time, record the result, and then decide whether to keep the change.

First, Know What You’re Measuring: Latency, Throughput, and Time to First Load

Shadowrocket’s connection test measures reachability or response time using a specific test method; it isn’t a substitute for testing sustained transfers. A connection may be established quickly while subsequent data is affected by congestion, packet loss, server load, or restrictions at the destination. Latency results from different test methods shouldn’t be compared directly.

Choose a website you normally use and a fixed-size file you’re authorized to access. Use the page to observe the initial response and the file to measure sustained throughput. Don’t compare results from two different sites as if they used the same route, and don’t run multiple transfers at once.

What you observe	Check first	How to verify
Slow initial load, then normal	DNS, connection setup, destination response	Compare the first and second load of the same page
File transfer stays slow	Route, node load, destination throttling	Observe the same file continuously for 30 seconds
Transfers speed up and stall intermittently	Packet loss, wireless signal, congestion	Keep the node fixed; compare Wi-Fi with cellular
Only one site is slow	The site itself, rules, route to the destination	Use the same node to access another independent site

Watch the units: Mbps means megabits per second, while MB/s means megabytes per second. By unit conversion alone, 8 Mbps = 1 MB/s; real transfers also include protocol overhead. For example, “80 ms latency, 0.5 MB/s file speed” is one possible set of readings, but it doesn’t prove that a node is working normally or abnormally. The numbers here illustrate how to record results; they are not measured performance figures.

Layer 1: Keep Conditions Consistent and Check Your iPhone’s Local Network

First, check whether the slowdown also occurs outside Shadowrocket. For the same destination that you can access without a proxy, disconnect and run a baseline test. This uses your local network to connect directly, so choose content that’s suitable for direct access. If the baseline is also slow, investigate your Wi-Fi, cellular signal, or network first.

Record the Current Setup

Note the selected node in Home and the current mode in Home → Global Routing. Also record whether you’re on Wi-Fi or cellular, the test target, and the time. Don’t clear your configuration first.
Pause Automatic Connections

Go to Settings → On Demand, note the existing settings, then temporarily turn off On Demand. Return to Home and switch off the connection. Make sure the system doesn’t reconnect immediately, or your baseline may mistakenly use the proxy.
Check the Local Baseline

Pause other bandwidth-heavy tasks on your device, move closer to the router, and access a fixed target. If the Wi-Fi network requires a web login, complete it first. A strong signal indicator doesn’t rule out congestion beyond your local connection.
Try a Different Network

Reconnect in Shadowrocket and keep the same node. Test the same target on Wi-Fi and cellular, repeating each test three times. Cellular testing uses mobile data, so keep your data plan in mind.
Restore Your Original Settings

Record the results, then restore the Global Routing and On Demand settings you need. If only one network is slow, investigate that network first; don’t change the node protocol and DNS at the same time.

Switching between Wi-Fi and cellular also changes your carrier’s network path. This comparison helps narrow the issue to local access and the route beyond it; it doesn’t prove that the router is faulty. If performance improves noticeably closer to the router while other conditions stay the same, wireless coverage or interference is more likely worth checking first.

Layer 2: Separate Node Endpoint Issues from the Route to the Node

A node is the server endpoint for a connection. The route is the data path from your device to that endpoint, and from the endpoint to the destination. Low node latency only means a particular probe responded quickly; it says nothing about the server’s available bandwidth or current load, or how quickly it can reach the destination. A nearby location doesn’t necessarily mean a shorter route.

Same network, different existing node: In Home, select another node from your existing subscription while keeping the test target and Global Routing unchanged. If only one node stays slow, focus on that endpoint and its route to the destination.
Same node, different network: If Wi-Fi is slow but cellular is fine with the same node, the difference may lie in the access network or route to the node. That doesn’t mean the node’s overall performance is the cause.
Same node, different time: Record performance during busy and quiet periods under similar conditions. If speeds drop only at certain times, congestion is one possibility to investigate; a single test can’t confirm provider throttling.
Same node, different destination: If only one of several destinations is slow, check the destination’s response, the rule it matches, and the route from the node to that destination. Don’t immediately replace all your settings.

A subscription update retrieves node information published by your provider; it doesn’t automatically increase bandwidth. Update the relevant subscription in Home only if your provider confirms that endpoint details have changed, then check that the selected node is still the expected entry. A successful update and improved speeds are separate things. Record the endpoint again afterward so you don’t mistake a node change for the effect of another setting.

Layer 3: Check Protocol Settings Instead of Changing Ports at Random

Shadowsocks, VMess, VLESS, Trojan, Hysteria2, and WireGuard use different connection and transport mechanisms. Client settings must match your server configuration; these protocols aren’t speed presets you can freely switch between on the same node. If your server offers only one protocol, changing Type in the client alone will usually make the connection fail.

Local networkConnect to nodeProtocol handshakeData transferDestination response

In Home, open the current node’s edit screen and check the address, port, credentials, and any protocol-specific settings such as TLS, Server Name, and transport path against the information from your provider. Check only the fields relevant to this node; don’t enable mismatched options in pursuit of higher speeds.

A port isn’t a speed switch: 443 is commonly used for HTTPS, but changing a node’s port to 443 won’t make the server listen on that port or enable TLS automatically.
Check the underlying transport: Hysteria2 uses QUIC over UDP, and WireGuard also uses UDP. If your current network restricts UDP, the connection may fail to establish or keep dropping. Compare it with another working configuration already provided by your service provider.
Keep certificate validation enabled: Certificate validation helps confirm the identity of the connection endpoint. If validation fails, check the system time, Server Name, and server certificate. Skipping validation isn’t a way to improve speed.
Don’t adjust MTU blindly: Small requests working normally while large transfers repeatedly stall may point to path MTU issues, but packet loss or destination throttling can cause similar symptoms. Record what happens first. Adjust related settings only when you have server-side guidance, and keep the original values.

To compare protocols, use only connections your provider already offers with complete settings, and keep the endpoint region, destination, network, and time as consistent as possible. Even if one performs better, the result applies only to those test conditions; it doesn’t mean that protocol is faster on every network.

Layer 4: Verify Global Routing and the Rules That Actually Match

Before investigating speed, confirm that requests are taking the expected path. In Home → Global Routing, Proxy sends eligible traffic through the proxy, Direct uses a direct connection, and Config applies the current configuration. If you use Scene, first check which configuration and policy the active scene applies. Switching scenes means the two tests no longer have matching conditions.

You can briefly compare Proxy and Config against the same destination, then restore the original setting. If Proxy works normally but Config is slow, check which rule the destination matched, which policy it uses, and which node that policy ultimately selects. Proxy doesn’t necessarily make all domain resolution behave identically, so check your DNS settings too.

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

The example above illustrates rule syntax; it isn’t a recommendation to replace your existing configuration wholesale. DOMAIN-SUFFIX matches domain suffixes, IP-CIDR matches IP ranges, GEOIP matches an IP address’s geographic location, and FINAL catches requests not matched by earlier rules. Rules are checked in order. Any custom policy name must also have a corresponding definition in the complete configuration.

In Config, confirm that the expected configuration is active, not merely saved in the list.
Check the connection log for the target request and verify its rule, policy, and final outbound. Don’t infer the path for every request solely from the node selected in Home.
If only the initial load is slow, check whether DNS queries are timing out or being retried repeatedly. DNS affects the resolution stage and usually doesn’t explain a sustained throughput drop after the connection is established.
Don’t change several DNS addresses at once. Keep the original values, change one item, then check whether the same destination’s initial response and subsequent transfer each improve.

Error Logs: Handle Connection Failures Separately from Slow Speeds

If the actual problem is repeated connection failures, fix those first and then test speed. The snippets below are examples of errors that may appear in network logs. The exact wording depends on the connection stage and underlying response, and may vary. When recording an error, include the time, network, and node.

Error: i/o timeout

Cause and next steps: A network read or write operation exceeded its timeout. Possible causes include packet loss, an unreachable route, or an unresponsive remote endpoint. First identify whether the error occurred during resolution, connection, or transfer. Then keep the node fixed and compare access networks; don’t reset your configuration based on a timeout alone.

Error: connection refused

Cause and next steps: The destination endpoint or a device along the route explicitly refused the connection, often because no service is listening on the port. Check the current node address and port, and ask your provider to confirm that the endpoint is available.

Error: no such host

Cause and next steps: The current lookup didn’t return the required host address. The cause may be a misspelled domain, a missing record, or the resolver. First determine whether the domain in the error belongs to the node or the destination website, then check that domain and the relevant DNS settings.

Before sharing logs, hide subscription links, tokens, passwords, private keys, and other credentials. You can include the protocol name, error snippet, network type, stage when it occurred, and comparison results. These details are usually more useful for troubleshooting than a screenshot showing only latency.

Common Questions: How to Interpret Your Results

Why does video still buffer when latency is low?

Latency measures only the probe request; video also depends on sustained bandwidth, packet loss, and the content server. Keep the same node and test another video and a fixed file. If only one content source is slow, check that source and its rule match first. Low latency doesn’t guarantee available bandwidth.

If switching nodes makes things faster right away, does that prove the original node is faulty?

It shows that the two connections had different overall conditions, but node load, routes, and destination exits may all have changed. Switch back to the original node and repeat the test with the same destination and network. If the difference is reproducible, share the results with your provider for further investigation.

How can I run a baseline if the connection turns itself back on?

Go to Settings → On Demand, note the current settings, and temporarily disable automatic connections. Then return to Home and disconnect. If your device has other managed connection rules, check their status first. Restore your original settings after the baseline test so your everyday connection behavior isn’t changed.

All my existing nodes are slow. Do I need to buy the app again?

Buying the client and getting bandwidth from a network route are separate matters. First compare a local baseline with another access network, then check the configuration and destination shared by the slow connections. A one-time client purchase ≠ a network plan; buying again won’t replace troubleshooting the route, endpoint, and settings.

Wrap-Up: Keep a Reproducible Comparison Log

When you’re done troubleshooting, keep only changes that have been verified through repeated tests, and restore any temporary modes or toggles. Revert changes whose benefits you can’t confirm. This avoids stacking variables and making the next issue harder to compare. You can use the format below without including any credentials.

Test target: same webpage or fixed-size file
Test conditions: same iPhone, pause other bandwidth-heavy tasks
Access network: Wi-Fi / cellular
Selected connection: your own node label, no credentials
Global Routing：Config / Proxy / Direct / Scene
Actual match: rule, policy, final outbound
Observation window: 30 seconds per round, repeat each set 3 times
Record: initial response, sustained speed, any interruptions
Single change: the one condition changed this round
Restore check: configuration, mode, On Demand

A useful conclusion describes the limits of what you observed, for example, “The same node works on cellular but keeps stalling on this Wi-Fi network,” rather than simply “The app is slow.” The first points to a clear next step; the second conflates the local network, route, protocol, and destination, making the issue hard to reproduce.