This guide is for users who have imported their own provider configuration into Shadowrocket and can connect, but experience slow webpage responses or file transfers. Keep the test target and time consistent, then check node status, network route, protocol parameters, and local connectivity in order. Use Global Routing, Connectivity Test, and repeated results to identify the cause.
Define “slow” first, then standardize the test
“Connected” only means that the system tunnel has been established. It does not mean the entire path from the device to the destination site is operating normally. A request typically passes through local Wi‑Fi or cellular service, the system VPN tunnel, Shadowrocket rule matching, the user’s own server, and the destination site. Queuing, packet loss, or DNS delays at any point can leave a page spinning.
Start by separating three patterns. The first is slow startup: the page stays blank for a long time, then loads normally, often pointing to DNS, connection setup, or time to first byte. The second is consistently slow transfer: a large file remains slow from start to finish, so check route throughput, server load, and the local network. The third is instability: speed fluctuates, video quality changes frequently, and packet loss, wireless interference, or peak-hour load are likely factors.
Use a fixed test site
Choose the same reliably reachable webpage and a test file with a known size. Do not compare different sites directly, because their bandwidth and caching policies vary.
Keep the configuration fixed
In Home, keep the same node, Global Routing mode, and network connection method. Run three consecutive tests and record the time to first response and sustained transfer speed.
Stop background tasks
Pause photo syncing, app updates, cloud backups, and other high-bandwidth tasks. Otherwise, bandwidth contention will make the results difficult to compare.
Change one variable at a time
Adjust only one factor per round—for example, change only the node or switch only from Wi‑Fi to cellular. Changing several parameters at once makes the result impossible to attribute.
Layer 1: Check node load and server response
At the node layer, determine whether the server you use can accept connections and process data promptly. Low latency does not guarantee high throughput: the millisecond value shown by Connectivity Test mainly reflects the round-trip time for one connection or request, while sustained download speed also depends on server egress bandwidth, concurrent load, and destination-site limits.
Run Connectivity Test on the current node from the Home node list. Record whether it succeeds or times out and whether latency fluctuates sharply. Depending on the interface layout, the test may be in the node action menu; follow what the app currently shows. If three results are 85 ms, 92 ms, and 410 ms, the third clearly deviates from the first two, indicating instability on the route or server. If every test completes quickly but large files remain slow, continue by checking route throughput.
Confirm the current node
Return to Home and check the server entry actually selected. Do not mistake a subscription group name for the current outbound node.
Run a connectivity test
Run Connectivity Test three times on the same node, waiting about five seconds between tests. Record success or failure and the range of latency variation.
Cross-check another node in the same group
In your own provider configuration, select another known-working node. Change only the node and repeat the same test. If the new node works normally, the problem is more likely with the original node or its upstream route.
Check the subscription status
Pull down in Home to update the existing subscription, and confirm that the server address and port still match the values currently provided by your provider. A sample subscription URL should use a format such as https://example.com/sub?token=xxxx; confirm the actual details with your own provider.
Error: The request timed out
Cause and fix: No response arrived within the allowed time. The node may be congested, the route may be dropping packets, or the server may be unreachable. Repeat the test without changing other conditions, then cross-check with another available node in your own configuration.
Error: Connection reset by peer
Cause and fix: The remote endpoint or an intermediate network reset the connection. First verify the server address, port, password, UUID, and transport parameters. If the configuration is correct but the error continues, ask the relevant provider to check the server status.
Error: Failed to load subscription
Cause and fix: The subscription URL may have expired, timed out, or become subject to different access conditions. Confirm that it came from your own provider and pull down in Home to refresh it. If it still fails, ask the provider to verify the URL.
Do not judge speed solely by the region shown in a node name. The name is only a configuration label and does not directly represent the actual route, load, or egress quality. Useful evidence includes repeated test success, latency variation, time to first response, and sustained transfer speed for a fixed file.
Layer 2: Check route latency, packet loss, and peak-hour congestion
The route is the network path between the device and the server. Even when the server itself is operating normally, the access network, carrier route, and time of day can produce significant differences. Typical route issues include consistently high latency, sudden latency spikes, intermittent timeouts, and small webpages that work while long-lived transfers steadily slow down.
The key to route testing is comparing times and access methods. Keep the Shadowrocket node and protocol unchanged, complete one test round on Wi‑Fi, then switch to cellular and complete another. If only one access method is clearly slow, check that local network and its path to the server first instead of changing protocol parameters.
- Low latency and stable speed: The node and route are broadly healthy at the moment. If only certain sites are slow, check the destination site or the matched rule.
- High but stable latency: The path may be long or indirect. Interactive responses will feel slow, although sustained transfers may still work reasonably well.
- Latency swings by several hundred milliseconds: Video buffering and resources arriving in batches are common signs. Check packet loss, wireless signal quality, and peak-hour congestion.
- Occasional test timeouts: The connection is being interrupted. Do not look only at the lowest latency from a successful test.
- Normal during the day but slow at a regular time: This points more strongly to time-based load or congestion. Repeat the test for several days at the same times.
| Observed result | Most likely cause | Next step |
|---|---|---|
| Wi‑Fi is slow; cellular is normal | Router, wireless interference, or broadband route | Move closer to the router, switch bands, restart the network equipment, and test again |
| Both networks are slow only on one node | Node load or the node’s upstream route | Cross-check with another node in your own configuration |
| All nodes are slow on only one site | Destination site, DNS, or matched rule | Check whether the request is using DIRECT or the proxy policy as expected |
| Speed drops broadly in the evening | Peak-hour congestion | Run three tests in the morning and evening under the same conditions, then compare the middle results |
Layer 3: Verify protocol and transport overhead
Shadowrocket supports configuration types including Shadowsocks, VMess, VLESS, Trojan, Hysteria2, and WireGuard. Their handshakes, encryption, transport layers, and packet-loss recovery mechanisms differ, but no protocol can be declared faster without considering the server-side configuration. Client parameters must match the server side field by field.
Protocol issues are often mistaken for a slow route. If the transport method, TLS, SNI, Path, password, or UUID is inconsistent, the result may be repeated handshakes, connection resets, or a complete failure to connect. When UDP is restricted, configurations that depend on UDP may become unstable. Repeatedly switching Global Routing will not fix incorrect parameters.
| Configuration type | What to check | Typical symptoms |
|---|---|---|
| Shadowsocks | Server address, port, password, and encryption method | Any mismatch will usually cause the connection to fail or drop immediately |
| VMess / VLESS | UUID, TLS, SNI, Transport, and Path | When the handshake times out or resets, verify the complete parameter combination first |
| Trojan | Password, TLS, SNI, and certificate-related settings | An issue during the TLS phase may prevent the connection from being established |
| Hysteria2 | UDP reachability, authentication details, and server parameters | A restricted network may cause instability or prevent the connection from completing |
| WireGuard | Key, Endpoint, Allowed IPs, and MTU | Check MTU when some sites stall while small requests work normally |
Save the original configuration
Before making changes, record the current server address, port, and protocol parameters. Do not batch-adjust TLS, MTU, Transport, or UDP options based on guesswork.
Verify the server-side details
Compare the node details in Home with the current configuration from your own provider, field by field. Pay particular attention to capitalization, a leading slash in Path, SNI, and the port.
Change only one parameter
Correct one clearly inconsistent field at a time, save, reconnect, and repeat the same test. This keeps the change traceable.
Restore the original value
If the change does not help or introduces a new error, immediately restore the recorded original configuration before checking another layer.
Adjust MTU only when there is clear evidence of fragmentation or a specific site stalling. A value that is too large may prevent some packets from passing; one that is too small increases header overhead and processing. Do not copy an MTU value that works on one network environment into every configuration.
Layer 4: Rule out local Wi‑Fi, cellular issues, and background traffic
The local network is the layer most often overlooked. Distance from the router, same-channel interference, prolonged router load, or a saturated broadband uplink can all raise latency in Shadowrocket. If local sites are also slow with the connection off, compare behavior with and without the connection enabled first.
A full Wi‑Fi signal icon only means the device is receiving a strong wireless signal; it does not show whether the internet uplink is congested. 2.4 GHz usually covers a larger area but is more susceptible to same-channel interference. 5 GHz generally offers more available bandwidth at short range but attenuates more through walls. The exact band names and switching method depend on the router.
Stop background transfers
Pause cloud photo syncing, system backups, app updates, and local-network file transfers. Wait about 30 seconds, then test again.
Move closer to the router
Test the same node from a nearby location without obstructions. If latency becomes much more stable, address wireless coverage or interference first.
Switch the access network
Keep the node, protocol, and Global Routing unchanged. Switch from Wi‑Fi to cellular and repeat the same webpage and file tests.
Rebuild the network connection
Turn off the Shadowrocket connection switch, reconnect the current network, and turn the connection back on. If the issue remains, restart the device and router using their normal procedures, then test again.
Check On Demand
Go to Settings → On Demand and confirm that its rules are not repeatedly connecting and disconnecting during Wi‑Fi and cellular transitions. During troubleshooting, record the original settings, temporarily disable them, and connect manually for the test.
Error: Network is unreachable
Cause and fix: The device currently has no usable network path, or routing has not recovered after a network switch. Confirm that Wi‑Fi or cellular service works on its own, then turn the Shadowrocket connection off and on again.
Error: The Internet connection appears to be offline
Cause and fix: The system cannot detect a usable internet connection. With Shadowrocket off, verify the local network first. Once access is restored, establish the system VPN tunnel again.
Check Global Routing, rule matches, and DNS wait time
Slow performance can also result from traffic taking the wrong path. Shadowrocket’s common Global Routing modes are Proxy, Direct, Config, and Scene. Proxy sends traffic through the proxy policy, Direct connects directly, Config matches rules from top to bottom, and Scene follows the configured scene. Confirm that the current mode matches the expected behavior.
If Global Routing is set to Direct, the current node will not carry the relevant proxy traffic. If it is set to Proxy, local resources that should use DIRECT may take an indirect route. When using Config for everyday routing, rule order is especially important: after Shadowrocket matches the first applicable rule, it generally does not continue downward, so a broad rule near the top can hide a later, more specific rule.
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYThis example only illustrates match order: example.com uses PROXY under DOMAIN-SUFFIX; local addresses connect directly under IP-CIDR; other traffic matching GEOIP uses DIRECT; requests matching none of the earlier rules fall through to FINAL. The actual policy names must match those defined in your Config.
DNS waiting often appears as a slow first visit to a domain followed by a faster refresh. Compare a domain request with a request to a known-working IP resource, but do not enter an unknown DNS address casually. Also check whether Config contains GEOIP or IP-CIDR rules that require resolution, and whether `no-resolve` is used where resolution should not be triggered.
- In Home, confirm whether Global Routing is currently Proxy, Direct, Config, or Scene, and record the state before testing.
- When using Config, scan from the top of the rules to find the first DOMAIN-SUFFIX, DOMAIN-KEYWORD, GEOIP, IP-CIDR, or FINAL rule that may match the target domain.
- If only the first request is slow, focus on DNS resolution and time to first byte. If the connection is established but remains slow, return to the route and server-throughput layers.
- After troubleshooting, restore the original Global Routing mode. Do not treat a temporary Proxy test mode as a long-term conclusion.
Symptom: Connected but no traffic
Cause and fix: The system tunnel is established, but rule matching, DNS, or server egress is not producing a usable response. First check whether Global Routing was mistakenly set to Direct, then use Config to verify the first matching result for the target domain rule by rule.
Retest in a fixed order and record the result
After adjusting one layer, return to the original fixed test target instead of switching sites and relying on subjective impressions. Record the date, time, access network, node label, protocol, Global Routing mode, three latency results, first-response behavior, and sustained speed. Consistent fields make it possible to distinguish occasional fluctuation from a stable difference.
Why is the download still slow when latency is very low?
Latency measures the time for one round trip; it does not represent server egress capacity or sustained throughput across the full path. Test one file of known size three times, while also checking node load and route performance during peak hours.
Can I conclude immediately that the node is better if it becomes faster right away?
Repeat the test three times on the same network, with the same Global Routing mode and test target. Only when the original node remains slow and the new node remains normal can you narrow the cause to the original node or its upstream route.
What should I do if Wi‑Fi is slow but cellular is normal?
Keep the Shadowrocket configuration unchanged, move closer to the router, and pause background syncing before testing again. If performance returns at close range, check wireless coverage; if it remains slow, check router load and the broadband route.
Can a failed subscription update affect existing nodes?
Existing entries may remain temporarily, but they will not receive later configuration changes from the provider. Pull down in Home to update first. If Failed to load subscription appears, ask your own provider to confirm the URL and access conditions.
Should I use Proxy for long-term testing?
Proxy is useful during troubleshooting to verify a uniform proxy path, but it bypasses Config routing results. Restore the original mode after testing and check the actual match order of DOMAIN-SUFFIX, GEOIP, IP-CIDR, and FINAL.
- Run a baseline on the current network and node, and record three consecutive results.
- Change only the node to determine whether server load or the node’s upstream route is abnormal.
- Switch only between Wi‑Fi and cellular to compare local access and route behavior.
- Verify the protocol parameters; do not change the port, TLS, Transport, or MTU based on guesswork.
- Check Global Routing, Config rule order, and the first DNS response.
- Restore the original settings, run three more tests with the same target, and use the middle result as the conclusion.
Shadowrocket is a paid commercial app for Apple platforms. iPhone and iPad are the primary devices, while the App Store compatibility section may also list Mac, Apple TV, and Apple Vision; system requirements should be checked on the App Store page. The App Store is the only acquisition channel. The product page should list Shadow Launch Technology Limited as the developer, with app ID 932747118 and a one-time purchase. Buying the client and obtaining your own network service are separate matters.