If Shadowrocket is slow, first keep the test target and Global Routing setting consistent. Check connectivity for your existing nodes, then compare routes, protocol settings, and Wi-Fi versus cellular. This guide is for users with their own provider and subscription who can connect but experience slow responses or unstable transfers. The goal is a reproducible set of comparisons—not changing every setting based on a single latency reading.
Before you start: Keep test conditions consistent and distinguish latency from throughput
First, a key point: Connectivity Test results are not the same as download speed. Latency measures how long a test request takes to complete. Sustained transfers also depend on available bandwidth, packet loss, congestion, and limits imposed by the destination server. A node that responds quickly to a test can still be slow when transferring a large file; a slow-loading webpage does not prove that the entire connection is slow.
In Home, note the currently selected node and Global Routing setting. If you normally use Config, keep it as your baseline. To isolate the effect of rules, temporarily switch to Proxy and confirm that the request being tested actually goes through the selected node. Scene selection should remain unchanged during this comparison. Direct does not represent the speed of a proxy route.
- Choose a regular destination and observe the first visit, repeat visits, and a sustained transfer. Don't compare different sites as if they were interchangeable.
- Pause high-traffic activity on other devices. Record the test time, network type, node name, Global Routing setting, and any timeouts.
- Repeat each test three times under the same conditions. Record every result or the median, not just the fastest run.
- Change one variable at a time and reconnect after each change. Restore the original Global Routing setting when testing is complete.
Layer 1: Is the node available, or is only the test responding normally?
In Home, run Connectivity Test for the selected node, then verify it with a real request. A successful test only confirms reachability under those test conditions. If it fails, distinguish between an unreachable server, an authentication error, and an unreachable test destination. Repeatedly refreshing a subscription is not a substitute for diagnosing a node; updating the list does not resolve remote-server load or route congestion.
- Check that the node address, port, protocol, and authentication fields match the information you already have. Use the port specified by your provider. Even if you see the commonly used
443, don't change another port to it without confirmation. - On the same network and with the same Global Routing setting, select another node already in your list and repeat the same request. If possible, start with an entry using the same protocol to minimize variables.
- If only one node repeatedly fails, record the test time and error. If all nodes are slow, continue by checking the shared route, local network, and test destination.
- If you suspect the node information has changed, use the existing Subscribe update option once, then verify which entry is selected. A successful subscription update does not mean the node is reachable.
These are common snippets from connection logs. Exact wording varies by protocol and underlying connection. Treat them as clues, not definitive diagnoses; check whether the error occurs during DNS resolution, connection setup, or data transfer.
Error: connection refused
Possible cause: Nothing may be listening on the destination port, or an intermediary may be actively rejecting the connection.
What to do: Check the address and port of the existing node, then ask your provider to verify the server status at the time the error occurred.
Error: i/o timeout
Possible cause: The connection or a read/write operation did not complete within the time limit. Packet loss, congestion, or an unresponsive remote server may be involved.
What to do: Keep the same node and retest on another network, then compare it with another existing node. Don't assume the protocol is the cause.
Error: no such host
Possible cause: The current lookup did not return a valid result for the required hostname.
What to do: Check the hostname spelling and DNS settings. Determine whether the failed lookup was for the node hostname or the destination hostname.
Layer 2: Distinguish route congestion from rule-based routing
A node is the remote entry point for a connection. The route also includes your local access network, the path through your carrier, the node's exit, and the path from that exit to the destination site. Two nodes with different names may share part of a route. So switching nodes and still seeing slow speeds does not rule out a route issue. Likewise, a successful test to one destination does not mean all destinations will work normally.
| Comparison | What you observe | Next step |
|---|---|---|
| Same node and network, different times | Sustained transfers slow down during busy hours and recover at other times | Record results at multiple times and check for a recurring congestion pattern |
| Same node and network, different destinations | Only one site is slow; other destinations work normally | Check the rules, resolution, and remote response for that destination |
| Same node and destination, Config vs. Proxy | Proxy works normally, but Config is slow or fails | In Config, check the active configuration and which rule the request actually matches |
| Same node and destination, Wi-Fi vs. cellular | Only one type of network access is slow | Continue with local network and access-route checks |
Config routes requests according to the active configuration's rules. Proxy provides a comparison using proxy mode, but you still need to verify the actual request record. Rules are matched in order, so an earlier rule may prevent a later one from taking effect. The examples below illustrate syntax only. They are not a complete file to replace your configuration with, nor do they imply that these policies are suitable for every destination.
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXYDOMAIN-SUFFIX matches domain suffixes; IP-CIDR matches IP ranges; GEOIP matches using IP geolocation data; and FINAL handles requests that did not match any earlier rule. If a request actually goes through DIRECT, testing proxy-node latency won't explain why that request is slow. First confirm which rule it matched.
Bottom line: Confirm the route before comparing connections
If the same destination works in Proxy but remains slow in Config, first check the active configuration's matching rule and DNS results. Confirm that both requests take the same route before comparing node or route performance.
Layer 3: Correct protocol settings matter more than switching protocols
Shadowsocks, VMess, VLESS, Trojan, Hysteria2, and WireGuard use different transport and authentication mechanisms. You can't switch by changing only the protocol name on a node. Each connection needs matching server-side support and complete parameters. Compare only configurations you already have and have verified as working. If the two configurations use different servers, the performance difference cannot be attributed entirely to the protocol.
- Shadowsocks: Check the encryption method and password. If you're using a plugin, also verify that the plugin and its parameters match the server requirements.
- VMess/VLESS: Check the identity fields, transport, and settings such as TLS. If you're using WebSocket or gRPC, make sure the path or service name matches the server.
- Trojan: Check the password and TLS server name. If certificate validation fails, check the device time, domain name, and certificate chain. Don't disable validation as a way to improve speed.
- Hysteria2: It uses QUIC and requires a working UDP route. If the current network restricts UDP, you may see handshake failures or instability. Don't assume it will be faster on every network.
- WireGuard: It uses UDP. Check the keys, endpoint, and routing parameters. If small requests work but larger transfers stall, consider MTU as one item to investigate—but first rule out packet loss and server-side issues.
This flow shows why “the connection switch is on” and “the destination can transfer data reliably” are not the same thing. If the handshake fails, check authentication, TLS, or the underlying transport first. If the handshake completes but transfers then slow down, investigate packet loss, congestion, remote-server load, and the destination's response. Don't change MTU, DNS, protocol, and node settings all at once; even if performance improves, you won't know which change helped.
Layer 4: Check Wi-Fi, cellular, and DNS on your device
Keeping the same node and destination, test first on Wi-Fi and then on cellular. This is a straightforward way to spot differences in local network access. Watch your data usage before switching. After switching, wait for the network to stabilize and reconnect. Different results indicate a difference in the access environment or route, but don't by themselves prove that the router, carrier, or node is at fault.
- Check basic access: Temporarily disconnect Shadowrocket and visit a commonly used page that normally opens directly. If direct access is also slow, check your local network first. Don't use a destination that you couldn't access directly in the first place for this test.
- Check Wi-Fi conditions: Retest closer to the router, pause high-traffic activity on your local network, and make sure you've completed the sign-in page for public Wi-Fi. The number of signal bars doesn't fully indicate available bandwidth.
- Separate DNS lookup from data transfer: If the first visit takes a long time but content transfers normally afterward, check whether DNS requests are timing out or being retried. Don't change all your DNS settings based on this symptom alone.
- Check for automatic connection changes: In Settings → On Demand, review the existing conditions and see whether a network change triggers a reconnection. To establish a manual-test baseline, note your original settings, temporarily turn off On Demand, and restore it after testing.
- Keep IPv6 details: If the issue occurs only on a particular network, record whether the DNS result includes an IPv6 address and whether the related connection fails. Don't treat disabling IPv6 as a universal fix without comparison results.
Changing DNS affects how names are resolved and which addresses may be used afterward; it does not directly increase route bandwidth. If an ongoing download is already established and consistently slow, repeatedly changing DNS usually won't identify the bandwidth bottleneck. If the request is stalled during resolution, check the lookup result and request route instead of continuing to adjust protocol settings.
Common questions: Low latency, subscription updates, and slowdowns at night
Why is my download slow when latency is only a few dozen milliseconds?
Latency tests and sustained-transfer measurements measure different things. Keep the same node and destination, observe the transfer repeatedly, and note whether speed drops after the first few seconds. Then compare with another destination to help distinguish route congestion from destination-side rate limits.
Can updating Subscribe make an existing node faster?
An update can sync changed addresses or parameters in an existing subscription, but it doesn't add bandwidth to your current connection. Update only if you suspect the node information is outdated or has changed. Then check the selected node in Home and test again.
Why is it slow only at night but fine during the day?
First, use the same node, network, and destination to record results at different times, and rule out high-traffic activity on your home network. If the difference recurs, share the times, failure rate, and results from comparable tests with your provider. Don't draw a conclusion from a single test.
If all nodes are slow, does that mean there's a problem with Shadowrocket settings?
Not necessarily. Shared factors can include Wi-Fi, the access route, DNS, rules, and the test destination. Compare Wi-Fi with cellular, then Config with Proxy. Once you know which variable the issue follows, check only the relevant settings.
Document the results: Make the troubleshooting process reproducible
The goal of troubleshooting these four layers is to narrow down the issue—not to reset every option. After comparing results, restore your original Global Routing and On Demand settings. Revert any changes that the evidence doesn't support. If you need help from your provider, share only the relevant symptoms and connection details. Don't disclose a full subscription URL, password, private key, or authentication token.
- Environment: iPhone or iPad, Wi-Fi or cellular, time of occurrence, and duration.
- Connection: The selected node's identifying name, protocol, Global Routing setting, and whether you retested with the same destination.
- Results: The raw results from all three tests, what happened during actual access, any error snippets, and a comparison using another network or another existing node.
- Actions taken: List each setting you changed and whether you restored it, so the next check starts from a known state.
Bottom line: Describe “slow” in reproducible terms
“The same node timed out three times in a row on Wi-Fi and succeeded three times after switching to cellular” is more useful than simply saying “it's slow.” This points to an access route worth checking while leaving room for further verification.