This guide is for users who have already added their own node in Shadowrocket and can connect, but experience noticeably slow web pages or file transfers. Start with a local network baseline, then check node latency, route timing, Global Routing, protocol settings, and Log. Change one condition at a time to identify whether the bottleneck is the device network, remote route, rules, or transport settings.
Fix the test conditions first to avoid conflicting speed results
The most common speed-testing mistake is changing Wi‑Fi, nodes, protocols, and test targets at the same time. Even if the result improves, you cannot tell which change helped. Keep the device, network, test target, and test time consistent; change one variable per round and repeat each test at least three times.
First record local network performance with Shadowrocket disconnected, including initial page-load time, download speed, and baseline latency. Then turn on Shadowrocket, keep the same Wi‑Fi and test target, and record another set of results. If the local baseline is already unstable, check the router, signal, or access network before changing client settings.
Record the local baseline
Turn off Shadowrocket’s connection switch and run three consecutive tests on the same Wi‑Fi. Record latency, download speed, and first page-load time; do not keep only the highest result.
Use one fixed node
Return to Home and select one node from the user’s existing service. Do not refresh the subscription or switch nodes automatically during testing, or the test subject may change.
Use Config
In Home → Global Routing, select Config so requests follow the rules in the current configuration file. Record the configuration name during troubleshooting to avoid mistaking a rule change for a route change.
Repeat three rounds of testing
After enabling the connection, test the same target for three rounds, with about 30 seconds between rounds. If the results are 18 Mbps, 76 Mbps, and 24 Mbps, treat this as fluctuation rather than a stable speed limit.
Change one thing at a time
Retest after changing the node. Only compare protocols or transport settings after confirming that the nodes differ. Do not change DNS, MTU, Global Routing, and the node in the same round.
Layer 1: Check the local network and device connection
After an application sends a request, it first passes through the device’s current network and then the system-established VPN tunnel. Weak Wi‑Fi, a busy router, a changing access network, or packet loss on the local network can add delay before traffic reaches the remote node. Changing protocols usually will not fix the root cause.
On an iPhone or iPad, first test near the wireless router, then switch to another known-stable Wi‑Fi network and test again. If possible, compare with cellular data, but use the same node and target in both tests. If all nodes are slow on one Wi‑Fi network but recover on another, the problem is more likely in the local access layer.
Also watch for the pattern “fast immediately after connecting, then gradually slower after a few minutes.” Possible causes include wireless interference, changing router load, or the device switching between access points. Keep the screen awake for a short test, then run a continuous transfer for five to ten minutes and compare short and long connections.
- All nodes become slow: Check the Wi‑Fi signal, router load, and current access network first.
- Only one node becomes slow: The local network is usually not the primary suspect; continue checking the node and route.
- Pages are slow to open but normal afterward: Focus on DNS, connection establishment, and the TLS handshake.
- Small files are fine but large transfers slow down: Focus on route throughput, packet loss, MTU, and congestion control.
- Speed returns immediately after changing networks: Keep the existing Shadowrocket configuration and address the original network first.
Layer 2: Use Ping and time-of-day tests to identify nodes and routes
When running an available latency or Ping test from the node list in Home, do not rely on a single result. One reading of 60 ms does not prove a stable route; consecutive results of 58 ms, 62 ms, and 61 ms are generally more predictable than 35 ms, 240 ms, and 90 ms. The latter has a better minimum but obvious jitter, which can still cause pauses in web browsing and video.
Ping can also be affected by remote response policies, so use it only as an initial indicator. If latency looks normal but real-world access is slow, run an actual transfer test and check Log for the timing of connection establishment, timeouts, and retries. A remote host not responding to Ping does not necessarily mean the service is unavailable.
Route conditions by time of day matter too. Run the same test on the same node in the morning, evening, and the period when the problem occurs. If throughput drops only in the evening while the local baseline and other nodes remain normal, the pattern is more consistent with congestion on a specific route or remote resource.
Error: timeout
Cause and fix: The connection did not complete within the allowed time. Possible causes include local packet loss, a busy remote node, or an unstable route. Test another node from your own service on the same network, then retest on another network to narrow down the scope.
Error: connection refused
Cause and fix: The destination is reachable, but the specified port refused the connection. Check that the node address, port, and protocol match the details from your own service provider. Port 443 is only a common example; it does not mean every configuration should use 443.
Error: Network is unreachable
Cause and fix: The current network has no usable route, or it briefly dropped while switching between Wi‑Fi and cellular data. Wait for the system network to stabilize, reconnect, and check whether the error continues.
Layer 3: Check Global Routing, rules, and DNS
When the node itself is normal but some websites or only certain apps are slow, check Global Routing. Proxy sends requests through the current proxy policy, Direct connects directly, Config follows the configuration file rules, and Scene applies the selected scene behavior. For routine troubleshooting, first confirm that the expected Config is active rather than accidentally remaining on Direct or Proxy.
In Config mode, a request is matched against rules from top to bottom. DOMAIN-SUFFIX matches a domain suffix, GEOIP matches the geographic database result for the destination IP, IP-CIDR matches an address range, and FINAL handles requests not matched by earlier rules. Incorrect ordering can send a request that should be Direct through the proxy, or cause a request that needs the proxy to hit Direct first.
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXYThe syntax above explains matching order only; it is not suitable for every configuration. The first rule sends the specified example domain to PROXY, the second sends local network addresses Direct, the third sends traffic Direct based on GEOIP, and FINAL catches the remaining requests. Actual policy names must match policies present in the current Config.
If the symptom is “Ping is normal but the page stays blank for a long time,” also check DNS. Domain resolution occurs before the destination connection is established; resolution timeouts, unreachable addresses, or inconsistent cache results across networks can all slow the initial display. Do not replace multiple DNS settings at once. Restore a known-working configuration first, then compare one change at a time.
- Confirm the current node and Config name in Home first.
- Make sure Global Routing has not unexpectedly remained on Direct or global Proxy.
- In Config, check the first rule that matches the target domain rather than looking only at FINAL.
- For “the domain cannot be opened but the IP connects,” inspect the DNS resolution process first.
- After changing rules, start a new connection so an existing connection’s cached result is not mistaken for the result of the new rules.
Layer 4: Compare protocols and transport settings
Shadowrocket supports Shadowsocks, VMess, VLESS, Trojan, Hysteria2, WireGuard, and other protocols. The protocol name alone does not determine speed; real-world performance also depends on server settings, encryption, transport layer, route packet loss, CPU load, and matching parameters. Protocol comparisons are meaningful only when the network and route conditions are similar.
Before making changes, save the original parameters provided by the user’s service provider. Address, port, password, UUID, public key, SNI, Transport, TLS, and path must match as a set. Copying only the address and port while omitting other fields may allow a connection to start but cause repeated retries, handshake failures, or poor transfer performance.
- Shadowsocks: Check the encryption method, password, and port. If the client and server parameters do not match, data exchange will generally fail.
- VMess and VLESS: Check UUID, Transport, TLS, Host, Path, and SNI. An incorrect WebSocket path or Host can affect the handshake.
- Trojan: Check the password, TLS, and SNI carefully. If the certificate name does not match the target name, Log may show TLS-related errors.
- Hysteria2: Performance on a high-loss network depends on bandwidth, congestion control, and server limits. Do not enter bandwidth parameters independently of the server configuration.
- WireGuard: Check the public key, private key, Address, Endpoint, and Allowed IPs. If small requests work but larger transfers stall, compare MTU values within the range allowed by the service provider, such as 1280, 1380, and 1420 in sequence. Change only one value at a time.
MTU is not always better when smaller. If it is too large, some paths may fragment or discard packets; if it is too small, each packet carries less useful data and overhead increases. Test MTU with the same node and transfer task, reconnecting after each change. If the service provider specifies a value, keep that value first.
On Demand is mainly for establishing connections automatically based on network conditions, not for accelerating speed tests. If the connection drops or switches during troubleshooting, open Settings → On Demand and check whether existing rules are triggered by SSID, domain, or network status. Record the original settings before adjusting them, then restore them according to actual usage needs.
Layer 5: Use Log to identify which connection stage is slow
The value of Log is not a generic indication of “fast” or “slow,” but a breakdown of the stages a request passes through. Open Settings → Log, clear existing records, reproduce the problem once, and review DNS, connection, TLS, rule matches, and retry information by time. Keeping only one reproduction is usually easier to analyze than searching through a large history.
If the same domain is resolved repeatedly within a short time before a connection is established, check DNS. If TCP connects but remains at TLS handshake for a long time, focus on the system clock, SNI, TLS settings, and remote response. If the connection starts quickly but timeout or retry appears repeatedly during transfer, packet loss, congestion, or remote load is more likely.
Error: TLS handshake failed
Cause and fix: The TLS negotiation did not complete. Check SNI, Host, the TLS switch, and your own service details in the node configuration. Confirm that the device time is synchronized automatically, then reconnect and test again.
Error: DNS lookup failed
Cause and fix: Domain resolution did not return a usable result. First check whether other domains work, then review the DNS configuration in Settings and whether the current network can reach the configured resolver.
Error: connection reset by peer
Cause and fix: The remote side actively reset the established connection. Possible causes include mismatched parameters, remote policies, or a route interruption. Keep the local network unchanged, compare with another node from your own service, and ask your service provider to verify the original node’s status.
When reading Log, focus on timing relationships rather than only the final line. For example, if DNS takes 20 ms and connection establishment takes 70 ms but TLS waits for several seconds, the bottleneck is not domain resolution. Conversely, if DNS timeout appears repeatedly before connection, changing the node may not solve the problem.
Clear old records
Open Settings → Log and clear history unrelated to the current test.
Reproduce the problem once
Return to the target app or webpage and perform one operation that reliably triggers the slowdown.
Find the first request
Locate the request start by domain, destination address, or time, then confirm which rule and policy it matched.
Check the waiting stages
Compare the intervals between DNS, connection establishment, TLS, and data transfer to find the longest pause.
Run a single-variable retest
Change only the network, node, or one parameter, then reproduce the issue once more. If the corresponding error disappears, the fault range is narrowed.
Quick diagnosis for common speed problems
After completing the layered checks, use combinations of symptoms to classify the problem quickly. The goal is not to prescribe one universal parameter set, but to decide what to change next. For the user’s existing service, rely on the provider’s details for the specific node status, port, and transport settings.
Why is the download still slow when Ping is low?
Ping measures response latency, not sustained throughput. Use the same node for at least three real download tests and check Log for timeout, retry, or connection resets. If latency is stable but throughput remains low, check route capacity, remote load, and transport settings.
Why is it noticeably slower only in the evening?
Record the local baseline and the same node’s results in the morning and evening. If the local network is normal but that node declines only during a fixed period, compare another node from your own service. A drop affecting only one node is more consistent with time-specific route congestion.
Why are webpages slow while small requests in an app work normally?
Webpages often contain multiple domains, TLS connections, and larger static resources. Check how each domain matches rules in Config, then open Settings → Log to see whether DNS or TLS repeatedly waits.
If switching to Proxy makes it faster, does that prove Config is wrong?
It shows that the two modes produce different paths, but it does not identify a specific rule error. Return to Config, inspect the first matching DOMAIN-SUFFIX, GEOIP, IP-CIDR, or FINAL rule for the target domain, and confirm that its policy is expected.
Do all protocol parameters need to be adjusted?
No. Keep the original values from the service documentation first. Only change one parameter after confirming that the local network, node status, and rules are normal and that Log points to a relevant issue. Reconnect and record the result after every change.