Shadowrocket Slow? Troubleshooting Nodes, Routes, Protocols, and Your Local Network

1. Define “slow”: latency, throughput, and time to first content

When the Shadowrocket connection switch is on, it means the system tunnel has started—not that every destination is reachable or performing normally. The latency test in Home is not a sustained bandwidth test: one successful probe does not rule out later packet loss, congestion, remote throttling, or a slow response from the destination site.

First identify where the delay occurs. A link that takes a long time to show anything may be waiting on DNS resolution, connection setup, or the TLS handshake. If text appears quickly but images keep loading, resource requests or sustained transfers may be constrained. If video starts normally and then keeps buffering, check throughput over several minutes. Don’t judge route quality by a single millisecond reading.

Note the units: Mbps means megabits per second; MB/s means megabytes per second. In an ideal conversion, 80 Mbps is about 10 MB/s; real-world transfers also have protocol overhead. Don’t mistake an app reading of 8 MB/s for a tenfold shortfall from a plan advertised at 80 Mbps.

2. Establish a repeatable test baseline

Before you start, save the configuration you’re using and note the selected node in Home, the Global Routing mode, and the network used for testing. The steps below use your existing settings and don’t involve obtaining a new connection service. Run tests close together in time so differences in network load at different times aren’t mistaken for configuration changes.

1. Record the current setup

   In Home, note the current node and Global Routing mode. In Config, confirm the active configuration. Check Settings → On Demand for any automatic connection conditions; record the current state, but don’t change it just to run a speed test.

2. Keep the destination fixed

   Choose a webpage you can normally access and a specific file you’re allowed to test. Use the same destinations in every round. Pause cloud sync, photo uploads, and other bandwidth-heavy tasks so they don’t compete for capacity.

3. Check routing

   In Home → Global Routing, check the current selection. Config applies the configuration’s rules; Proxy uses the proxy routing mode, and Direct uses the direct routing mode. If you use Scene, verify the settings that the scene actually applies—don’t rely on its name alone.

4. Repeat the measurements

   Test each condition three times for about 60 seconds per round, and note the median result. Don’t switch nodes, protocols, and networks at the same time. Start a fresh connection to the destination before each test so browser connection reuse or caching doesn’t mask changes.

5. Restore your original configuration

   After the comparison, restore your original Global Routing mode and configuration. If you changed On Demand, restore its original conditions too, then check your usual apps to make sure the diagnostic settings won’t affect regular use.

3. Local network: compare Wi-Fi and Cellular first

If the same node is slow on Wi-Fi but works normally on Cellular, the change is associated with the access network—but that doesn’t prove the router is faulty. The two connections use different carrier routes, and the difference may also lie between the access network and the node. Narrow down where the issue occurs before checking the router or contacting your provider.

• Test near the access point: Using the same iPhone or iPad, run the test again near the router. Wi-Fi bars don’t fully reflect interference or retransmissions. If performance drops noticeably through walls, check wireless coverage first.
• Confirm the active network: In system Settings → Wi-Fi, check which network you’re connected to. When switching to Cellular, make sure Wi-Fi is disconnected. For an iPad without cellular data, compare with another known-good Wi-Fi network and note how you connected.
• Reduce shared usage: Pause large uploads from other devices. When upload capacity is saturated, webpage requests and transfer acknowledgments can queue up, slowing both downloads and interactive tasks.
• Check for access restrictions: Complete any required sign-in on captive Wi-Fi. If normal webpages are also slow in Direct mode, resolve the access network issue before checking proxy settings.

After switching networks, start a new request rather than watching a task that was already downloading. Existing connections may stall or retry after the device’s address changes. If the issue occurs only after switching, manually disconnect and reconnect Shadowrocket to test. On Demand controls when a connection is established automatically; it does not increase bandwidth.

4. Nodes and routes: separate server differences from time-of-day effects

Here, a “node” means a set of server connection parameters in Home; a “route” is the network path from your device to that server and then to the destination. Switching nodes usually changes the exit location and network path too. If one node is faster, that only shows that performance differs along the paths you tested—it doesn’t prove the original server is underpowered.

Choose two nodes you already have and compare them, keeping the protocol, destination, and local network the same where possible. If only one node is consistently slow, check its service status, usage limits, and whether its settings have changed. If several nodes slow down only in the evening and recover during the day, record the time rather than rebuilding all your configurations. Congestion on a shared route, load at the entry point, or load at the destination can all cause this pattern.

Also check your provider’s account page for exhausted data, expiration, or speed limits. Shadowrocket’s Data reading may use a different accounting method from your provider, so one local cumulative figure can’t rule out an account-side limit. If you need to update an existing subscription, save your configuration first, update it through the original subscription source, and confirm whether the selected node’s parameters actually changed.

5. Protocols: verify settings before comparing transport behavior

In Home, open the edit screen for the current server and check Type, address, and port against the parameters from your existing provider. A port number alone doesn’t identify a protocol or determine its speed: if the server specifies 443, use 443. Don’t switch to another port just because it seems more common. Changing the port locally won’t make the server offer a different service.

• Shadowsocks: Check the encryption method, password, and any additional settings required by the server. Incorrect settings are more likely to cause connection or transfer failures than a normal low-speed mode.
• VMess / VLESS: Check the UUID, transport, and TLS settings. For WebSocket, match Host and Path individually; having the right UUID doesn’t make the other settings optional.
• Trojan: Check the password, TLS, and Server Name. The certificate domain, server address, and transport entry may be different values; use the parameters you already have.
• Hysteria2: This uses QUIC-based transport and requires a network path that allows the relevant UDP traffic. If your provider specifies bandwidth parameters, follow its instructions instead of arbitrarily setting higher values.
• WireGuard: Check the keys, Endpoint, and other parameters provided by the server. MTU shouldn’t be the first setting you optimize. Investigate it only when there are clues such as transfers stalling at specific data sizes, and test changes one at a time according to your provider’s guidance.

A protocol comparison requires the server to support each corresponding entry. You can’t test by simply changing VLESS to Trojan in Type. Even when both entries work, they may use different servers, so the measured difference may not come from the protocol. Compare the full settings and network conditions before considering protocol overhead.

Error messages may come from different connection components; the exact wording depends on the log. If an error keeps appearing, treat it as a connection failure first. Don’t mistake long waits caused by repeated retries for low available bandwidth.

6. Rules and DNS: confirm where requests actually go

If the same node works normally in Proxy mode but slows down again in Config, check the active Config rules and DNS behavior first. Rules determine how requests are handled; DNS determines how domain names are resolved. They aren’t the same setting. Don’t replace the configuration, resolver, and node all at once, or you won’t know which change made a difference.

• Check rule order: DOMAIN-SUFFIX matches domain suffixes, IP-CIDR matches address ranges, GEOIP matches against an IP geolocation database, and FINAL handles requests that didn’t match an earlier rule. An earlier match may send a request somewhere other than the node you’re testing.
• Check the actual requests: A webpage’s text, images, and videos may come from different domains. Routing the main domain through a proxy doesn’t prove that every resource on the page uses the same outbound policy.
• Separate resolution from transfer: If the first request takes a long time but later transfers are normal, check DNS resolution and the handshake. If the connection is already established and remains slow, changing DNS alone won’t explain it.
• Keep the original configuration: Save a copy before changing rules, and change only one setting related to the destination at a time. Don’t move FINAL or delete a whole block of rules just to test.

Don’t use an IP address instead of an HTTPS domain for general speed tests. This can change certificate verification, the TLS Server Name, virtual hosting, and the CDN route—so you’re no longer testing the same destination. Send requests to the normal domain and check the connection log to see whether resolution completed and which policy was applied.

7. Common questions and wrapping up

When you finish troubleshooting, write down a reproducible finding, such as “same node and destination; all three Wi-Fi tests were slow, but Cellular recovered,” rather than just “Shadowrocket is slow.” If only one destination is affected, keep checking its relationship to the exit route. If every destination is affected, investigate shared access or node routes. Don’t assign a cause before you have a comparison.