Shadowrocket Slow Connection Troubleshooting: Check Nodes, Network Routes, Protocols, and Local Network

1. Set consistent test conditions and pinpoint the slowdown

An enabled connection switch only confirms that the system tunnel is up; it does not prove that a request reached its destination through the selected node. A slow initial page load, slow sustained downloads, and frequent video buffering are different symptoms. The first may involve DNS or connection setup; the others call for checking sustained throughput and transport stability.

In Home, note the current node, Global Routing setting, and local network. Then check which configuration is active in Config. During testing, don't refresh subscriptions, change DNS, switch protocols, and edit rules at the same time. Otherwise, even if speeds improve, you won't know which change made the difference.

1. Choose a specific page or file that you can access and load repeatedly, and note its name. Don't compare download speeds from two different sites.
2. Pause system updates, photo syncing, and other high-bandwidth tasks. Run 3 tests in a row, each for about 30 seconds. Record time to first content, sustained speed, and any interruptions.
3. Use consistent speed units. 1 MB/s is about 8 Mbps; don't treat the MB/s shown for file downloads as the same number as a broadband speed in Mbps.
4. Change one condition per test round and run comparisons at roughly the same time. Cellular testing uses data, so check your plan allowance first.

2. Node checks: distinguish reachability from throughput

In Home, run Connectivity Test for your existing nodes to rule out ones that are clearly unreachable. Latency reflects the response under a specific test method, not download bandwidth. The test target, handshake, and whether traffic goes through a proxy all affect the result, so don't judge the experience by the lowest millisecond reading alone.

Choose two nodes from your existing subscription, preferably using the same protocol, and test them against the same target on the same local network. If only one remains consistently slow, narrow the issue to that node or its route—but don't assume the server is overloaded.

3. Network routes: compare across times and networks

A route isn't a separate switch in the node list. A request involves at least two paths: from your local connection to the server, and from the server to the destination site. Even when the node name and region stay the same, routing, congestion, and content delivery can change. A nearby location doesn't guarantee a shorter network path or stable performance during peak hours.

1. Same node, different network: On your iPhone, turn off Wi-Fi and access the same destination over cellular. Then switch back to Wi-Fi and test again. Keep all other conditions the same.
2. Same network, different time: Test once during the problem period and again at a quieter time. Record the time and sustained speed instead of just writing “slow in the evening.”
3. Same node, different destinations: Test two unrelated sites. If only one is slow, check the route from the exit to that destination before changing local DNS again.
4. Compare the results: Note patterns such as “slow on Wi-Fi, fine on cellular” or “slow on both networks at the same time.” In the first case, check Wi-Fi access and its upstream route first; in the second, compare results across nodes and destinations.

Differences between two networks on the same node can't fully separate carrier routing from the local wireless environment. If everything is slow on Wi-Fi, start with the local network checks below. If only one proxy route is slow, continue narrowing down the route. Different nodes may share upstream infrastructure, so multiple slow nodes don't necessarily indicate separate failures.

4. Protocol checks: verify transport settings instead of changing ports at random

A protocol name isn't a speed rating. Shadowsocks, VMess, VLESS, Trojan, Hysteria2, and WireGuard have different transport requirements and configuration fields; availability depends on what the server actually supports. Changing the protocol in an existing node's dropdown to another name doesn't make it a valid protocol comparison.

Port 443 doesn't necessarily mean TCP, nor does it guarantee that traffic can get through. Hysteria2 can use UDP 443, but the actual port is determined by the server. If the network restricts UDP, connections that rely on it may fail or become unstable. Conversely, working UDP doesn't guarantee higher throughput under congestion.

• Check the server address, port, and authentication details provided by your service provider. For TLS, also verify the server name and certificate validation settings. Don't disable validation as a troubleshooting shortcut.
• Compare protocols only if your existing configuration provides entry points with different protocols. If the server or route changes at the same time, label it a “multi-variable comparison” rather than attributing all differences to the protocol.
• If small requests work but large file transfers keep stalling, test on a different network first. MTU or path MTU could be a factor, but don't change multiple values in a row without recording the results.

These are low-level error messages that may appear in connection logs; they aren't guaranteed to show up for every failure. Keeping the full context is more useful than saving only the last line.

5. Local network and rules: verify where requests actually go

In Home, check Global Routing. Proxy, Direct, Config, and Scene represent different routing modes: Proxy and Direct set a global preference for proxying or direct connections; Config uses the active configuration, while Scene also depends on the selected scene's settings. Note the original setting before testing. Restore it after any temporary change so a diagnostic doesn't leave routing misconfigured.

1. Check local access: Move closer to the router and test again. Make sure Wi-Fi isn't waiting for a web-based sign-in. If your network allows it and the destination is reachable directly, briefly turn off the connection to establish a baseline. If direct access is also slow, address the local connection first.
2. Check the matched policy: In Config, verify which configuration is active. Then use connection logs to confirm which rule matched the test destination, and which policy and node were used. Selecting a node doesn't mean every request goes through it.
3. Check rule order: DOMAIN-SUFFIX matches domain suffixes, IP-CIDR matches IP ranges, GEOIP matches using IP geolocation data, and FINAL is the catch-all rule. Check whether an earlier rule matched before changing only the last one.
4. Check automatic reconnection: If the connection status changes on its own during testing, check Settings → On Demand. Note the current conditions, temporarily disable the relevant automatic connection behavior, then restore it after manual testing.

Check DNS when the symptoms point to it—for example, when the first page load is noticeably slow but downloads are steady once connected. Look for resolution timeouts, failures, or unexpected destination addresses, then check the DNS settings in the active configuration. Changing DNS isn't a universal fix for slow speeds. Don't disable certificate validation or broaden direct access without a clear reason.

6. Frequently asked questions and when to stop troubleshooting

A useful report includes the time, Wi-Fi or cellular connection, node identifier, protocol, Global Routing setting, destination, speed units, and comparison results. The goal isn't to find one “fastest setting,” but to identify which layer is affected and who should investigate next. If the access network or remote route outside the app consistently shows the same issue, further local configuration changes are unlikely to fix it.