For readers who have imported their own subscription into Shadowrocket and need to choose a node for everyday use. Test candidates under the same network conditions, check the region required by your target service, and compare real-world results. Use protocol type to check compatibility, not to rank speed.
Set consistent test conditions first
Shadowrocket is a paid Apple-platform app available through the App Store, primarily used on iPhone and iPad. Refer to the App Store listing for other compatible devices and system requirements. It uses configurations you import; purchasing the app does not include network service. A one-time app purchase is not a service plan. The steps below assume you already have your own provider and subscription, and that the nodes appear in the Home list.
Before comparing nodes, identify the problem you want to solve: access to a specific region, slow page loads, or frequent connection drops. Each calls for different indicators. If you switch between Wi-Fi and Cellular or change Global Routing while testing, the results are not from the same conditions and cannot be compared directly.
Before testing, note whether you are on Wi-Fi or Cellular and which website or app you are testing. Keep the device in the same place and stay on the same network where possible; if the network changes between rounds, run the test again. Record each candidate’s name, region, displayed latency, connection status, and whether the target content loads properly. That is more useful than saving a single millisecond figure.
What the latency figure measures
The latency result in the Home node list is the response time for a test request under specific measurement conditions, usually shown in milliseconds. It can help identify candidates that fail to respond or respond noticeably slowly during the test, but it is not the sustained throughput of the full connection path. Results also depend on the test target, timeout settings, current network conditions, and node load. Treat a single result as a snapshot, not a long-term guarantee.
Loading a webpage also involves resolving the domain, establishing a connection, transferring page resources, and processing by the website itself. A quick response to a short test request does not mean larger content such as images or video will load quickly. Conversely, a high result may reflect a brief network fluctuation. In particular, distinguish between “the node test returned a result” and “the target traffic actually went through that node.”
Check the node list
In Home, view the nodes from your own subscription. If you have not imported it yet, go to Home → “+” → Type → Subscribe and add your own subscription URL, then return to the list and confirm that the nodes have loaded. This example URL,
https://example.com/sub?token=xxxx, is for format illustration only.Test on the same network
Stay on the same Wi-Fi or Cellular connection. Run latency tests on the candidates in the Home node list and note which ones do not respond, respond noticeably slowly, or return similar results.
Switch one at a time
Select one candidate at a time, connect, and visit the same target website. To check the selected node’s direct performance, first verify Proxy under Home → Global Routing. Restore your previous mode after testing.
Test again to confirm
Retest candidates with similar results several times under the same conditions, and open the target content for real. Keep the one that performs consistently, rather than choosing solely by its lowest reading in a single test.
When Global Routing is set to Direct, target traffic may connect directly, so a fast page load does not prove the selected node is fast. With Config, rules in the configuration determine where different requests go; Scene involves scene-based conditions. Check the current mode before comparing. If you use Config, also check which rule matches the target domain so different routing outcomes are not mistaken for node differences.
Balancing distance and the target region
Choose a region based first on the target service’s requirements, then on connection performance. If the target content requires a specific exit region, first filter your existing subscription for nodes in that region, then compare stability among those candidates. If no region is required, start by testing nodes in regions closer to your current network. Shorter physical distance can sometimes reduce round-trip time, but carrier routing, congestion, and detours can also affect results.
The region in a node name is a label set by the configuration provider; it does not guarantee how every target website will be accessed. If a region matters, check the region and availability shown by the target service itself. Do not infer the exit location from the node name or latency alone. The two sequences below show how to choose, not a regional speed ranking.
Target requires a specific region
- Filter first
- The exit region required by the target service
- Then test
- Multiple candidates in that region
- Finally, check
- Whether the target content loads properly
Meet the region requirement before comparing latency across regions.
No region requirement
- Start with
- Existing nodes in nearby regions
- Rule out
- Candidates that fail to respond
- Keep
- Nodes that perform consistently across repeated visits
Routes and congestion change; closer does not always mean faster.
For example, on the same network, a node in a nearby region may show lower latency but repeatedly stall while loading the target page. A node in another region may have a slightly higher reading yet load the page consistently. For this target, prioritize the latter’s real-world performance and test again later. The ranking may not apply to another service, since its servers and network path are different.
Protocol type is not a speed ranking
Your existing subscription may include nodes using different protocols, such as Shadowsocks, VMess, VLESS, Trojan, Hysteria2, or WireGuard. A protocol name describes the technology used for the connection; it cannot tell you which option will be fastest on your current network. Nodes using the same protocol can also differ in region, route, and load. When comparing different protocols, keep the test network and target the same.
First confirm that the node connects properly and that all required configuration parameters are included in your own subscription. Then check how the target content performs in practice. If a node type connects reliably over Wi-Fi but repeatedly times out over Cellular, record the results separately for each network rather than treating this as a fixed trait of every node using that protocol. Use your own configuration for protocol settings; changing a label cannot fill in missing parameters.
- Cannot connect: First check that the subscription updated successfully and that the node is still listed. Then verify that your current network is working. There is no point ranking latency until the connection issue is resolved.
- Connects, but loads slowly: With Global Routing set to the same mode, compare the first visit, subsequent visits, and sustained loading for the same target. Do not rely on a single instant test result.
- Some destinations work: If you use Config, check which rules match. For example,
DOMAIN-SUFFIX,example.com,PROXYandGEOIP,CN,DIRECTsend different requests through different policies, whileFINAL,PROXYapplies to traffic that does not match an earlier rule.
Rules are matched from top to bottom, and matching stops at the first applicable rule. Before comparing protocols or nodes, confirm which policy the target request actually uses. Comparing a result with target traffic routed through Direct against another with traffic routed through Proxy can make a routing difference look like a protocol difference.
How to interpret common test results
If the numbers look good but performance feels poor, first distinguish the test method, connection status, and target routing. A latency result is not a webpage speed test and cannot replace checking access in the target app. The checks below are organized by symptom. Change one thing at a time so you can identify what made a difference.
Why is the webpage still slow on the lowest-latency node?
Use the same webpage and open it repeatedly. Check whether the delay occurs during the initial connection or whether content such as images continues to load slowly. Then check Home → Global Routing. If it is set to Config, inspect the rule that matches the target. Once routing is confirmed, repeat the test with another node in the same region.
Should I delete a node that times out?
First check whether your device can access other content on its current network, then test again on that same network. If several nodes in the same group time out, check the subscription contents and network status first. If one node continues to fail, temporarily remove it from your everyday shortlist.
Works on Wi-Fi but unstable on Cellular?
Record the test results and real-world access separately on each network. If Settings → On Demand is enabled, also check its Wi-Fi and Cellular conditions. Confirm that the connection behaves as expected when the network changes, then compare node performance.
The region label matches, but the target shows a different region?
First confirm that the target traffic is actually going through the selected node rather than taking another route through Direct or a matching rule. Then verify the exit region using information shown by the target service; do not rely on the node name alone.
If two candidates have similar latency readings, there is no need to switch frequently over a tiny difference. A more useful record is which one completes the real task consistently under the same network, target, and routing mode. Network conditions change, so retest if performance noticeably declines later.
Follow a repeatable selection process
For everyday use, focus on three questions: Does the target require a specific region? Can the candidate connect right now? Does the content load reliably in practice? Filter by region first, use latency tests to narrow the options, then verify with the real target. Use protocol type to check configuration and connection behavior, not as a substitute for those checks. This approach also makes it easy to compare again after changing Wi-Fi, Cellular, or the target service.
- In Home, confirm that your subscription and node list have loaded, and note your current network.
- Filter candidates by the target region. If no region is required, choose a few nodes from your existing subscription for testing under the same conditions.
- Check the mode under Home → Global Routing. Select nodes one at a time and repeatedly access the same target.
- Keep nodes with reliable connections and loading performance. Retest when conditions change; do not draw new conclusions from old readings.
To verify where to get the app, refer to its App Store product page: the app is named Shadowrocket, the developer is Shadow Launch Technology Limited, and the app ID is 932747118. The purchase covers the app itself; the selection steps in this guide assume you already have your own subscription or configuration.