For users with their own service provider and subscription who can connect but experience slow access. First note the node and Global Routing selection in Home, then use a consistent test target to compare the node, route, protocol, and local network in turn. Change one variable at a time. Use time to first screen, sustained transfer, and error logs to narrow down the issue; don’t mistake latency for download speed.
1. Check the connection path and identify what “slow” means
Shadowrocket is a paid client for Apple platforms, primarily iPhone and iPad. The App Store is the only place to get it; verify the developer, Shadow Launch Technology Limited, and app ID 932747118 on the store page. The app is a one-time purchase. Check the App Store page for system requirements and Universal Purchase availability. Buying the client does not include a network service plan. This guide covers troubleshooting an existing connection; it does not provide, sell, or recommend nodes or subscriptions.
“Connected” means the tunnel is established; it doesn’t guarantee that a request to a particular destination uses the currently selected node. Home → Global Routing options—Proxy, Direct, Config, and Scene—affect the actual route: Proxy uses proxy routing, Direct connects directly, Config follows the active configuration, and Scene follows the configured scene. Note the current selection before troubleshooting. If you use Config, also note the enabled configuration file and relevant policy selections.
Record the symptoms separately rather than switching protocols right away. A long wait on the first load followed by steady transfers may point to DNS, connection setup, or the destination’s time to first byte. Transfers that keep slowing down warrant checks for route congestion, server load, and local wireless quality. If only one site is slow, first check which rule matched the request and whether the destination service is operating normally.
- Time to first screen: Use the same page and record how long it takes for the main content to appear after you open it. Compare first and repeat visits; caching can affect the result.
- Sustained transfer: Use the same file you’re authorized to access and observe the transfer for at least 30 seconds. Don’t rely on a momentary peak as a measure of sustained speed.
- Connection failures: Record the time, destination domain, and exact log text. Before sharing, remove subscription credentials, passwords, and personal browsing details.
2. Node: low latency doesn’t mean high throughput
Connectivity or latency tests in Home can help identify unreachable nodes, but they don’t prove that bandwidth is sufficient. A short request completing quickly doesn’t mean the server’s outbound capacity, long-lived transfers, and route to the destination are all working well. A single timeout isn’t enough to conclude that a node has failed; test again under the same conditions.
- In Home, note the current node name, type, and connection status. If you use a policy group, check the available request records to confirm the actual outbound selected; don’t rely only on the selection indicator in Home.
- Keep the network, target file, and Global Routing selection unchanged. Test the current node three times, then repeat with another available node from a subscription you already have.
- Record latency, time to first screen, and sustained speed separately. Keep units consistent:
1 MB/s = 8 Mbps. If the interface shows different units, you can’t compare the numbers directly. - If only one node consistently performs poorly, first verify its server address, port, and authentication details. For subscription-managed entries, check whether the subscription has been updated so temporary manual changes don’t remain in place indefinitely.
Takeaway: When latency is similar, compare sustained transfers to the same destination
If two existing nodes have similar latency but only one repeatedly stalls during all three transfer tests, prioritize documenting that node’s results. Don’t change DNS, rules, and protocol settings all at once.
3. Route: compare times and destinations to spot path differences
A node’s performance can vary at different times of day because of congestion between your access network and the server, server egress load, or rate limits at the destination. A region in a node’s name doesn’t reveal its actual route, and the speed of one website doesn’t represent the capacity of an entire route. The client can help document symptoms, but it can’t fix remote bandwidth or an ISP’s network path.
| Comparison | What to record | Next step |
|---|---|---|
| Same node, same destination, different times | Does performance consistently drop at a particular time? | Test again at another time and share the time and results with your service provider |
| Same node, same network, different destinations | Is only one site or file source slow? | Check which rule matched, then check whether the destination service is operating normally |
| Same destination, same network, different existing nodes | Does only one egress path stall for an extended period? | Keep both normal and abnormal results for comparison, and check node status |
| Same node, same destination, different access networks | Is performance noticeably different on Wi-Fi and cellular? | Continue with checks of the local network and access path |
For example, you might record: “The same destination stalled in three consecutive tests on Wi-Fi, but transferred steadily after switching to cellular.” This is a troubleshooting clue, not a conclusion about remote service quality. The Wi-Fi connection, router, broadband egress, and path to the server all changed, so further testing is needed to narrow down the cause. This is an example of how to record observations, not test data collected by this site.
4. Protocol: check transport conditions instead of changing settings blindly
A protocol isn’t a standalone speed boost. Shadowsocks, VMess, VLESS, Trojan, Hysteria2, and WireGuard have different connection requirements. Actual performance also depends on the server implementation, encryption overhead, underlying transport, congestion control, and network restrictions. If your service provider offers multiple protocols but the egress and route also change, you can’t attribute the entire speed difference to the protocol.
| Protocol or transport | Conditions to check | Troubleshooting limits |
|---|---|---|
| Shadowsocks | Keep the server, port, password, and encryption method consistent; UDP support depends on the server and configuration | Fix authentication or method errors first; repeated speed tests aren’t a substitute for checking the settings |
| VMess / VLESS | Match the user ID, transport type, TLS, and related transport parameters to the server | Changing only the protocol name while keeping incompatible fields won’t work |
| Trojan | Check the password, port, TLS server name, and certificate validation settings | A TLS failure is a handshake issue; don’t mask it by disabling validation |
| Hysteria2 | Based on QUIC and requires a working UDP path; check authentication and server requirements | Network restrictions on UDP may prevent connections; this protocol isn’t guaranteed to be faster than others |
| WireGuard | Check the UDP endpoint, key, address, and routing scope | Even if the handshake succeeds, check the destination route; don’t reuse an MTU from an unrelated configuration without a reason |
If TLS is used, 443 is a common port, but it isn’t fixed for every node. Use the port provided by your own service provider. Hysteria2 bandwidth parameters don’t guarantee your device’s internet speed; setting them too high without care may worsen congestion. Keep the subscription-provided values unless the server documentation or test evidence calls for a change.
Log entry: connection refused
Cause and next steps: The destination endpoint or an intermediary actively refused the connection. First check the server address, port, and service status, then test again. Don’t treat this as ordinary insufficient bandwidth.
Log entry: i/o timeout
Cause and next steps: An operation didn’t complete within the allotted time. Use the surrounding log context to distinguish DNS, connection, or read stages, then compare the same node over a different access network.
These are examples of text that may appear in network error logs; an error won’t always display exactly the same wording. Keep the full context of the actual log, especially the stage where the failure occurred. The word “timeout” alone doesn’t tell you whether you need to change protocols.
5. Local network: check Wi-Fi, cellular, and DNS separately
Local network issues can affect subscription updates, node tests, and web access at the same time. Turning off cellular data while the device is still connected to Wi-Fi doesn’t switch the test to cellular. To compare networks, disconnect from Wi-Fi in system Settings → Wi-Fi and confirm the device is using cellular. Keep an eye on data usage from test files.
- Establish a local baseline: Keep the device in the same location and pause other high-bandwidth activity. Check whether the same destination, when directly accessible, is also slow. If it is, start by checking the router and broadband connection.
- Check for wireless interference: Retest closer to the router and, when possible, compare 2.4 GHz and 5 GHz. The frequency band doesn’t guarantee speed; distance, obstructions, and channel congestion all affect results.
- Switch access networks: Keep the node, mode, and destination the same, then repeat the test three times over cellular. If the difference is consistent, investigate the path from the access network to the server rather than immediately rebuilding the configuration.
- Distinguish DNS from transfer issues: If only the first visit to a domain takes a long time, check the active configuration’s
[dns]settings in Config and review the resolution logs. If the connection is established but remains slow, changing DNS alone usually won’t fix throughput. - Check automatic connections: In Settings → On Demand, note which conditions are enabled. If the connection is automatically triggered again during a test, check whether those conditions caused it. If you need to turn them off temporarily, record the original settings and restore them after testing.
Takeaway: Confirm the active access network before comparing configurations
Two tests aren’t comparable if the device switches automatically between Wi-Fi and cellular. First confirm which network the system is using, then decide whether to adjust Shadowrocket settings.
6. Rules and verification: confirm the request uses the expected egress
In Config mode, rules are generally matched in 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. DNS resolution, rule order, and policy group selection can all change the final route. Changing the selected node in Home won’t necessarily affect a request assigned to a different policy.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYThis snippet demonstrates rule syntax only; example.com is a sample domain and shouldn’t replace rules in your existing configuration. no-resolve prevents a DNS lookup from being triggered solely for that IP rule; it isn’t a general-purpose speed setting. Keep a copy of your current configuration, then check the matched rule and actual outbound for the problem destination. If switching briefly to Proxy changes the behavior, investigate the route in the original configuration further; that alone doesn’t prove the rule is incorrect.
Why does video keep buffering when latency is low?
Latency on a short request and sustained throughput are different metrics. Test the same video or file source three times on the same access network, then compare it with another node you already have. Also confirm that a rule hasn’t assigned the destination request to a different policy.
Switching to Proxy made it faster. Should I leave it that way?
First record the difference, then return to Config and check the rule and policy group matched by the destination. Proxy can be useful for a controlled comparison, but it changes routing for other requests too. Restore the original mode after testing, then adjust the configuration for the specific destination.
Can updating a subscription fix slow speeds?
An update may fix outdated entries only if the server address, port, or configuration has changed. In Home, update a subscription you already have and check whether the destination entry changed. A successful update doesn’t mean route congestion has been resolved.
All protocols are slow. Should I reset the app?
First compare Wi-Fi and cellular using the same node, and check a destination that’s accessible directly. Consider restoring the configuration only if you’ve identified a local configuration issue. Save the configuration and relevant records first so you don’t lose evidence needed to diagnose the problem.
Keep a minimal reproduction record before reporting an issue
- Include the device, access network, test time, and Home → Global Routing selection.
- Include the node type, destination access type, results from all three tests, and speed units. Don’t send passwords, keys, or a full subscription URL.
- Note the single change made before and after the issue, such as “same node, switched from Wi-Fi to cellular,” rather than just saying “I tried everything.”
- Restore any temporarily changed mode, On Demand conditions, and test configuration, then verify your usual destinations again.
The goal of layered troubleshooting isn’t to find a universal setting. It’s to determine whether the issue is with local access, the route to the server, server-side transport conditions, or the rules and destination response. Once the evidence points to a layer, make the smallest relevant change. For remote service issues, share redacted records with your own service provider for review.