If Shadowrocket slows down after connecting, first distinguish local network congestion, incorrect connection settings, route fluctuations, and remote node load. This guide is for users who already have their own configuration. It shows how to compare results using the same destination and node while changing one setting at a time, what Connectivity Test can tell you, and when to stop adjusting the app and send your provider the troubleshooting details.
Define “slow”: track connection setup separately from ongoing transfers
A page that stays blank, images that appear one by one, and playback that keeps buffering can point to different stages: name resolution, connection setup, or sustained data transfer. “Connected” alone does not confirm that the route is working properly. A successfully established system tunnel also does not mean the remote node or destination website is available. Choose one familiar webpage and one fixed file that you can safely download repeatedly, then use the same destinations for every comparison.
Run three tests in a row, about 30 seconds apart, and note the network type, selected node, Global Routing setting, and what failed. The figures below are examples of how to record results, not product measurements or performance benchmarks: recording that the first content appeared after 2, 5, and 3 seconds is more useful for reproducing the issue than saying “it’s sometimes slow.” Repeated tests use data, so keep file sizes small on cellular networks.
- Time to first content: Record the time from sending the request until the first content appears. Do not count page-rendering animations as connection latency.
- Sustained transfer: Record the stable transfer rate for the same file. Note that MB/s and Mbps are different: 1 MB/s is about 8 Mbps.
- Intermittent drops: Note whether the issue occurs only after waking the device, switching Wi-Fi networks, or changing between Wi-Fi and cellular.
- Scope: Note whether all destinations are affected, just one website, or only a particular app.
Layer 1: Check your local network and routing mode first
Your local network includes the wireless connection between your device and router, the router’s internet connection, and the network you are currently using. A weak Wi-Fi signal, heavy traffic on the same network, or a guest network that still requires sign-in can all make a remote node appear slow. Keep the node and configuration unchanged, then switch networks to see whether the issue is local.
-
Save a baseline
In Home, note the selected node and current Global Routing option, then record how the fixed webpage loads. Do not update your subscription or change multiple settings at once.
-
Check routing
Go to Home → Global Routing. Config applies the rules in the current configuration; Proxy uses a global proxy mode; Direct sends traffic directly. Scene uses scene-based settings and should not be treated as a fixed speed-test mode.
-
Compare with Direct
For a regular destination that you know is permitted to connect directly, temporarily use Direct for comparison. This changes the request route, so pause sensitive activity first and restore the original setting after testing. If the direct connection is slow too, check your local network first.
-
Switch networks
If possible, use the same device and node on both Wi-Fi and cellular, reconnect, and test the same destination. Do not switch networks and nodes at the same time.
-
Check On Demand
If the connection automatically reconnects after you disconnect, check Settings → On Demand. Before temporarily disabling it, note the original settings and restore them after your comparison. On Demand controls when to connect; it does not increase bandwidth.
If the connection is slow only on a particular Wi-Fi network but works normally on cellular with the same configuration, check the Wi-Fi signal, router load, and network restrictions first. If both connections are slow, do not assume the node is at fault; check the protocol and actual routing next. Direct and proxy connections use different routes. A faster direct connection only shows that the destination is reachable over another route; it does not identify where congestion occurs.
Layer 2: Verify protocol settings; don’t change MTU or ports blindly
From Home, open the edit screen for the current node and compare each field with the original settings from your provider. Server, Port, authentication, transport, and TLS settings must match as a set. The port is part of the server’s listening configuration. For example, if the original configuration uses 443, that does not mean every node should be changed to 443. A familiar port number does not prove that the server offers the same protocol on that port.
| Protocol or setting | What to check | Common misconception |
|---|---|---|
| Shadowsocks | Server, Port, password, and encryption method must all match the same server configuration. | Changing only the encryption method cannot compensate for mismatched server settings. |
| VMess / VLESS | Check authentication, transport, and any required Host, Path, and TLS settings. | Being able to reach a port does not confirm that the transport and authentication succeeded. |
| Trojan | Check the password, server name, and information required to validate the certificate. | If certificate validation fails, turning it off is not a speed optimization. |
| Hysteria2 | Check the authentication details and port, and confirm that the current network allows the required UDP traffic. | Working TCP connections do not mean the UDP route is working too. |
| WireGuard | Check the key, Endpoint, tunnel address, AllowedIPs, and MTU against the original configuration. | A tunnel handshake does not mean all destination addresses are routed correctly. |
If small webpages load but large responses or long connections stall, a path MTU issue is one possibility. Packet loss, server-side throttling, or the destination website can cause similar symptoms. Restore the MTU from the original configuration and keep a copy. Change one setting at a time, and only when you have guidance that applies to your setup. MTU is measured in bytes, not speed; a higher or lower value does not automatically mean a faster connection.
Connectivity Test: reachability is not throughput
Run the test from Home → Connectivity Test. Record the current network, selected node, Global Routing setting, and result under the current configuration. Check the app’s current settings to see exactly how the test is run and which destination it uses. The reported milliseconds measure response time under those test conditions, not file transfer speed, and cannot be directly converted into video quality.
- Low latency, slow transfers: Short requests may work normally while sustained traffic is limited. Check the stable rate with the same fixed file, and confirm that the destination is actually using the selected node.
- Highly variable results: Repeat the test three times on the same network and node, and record the range rather than keeping only the best result. Variation may be caused by Wi-Fi interference, route congestion, or remote load.
- Test fails, but webpages load: Check the test destination and current routing. A particular test request may fail while webpage requests follow a different rule or use a different connection method.
- Test succeeds, but one website fails: Check that website’s DNS, matching rules, TLS, and service status. A successful test does not prove that all destinations are working.
With Config, requests follow the rules and policies in the configuration. Check the currently enabled file in Config, paying attention to DOMAIN-SUFFIX, GEOIP, IP-CIDR, and FINAL. Domain and address rules match different conditions; FINAL is the fallback when no earlier rule matches. Changing the selected node in Home may not affect requests that match DIRECT or another policy. After temporarily switching to Proxy for comparison, restore the original routing mode and start a new request rather than reusing an existing connection.
Layers 3 and 4: Separate route fluctuations from node load
Route quality describes the path from your network connection to the remote endpoint; node load describes the remote service’s capacity to handle connections and transfers. The client usually cannot distinguish the two from a single latency reading. The goal is not to assign a definite cause based on symptoms, but to narrow down the issue through comparisons and give your provider evidence they can reproduce.
| What stays the same | What you observe | What the result may indicate |
|---|---|---|
| Same node and destination; change only the network connection | Performance stays poor on only one type of connection. | Check that connection and its route to the node first; this does not prove the remote service is generally faulty. |
| Same connection and destination; switch to another node already in your configuration | Only one node is noticeably slower. | That node or the route to it needs further investigation. |
| Same configuration and connection; repeat at different times | Performance is poor at regular busy times but improves at other times. | Record possible congestion or capacity limits, but do not infer the location of congestion from timing alone. |
| Same node and connection; change the destination | Only one destination is slow. | Check the destination service, restrictions on the destination side, and the route from the node to the destination. |
Compare only configurations you already have and are authorized to use; there is no need to look for another service to troubleshoot. When you send your results, include the test time and time zone, connection type, node label, protocol, destination type, and all three results. Before sharing, remove passwords, PrivateKey values, full subscription URLs, and links containing authentication details. Cover this information in screenshots too. The app purchase and network service are separate; buying the app does not include remote route capacity.
When logs show errors: identify the failed stage from the exact message
The following standard error snippets may appear in network logs. They are not shown for every issue and are not fixed messages in every screen. Save the complete error as it appears, then review request records from around the same time. Error text can help identify the stage that failed, but it cannot replace comparing the network and settings or establish fault on its own.
Error: connection refused
Cause: The destination or a device along the route actively rejected the connection. Common checks include the address, listening port, and service status.
What to do: Check that the current node’s Server and Port match the original settings, then ask your provider to confirm that the service is running on that port.
Error: i/o timeout
Cause: A network read or write did not complete within the allowed time. Packet loss, an unreachable route, or a slow remote response can all trigger this error.
What to do: Keep the node unchanged, switch networks, and test again. Record the destination and time around each timeout; increasing the wait time will not fix throughput.
Error: certificate has expired or is not yet valid
Cause: The certificate validity period or device date and time do not meet validation requirements. The failure occurs during secure connection validation.
What to do: Check the system date and time, then ask your provider to verify the certificate’s validity period. Keep certificate validation enabled; skipping validation is not a fix.
Common questions: when to keep troubleshooting and when to stop
Why does video still buffer when latency is only a few dozen milliseconds?
Latency describes the response to a short request, not the bandwidth available for sustained transfers. Keep the selected node in Home and Global Routing unchanged, check the stable rate with the same fixed file, and compare different destinations. If only the video service is slow, check the destination and actual routing before changing the protocol.
Why is the result almost unchanged after switching nodes?
First, check in Home → Global Routing that the mode is Config. Then inspect the current rules and matched policy in Config. The request may use DIRECT, a fixed policy, or an existing long-lived connection. A comparison is meaningful only after confirming that test traffic uses the new node and sending a fresh request.
Do I need to rebuild my configuration if things slow down after switching Wi-Fi?
Not as a first step. Confirm that the new network has internet access, stop any ongoing transfers, then disconnect and reconnect before testing the same destination. If the system reconnects automatically, check the existing conditions in Settings → On Demand and note whether the issue occurs only after switching networks.
Every setting matches, but it’s still slow. What else should I change?
Stop making random adjustments. Restore the baseline configuration, save three repeat results and comparisons across networks, then send your provider a record with sensitive information removed. Remote capacity, cross-network routes, and destination service status cannot be diagnosed or fixed simply by changing client settings.
After troubleshooting, restore the original Global Routing and On Demand settings, along with any temporary changes. Keep a record of conditions when everything worked normally so you can compare them if the issue returns. Shadowrocket is primarily used on iPhone and iPad. Compatibility with Mac and other Apple platforms, as well as system requirements, is listed on the App Store page. Wireless conditions and test setups vary by device, so record results separately for each one.