This guide is for users with their own service and subscription who can connect but are experiencing slow access. First confirm the app and test conditions, then compare nodes, routes, protocols, and local networks one variable at a time. Finally, use rules and connection logs to interpret the results—latency, throughput, and initial page load time are different measures.
1. Set a baseline: Identify what feels slow
Shadowrocket is a paid Apple-platform app available on the App Store, sold as a one-time purchase. To verify the genuine app, check the official icon, developer name Shadow Launch Technology Limited, and app ID 932747118. See the App Store listing for compatibility and system requirements. Buying the app and having a connection service are separate matters; purchasing the app does not change your route's bandwidth.
Before troubleshooting, save a copy of your current configuration in Config and note the selected node in Home and the current Global Routing mode. A slow first page load may involve DNS, connection setup, or the destination site's response. Slow transfers over time point more toward throughput; intermittent slowdowns may involve congestion, wireless interference, or connection resets. Don't change nodes, protocols, and DNS all at once.
- Choose one page you visit regularly and one larger file that is available for normal access. Check initial load time and sustained transfer separately.
- Keep the device, destination, node, and test time consistent. Pause high-bandwidth tasks on other devices, and run only one test at a time.
- Record the time, network type, whether the connection succeeded, initial load time, and transfer rate after it stabilizes. Use measurements from your own device, not advertised figures in node names.
- Watch the units: MB/s and Mbps are different. 1 MB/s equals 8 Mbps. Convert to the same unit before comparing.
2. Node status: Confirm the connection works
Select the node you're using in Home and run Connectivity Test. A successful test means the selected method can probe the target; it doesn't mean every site is reachable or that sustained bandwidth is sufficient. Results from different test methods shouldn't be compared directly, and a single low-latency result doesn't guarantee high speeds.
If the current node repeatedly fails, first check the address, port, account credentials, and whether the service is active. Then compare it with another working node in your existing configuration. A successful subscription import only means the app received and parsed the content; it doesn't confirm that every connection in it works. To refresh, update the relevant subscription in Home and check whether the node settings actually changed. Don't delete working entries before testing.
Error: Connection refused
Cause: The connection was refused. This commonly happens when the destination port isn't listening or an intermediate device actively rejects the connection. Fix: Check the address and port against your service configuration, then ask the service maintainer to verify the listening status. Changing the test target won't fix a refused port.
Error: Operation timed out
Cause: The network operation didn't complete within the allowed time. The destination may be unreachable, packets may be dropped, or the service may not respond. Fix: Keep the same node and compare Wi-Fi with Cellular, then test another existing node to narrow down whether the issue is local or remote.
These are common error messages in network diagnostics; the exact wording depends on the log source. When recording an error, include when it occurred, the target, and the stage of the operation. “VPN connected” only means the system tunnel is up; it doesn't confirm that the proxy server and destination site are communicating successfully.
3. Route quality: Check latency, packet loss, and throughput separately
The same node address doesn't guarantee the same route or load at different times. Evening congestion, wireless packet loss, remote exit load, and destination throttling can all make file transfers slow even when a probe succeeds. Compare repeated results for the same target rather than keeping only the best one.
| What you observe | Likely cause | What to check next |
|---|---|---|
| Slow initial load, then steady transfer | DNS, handshake, or destination response | Compare the first and subsequent page loads, then check the connection log. |
| Sustained slow transfers to multiple destinations | Shared route or node exit bottleneck | Keep the network unchanged and repeat the same task with another existing node. |
| Only one destination is slow | Destination site, content delivery, or a specific route | Check which policy the domain actually matches before changing global settings. |
| Noticeably slower at certain times | Time-dependent congestion or load | Record results at two times under the same conditions and share them with the service maintainer. |
If you use a network diagnostic tool to check packet loss, note the probing method. Some servers limit ICMP responses, so ICMP packet loss doesn't necessarily mean an equivalent loss of application traffic. Consider actual connection timeouts, transfer stalls, and retries; don't judge a route by a single percentage.
Bottom line: Locate the scope of the slowdown before changing connection settings
If only one destination is slow on the same network, check its rules and route first. If multiple destinations are slow but recover on another existing node, prioritize sharing a comparison of the original node and route rather than continuing to change local DNS settings.
4. Protocol settings: Match the server configuration, not assumptions about speed
Shadowsocks, VMess, VLESS, Trojan, Hysteria2, and WireGuard use different settings and transport methods. Switching protocols requires a matching server configuration; changing the protocol type for the same address won't make the connection work. The server configuration determines the port. Using port 443 doesn't guarantee that the protocol, TLS, and authentication settings are correct.
- Shadowsocks: Check the encryption method, password, and any required plugin settings. Incorrect authentication affects connectivity; it isn't a speed-tuning option.
- VMess / VLESS: Check the user ID and transport settings. With WebSocket, also verify the path and relevant Host settings; if TLS is enabled, check the server name.
- Trojan: Check the password, TLS server name, and certificate validity. Disabling certificate verification is not a routine speed fix.
- Hysteria2: Uses QUIC-based transport and requires the current network to allow the relevant UDP traffic. A successful TCP test doesn't confirm that these connection requirements are met.
- WireGuard: Check the keys, Endpoint, addresses, and routing scope. Adjust MTU only if there is clear evidence of a path MTU issue, and follow the configuration maintainer's guidance.
Save the original values before changing settings, change only one item at a time, and repeat the baseline tests. Don't arbitrarily increase concurrency, enter bandwidth values far beyond the route's actual capacity, or repeatedly change MTU; these can introduce queueing, packet loss, or connection problems. If a subscription refresh overwrites node fields, check whether your changes are still in place afterward.
5. Local network: Compare Wi-Fi and Cellular using the same node
Keep the node, configuration, and destination unchanged and switch only the local network. This is a straightforward way to distinguish wireless conditions from remote service issues. Wi-Fi signal bars don't show interference, backhaul congestion, or router load. Cellular performance also depends on location, coverage, and time of day. Before testing over cellular, check your data plan; a test of the same size is enough.
- Run the same test three times on Wi-Fi. Note whether other devices are uploading, streaming video, or syncing in the background.
- Turn off Wi-Fi, confirm the device has switched to Cellular, and wait for the connection to stabilize before testing. This avoids mistaking a brief reconnect during the network switch for sustained slow speeds.
- If only Wi-Fi is slow, test again near the router and check whether other devices are using all the upload bandwidth. If possible, compare different Wi-Fi bands.
- If both networks are slow, confirm they use the same node and rules, then continue troubleshooting at the node and route layers.
6. Check the rules: Confirm traffic is taking the expected route
In Global Routing, Proxy sends traffic through the current proxy policy, Direct connects directly, Config follows the rules in the current configuration, and Scene applies the selected scene. Record the current mode while troubleshooting; don't rely only on the connection toggle in Home. Selecting a file in Config doesn't confirm that the app is currently running in Config mode.
This minimal rule snippet illustrates matching order; it's not a general-purpose speed configuration. example.com is an example domain, and 192.0.2.0/24 is a documentation-only network range. Don't copy them as real destinations. Before applying anything to an existing configuration, decide which destinations should use DIRECT and which should use PROXY.
[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYDOMAIN-SUFFIXmatches the specified domain suffix and its subdomains. If an earlier domain rule matches, later rules generally won't determine the policy for that request.IP-CIDRmatches an IP address range.no-resolveprevents this rule from triggering a domain lookup; it doesn't disable DNS for the entire app.GEOIPrelies on an IP geolocation database and can't replace checking the specific domain and actual connection destination.FINALis the fallback when none of the preceding rules match and should go at the end of the rule list. Changing FINAL alone won't override a rule that already matched.
Open the connection log, find the target you just tested, and check its domain, matched rule, and final policy. If a brief test using Proxy works while Config remains slow, investigate the rules, policy selection, and DNS-related settings first. This narrows down the issue but doesn't prove that the entire configuration needs replacing. Restore the original Global Routing mode after the comparison.
7. Common questions and what to include in a troubleshooting report
Latency tests look good, so why does video still buffer?
A latency test and sustained video playback use different workloads. Keep the video quality fixed and check for repeated buffering, then compare another destination. Also check whether the video domain actually uses DIRECT or PROXY; a node probe isn't a substitute for testing the service itself.
Things slowed down after a subscription update. Should I delete all the nodes?
Keep the original configuration and working entries. Check the updated addresses, ports, protocols, and currently selected node. Confirm whether the selected node changed, then retest with the same destination. Deleting entries removes useful comparison points and won't fix congestion on a remote route.
It takes a while to work after switching from Wi-Fi to cellular. Is that slow speed?
First distinguish a reconnect during the network switch from slow sustained transfers. Check the trigger conditions in Settings → On Demand and start timing only after the connection stabilizes. If speeds return to normal once connected, record the reconnect behavior separately from throughput.
What information should I send to my service maintainer?
Include when the issue occurred and the time zone, network type, node identifier, destination, exact error message, and results from changing one variable at a time. Hide subscription tokens, passwords, private keys, and full authentication links. Share only the diagnostic details needed, and don't expose credentials in public discussions.
Before finishing, restore the Config, Global Routing, and On Demand settings from before testing, then revisit a regular destination. Keep a brief record of what changed, whether the issue was consistently reproducible, and whether it returned after restoring the original values. Repeatable differences are more useful for troubleshooting than a single speed-test screenshot. For more rule syntax, see Troubleshooting; for terminology, see Glossary.