How to Troubleshoot Slow Shadowrocket Speeds: A Four-Layer Check of Nodes, Routes, Protocols, and Local Networks

Before you start: turn “slow” into a repeatable symptom

When Shadowrocket shows Connected, it only confirms that the system VPN tunnel has been established; it does not mean every request will receive the same throughput. Slow first-page loads, video buffering, slow file transfers, and apps that occasionally keep spinning may point to DNS response time, connection handshakes, sustained bandwidth, or packet-loss jitter. Identify the exact symptom before troubleshooting instead of recording only that it “feels slow.”

Choose a webpage you can revisit, a file source you control or that is consistently available, and one repeatable action in the affected app. Run each test for at least 60 seconds, complete 3 consecutive rounds, and compare the first result with the next two. If only the first round is slow and later rounds recover, DNS, TLS handshakes, or caching differences are more likely. If all three rounds remain slow, suspect throughput or the route.

Fixed test conditions

1. In Home, choose an existing node and do not switch repeatedly during testing.
2. Confirm the current Global Routing mode and record the result. Use Proxy as a comparison when checking rule effects, and keep Config for normal use.
3. Pause large file syncs, system updates, and other tasks that continuously consume bandwidth.
4. Record whether you are using Wi-Fi or cellular, the test time, node name, protocol type, and the results from all 3 consecutive rounds.
5. Restore the original Global Routing after testing so a temporary comparison setting is not mistaken for a long-term configuration.

A request passes through several stages. The latency test in Home mainly reflects the round-trip time of a probe request, not full download speed. A node may show low latency yet suffer from load, congestion, or packet loss during sustained transfer; conversely, a node with slightly higher latency may deliver steadier throughput. Use latency only for initial screening, not as the sole conclusion.

Layer 1: determine whether a single node is overloaded

A node-layer issue usually looks like this: on the same network, at the same time, and with the same test target, one existing node remains slow for 3 rounds while other nodes in the same configuration are clearly stable. Compare nodes you already have rather than drawing conclusions from their names, region labels, or one latency reading.

Run a latency test for the current node in Home, then select another existing node and repeat the exact procedure. After switching, wait for the connection status to stabilize, then reopen the test target instead of reusing a page that has already loaded from cache. If both nodes use the same protocol, the result is easier to attribute to node load. If their protocols also differ, record the result as “node or protocol not yet separated” and continue to Layer 3.

Practical order for checking the node layer

• Keep Global Routing → Proxy as a short-term comparison to rule out different test requests being sent to different policies.
• Choose 2 to 3 existing nodes and complete the same 3-round test for each. Do not refresh the subscription during testing.
• Record “time to first open” and “sustained transfer stability” separately instead of combining them into one rating.
• When finished, switch back to Config and check whether the result changes under rule-based routing.

Layer 2: identify time-based route congestion

Route-layer issues often follow a clear time pattern—for example, stable performance during the day but a drop every evening, or different results on weekdays and weekends. The node itself may be unchanged while the path from the local network to its entry point becomes congested at certain times. Constantly changing settings during the incident can easily make a brief recovery look like proof that an option works.

A minimal record is enough: test once in the morning, afternoon, and evening, using the same network, node, target, and Global Routing each time. After two days of records, if slow results cluster around similar times and Wi-Fi differs from cellular, check the local access path first. If both access methods slow down at the same time, a shared path or node entry-point load is more likely.

Distinguishing time-of-day issues by symptom

• Slows down at about the same time every day: Keep test records and do not change the protocol or rules between rounds.
• Wi-Fi is slow, cellular is normal: Check router distance, wireless band, signal obstruction, and bandwidth use by other devices on the same network first.
• Both networks are slow: Test one other existing node to determine whether the issue is shared at the node entry point.
• Speed tests are normal but a specific website is slow: Check rule matches, DNS results, and the destination site’s own response instead of blaming the entire route.

Also distinguish peak speed from sustained speed. A high burst during the first few seconds followed by a steady decline may result from congestion control, packet loss, or server-side throttling; a stable but low ceiling is more consistent with a fixed bandwidth limit. Recording the trend is more useful than copying only the highest number.

Layer 3: separate protocol behavior from configuration mismatches

Shadowrocket supports protocols including Shadowsocks, VMess, VLESS, Trojan, Hysteria2, and WireGuard, but the protocol name alone does not determine speed. Results also depend on the transport layer, encryption method, TLS, UDP availability, MTU, server configuration, and local network quality. When comparing protocols, use entries already supplied and correctly configured by your own service provider.

Shadowsocks performance depends on the encryption method, server capacity, and whether traffic uses TCP or UDP. VMess and VLESS may use different transport methods, while extra encapsulation and TLS handshakes affect initial connection time. Trojan is commonly used with TLS over TCP, where packet loss may cause noticeable retransmissions. Hysteria2 is based on QUIC and UDP, so its performance depends on UDP support and packet loss on the network. WireGuard also relies on UDP; an unsuitable MTU can make small requests work while large transfers stall.

Do not change server-side parameters casually

Protocol parameters must match the server. Any mismatch in the port, password, UUID, key, Server Name, Public Key, or transport path can cause connection failures or repeated retries. Speed troubleshooting should not begin with random edits to these fields; first confirm that the imported entry matches the original configuration supplied by the service provider.

If you have existing entries under the same service that use different protocols and target a similar location, fix the local network and test target for a comparison. Run the same 3-round test for each protocol, recording first response and sustained throughput separately. The comparison is meaningful only when the protocol is the main variable.

Layer 4: check local Wi-Fi, cellular, and system connectivity

The local network is the easiest layer to overlook. Several Wi-Fi signal bars do not guarantee a clear wireless environment; other devices continuously uploading in the same room can also raise latency and reduce download speed. The most direct test is to switch between Wi-Fi and cellular while keeping the node, protocol, and test target unchanged.

If cellular is stable while Wi-Fi fluctuates, move closer to the router and test again, then pause high-bandwidth activity on the same network. If moving closer restores performance, signal attenuation or wireless interference is more likely. If distance makes no difference but performance returns after other devices stop transferring, local network bandwidth use is more likely. Conversely, if Wi-Fi is normal but cellular is slow, consider signal quality and mobile-network congestion at your location.

1. In Home, keep the same node and do not refresh or switch configurations.
2. Complete 3 rounds over Wi-Fi, recording the first response and sustained behavior for each round.
3. Turn off Wi-Fi, wait for the cellular connection to stabilize, and complete 3 more rounds against the same target.
4. If the difference is clear, retest once on the original network to rule out a short-lived fluctuation.
5. If both networks are slow, return to the node or route layer for further diagnosis.

Check whether On Demand is causing connection changes

Open Settings → On Demand and check whether rules for automatic connection based on network conditions are enabled. On Demand mainly controls when a connection is established; it does not directly add bandwidth, but repeated condition matches can cause the connection to be re-established during network changes. If slowness occurs only when leaving Wi-Fi, switching to cellular, or rejoining a particular Wi-Fi network, temporarily disable On Demand for one comparison, then restore the original setting.

Include Global Routing in your records. Proxy sends requests through the current proxy policy and is useful for a short comparison; Direct tests a direct connection; Config applies rule matching; Scene handles requests according to the configured scene. If Proxy and Config produce different results, investigate rules and DNS instead of continuing to change the protocol.

Rules, DNS, and subscription updates: separating commonly confused symptoms

After completing all four layers, if slowness occurs only for a specific domain or app, check rule matching in Config. Shadowrocket processes rules in configuration order, with the first matching rule taking effect. DOMAIN-SUFFIX matches domain suffixes, GEOIP matches IP geolocation, IP-CIDR matches address ranges, and FINAL handles requests not matched earlier.

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

The snippets above explain matching order; they are not meant to replace an existing configuration directly. If a domain is slow under Config but recovers under Proxy, first check whether it matched DIRECT, an unsuitable policy, or an overly broad rule placed too early. If both modes are slow, rules are not the primary variable.

DNS issues often look like this: you enter an address and wait a long time, but the page loads quickly once loading begins. This differs from limited sustained bandwidth. When checking DNS settings in the configuration, follow the existing configuration instructions and do not replace several resolvers at once. Remember that domain-rule and IP-rule results can depend on the resolved address, so observe DNS and rules together.

Keep subscription updates separate from speed tests

A subscription update retrieves the node list and configuration content provided by the service provider; it is not a speed optimization step. Refreshing during a test may change node entries or parameters, making the results impossible to compare directly. Complete a test set with a fixed configuration first, then handle update issues separately.

If you need to check subscription formatting manually, an example URL may look like https://example.com/sub?token=xxxx, where both the domain and token are fictitious. The actual link comes from your own service provider and usually contains access credentials, so do not publish or forward it.

Reach a conclusion with minimal changes

Effective troubleshooting is not about finding a combination that is fastest for one moment; it is about identifying the layer where slowness occurs. The node layer checks whether one entry is abnormal, the route layer checks timing and path, the protocol layer checks transport behavior and parameter matching, and the local-network layer checks Wi-Fi, cellular, and system connectivity. These layers interact, but controlled variables can narrow the scope step by step.

1. Set a baseline: Use the same target, node, protocol, and Global Routing for 3 consecutive rounds.
2. Change only the node: Determine whether one node is overloaded; do not substitute a single latency reading for sustained testing.
3. Change only the time: Record the same conditions in the morning, afternoon, and evening to see whether a stable time pattern exists.
4. Change only the protocol: Use existing entries with correct parameters and record first response and sustained throughput separately.
5. Change only the access network: Compare Wi-Fi with cellular to determine whether the local network is the main variable.
6. Return to Config: If Proxy works but Config does not, check rule order, DNS, and policy matches.

After testing, keep only adjustments that explain the symptom and restore settings changed temporarily for comparison. If the issue centers on subscription content, server parameters, or node status, provide your own service provider with the test time, network type, protocol, and repeated results. If it occurs only on local Wi-Fi, continue checking the router environment and local-network usage.

Shadowrocket is a paid commercial client for Apple platforms, primarily used on iPhone and iPad. Compatibility and system requirements for Mac, Apple TV, and Apple Vision are as listed on the App Store page. The app is sold as a one-time purchase, developed by Shadow Launch Technology Limited, and has app ID 932747118. Purchasing the client and obtaining your own network service are separate matters.