This guide is for cases where Shadowrocket is already configured with your own server or subscription and connects, but browsing or transfers are slow. Check your local network, routing, individual servers, protocol settings, DNS, and automatic connection conditions in order. Change one variable at a time and retest the same destination to distinguish latency, throughput, and connection failures. Keep notes that others can use to reproduce the issue.
1. Define “slow”: slow to connect or slow to transfer?
An enabled switch only indicates that the system tunnel is on; it does not prove that the entire path between the server and the website is working properly. A long wait before a page opens, low download speeds after a transfer starts, and video playback that stutters are different symptoms. Before testing, note when the issue occurs, whether you’re on Wi-Fi or cellular, which server is selected in Home, and the current Global Routing option.
A connectivity test usually covers only part of the path. A low latency reading does not guarantee faster sustained transfers, and a slow response from one website does not mean all servers are unavailable. Do not treat latency as a direct measure of download speed.
| Symptom | Check first | What to record |
|---|---|---|
| Long wait on first visit; loads normally afterward | DNS, connection setup, TLS handshake | Compare the first visit with subsequent visits |
| Consistently low transfer speed | Local bandwidth, server load, egress route | Retest the same resource repeatedly on the same network |
| Frequent disconnects or timeouts | Packet loss, server port, UDP reachability | Compare results before and after switching networks |
| Only one website is slow | Rules for that domain and the destination’s status | Test a second, unrelated domain for comparison |
2. Local network: compare Wi-Fi and cellular
Your local network is the common starting point for every test that follows. Public Wi-Fi that still requires a sign-in, a congested router, or an unstable wireless signal can all make Shadowrocket seem slow after connecting. The steps below use an iPhone as an example. Comparing with cellular on an iPad requires a device with cellular capability.
- Turn off the connection switch in Home, then use Safari to visit a page that normally opens directly on your current network. If that is slow too, troubleshoot the local network first instead of changing server settings right away.
- Complete any Wi-Fi sign-in, pause bandwidth-intensive activity on your devices, and test again closer to the router. Don’t change DNS or Global Routing at the same time.
- Return to Home, select the same server, turn the connection back on, and retest the same destination.
- Turn off Wi-Fi and confirm that the device has switched to cellular. Test with the same server and Global Routing option. Keep an eye on cellular data usage.
- Record whether each network establishes a connection, whether only the first visit is slow, and whether sustained transfers are interrupted.
Takeaway: Start with the network where the issue is reproducible
If the same server consistently has issues on only one Wi-Fi network, check that network’s sign-in requirements, congestion, and traffic restrictions first. Don’t use a protocol change to mask a local network problem.
3. Global Routing: confirm the traffic takes the expected path
In Home, open Global Routing and note whether it is set to Proxy, Direct, Config, or Scene. Save the original setting before troubleshooting and restore it afterward. Switching modes is not a speed boost: the mode determines how traffic is routed; it cannot increase available bandwidth.
| Option | What it means for troubleshooting | What to check |
|---|---|---|
| Proxy | Compare using a global proxy route | Check the current server in Home, then visit the same destination |
| Direct | Compare using a direct connection | Test only a destination normally reachable directly on your current network |
| Config | Route traffic according to the active configuration’s rules and policies | Open Config and confirm which file is active |
| Scene | Apply settings according to the configured scene conditions | Check the scene for the current network; don’t treat it as a fixed proxy route |
If Proxy works normally but Config is slow, check which rule matches the destination domain and which server the rule’s policy actually selects. In Config, review the active configuration and check DOMAIN-SUFFIX, IP-CIDR, GEOIP, and FINAL in order. FINAL is the fallback when no earlier rule matches; it does not override a rule that already matched.
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYThe rules below illustrate syntax; they are not a complete configuration to replace yours with. example.com is a sample domain. For troubleshooting, use the destination that is actually causing the issue. If you use a policy group, also check its current selection. A rule ending in PROXY does not by itself confirm that traffic is using the server selected in Home.
4. Individual servers and routes: compare servers in your existing configuration
Here, “server” or “node” means a connection entry for a service you already have. Congestion at the server entrance, along the route between ingress and egress, or between egress and the destination can all reduce speed. The latency shown by the client cannot identify which segment is congested on its own.
- In Home, run Connectivity Test for the current server and record the test method, result, and time. A reading does not verify performance under sustained, high-volume transfers.
- Keep the local network and Global Routing setting unchanged. Switch to another server you already have and visit the same destination.
- If only one server has issues, open its edit screen and compare the address, port, protocol, and authentication settings with your original configuration details.
- If several servers are slow only for the same website, test another destination to distinguish a route between egress and that website from a general transfer problem.
- Repeat the same set of tests at different times. Issues that occur only in the evening may point to load or congestion, but you’ll need server-side status or route data to confirm.
A subscription URL may contain access credentials. When reporting an issue to your own service provider, share the server alias, time, network type, and test results. Don’t include the full subscription URL, password, or private key in public reports. This manual covers checks for services you already have.
5. Protocol settings: check connection requirements before judging performance
Shadowsocks, VMess, VLESS, Trojan, Hysteria2, and WireGuard have different connection requirements. Changing only the protocol name does not make a valid comparison. Testing another protocol requires an existing server configuration for it; matching port numbers do not mean protocols are interchangeable. For example, port 443 is only a port number and does not identify the protocol or transport in use.
| Protocol | Settings that must match the server | Commonly misread symptoms |
|---|---|---|
| Shadowsocks | Address, port, encryption method, and password | Authentication mismatch causes connection failure, not low bandwidth |
| VMess / VLESS | User ID, transport type, and the corresponding TLS, Host, and Path settings | An incorrect transport path can cause a timeout during connection setup |
| Trojan | Password, TLS, and the Server Name required by the server | A failed TLS handshake may leave a page waiting indefinitely |
| Hysteria2 | Authentication, TLS, UDP reachability, and the relevant bandwidth settings | QUIC-based connections depend on UDP availability on the current network |
| WireGuard | Keys, Endpoint, tunnel addresses, and routing-related settings | A configured entry does not mean the UDP handshake has completed |
In Home, open the server’s edit screen and check each setting against your original configuration. Don’t disable certificate verification as a test; correct the actual issue, such as the server name, certificate, or device time. Don’t set MTU or bandwidth values arbitrarily high, either: MTU affects packet size, and bandwidth settings should follow the instructions for your service. Neither is a universal speed boost.
Error: connection refused
Cause and fix: The destination port or an intermediary device actively refused the connection. First, check the address and port in the server editor in Home, then ask your service provider to confirm that the port is listening. Repeatedly changing routing rules won’t fix a port refusal.
Error: i/o timeout
Cause and fix: A read or write did not complete before its deadline. This message alone cannot tell you whether the cause was congestion or an unreachable destination. Note whether it happened during testing, the handshake, or data transfer, then switch local networks and retest with the same server.
These are examples of errors that may appear during connection attempts. The exact message depends on where the failure occurs and on the underlying implementation; not all connection failures display the same text. When reporting an issue, keep the exact message instead of describing every problem as “slow.”
6. DNS and On Demand: troubleshoot slow first visits and issues after switching networks
DNS affects domain resolution, while connection reuse and DNS or destination caching can change what happens on subsequent visits. A slow first visit followed by a faster refresh can point to a resolution or connection setup issue, but it is only a clue. Replacing an HTTPS URL with an IP address is not a reliable test: the certificate, Server Name, and site routing may change as a result.
- In Settings, check the DNS-related options and the DNS configuration in the active Config file. First, note the existing resolver addresses and any overrides.
- Check whether the current network can reach the configured DNS resolver, and whether results differ between proxy and direct routes. Don’t replace multiple resolver addresses and routing rules at once.
- Change only one setting you’ve confirmed is causing a problem. Reconnect, visit the same domain, and record the difference between the first and subsequent visits.
- If the issue occurs only after switching between Wi-Fi and cellular, go to Settings → On Demand and note the current automatic connection conditions.
- Temporarily turn off On Demand, disconnect and reconnect manually in Home, then check the result on the current network. Restore the original automatic connection settings when you’re done.
Takeaway: Test automatic connections separately from transfer performance
If a manual reconnect fixes the issue but it returns after switching networks, check the On Demand conditions and the settings for the relevant Scene first. Don’t assume the cause is protocol throughput.
7. Common questions and what to include in a troubleshooting report
Why is the server with lower latency slower for downloads?
Latency tests and sustained transfers measure different things. Keep Global Routing and the target resource fixed, switch between two servers you already have in Home, and repeat the tests. Record transfer stability instead of ranking servers by a single latency reading.
If it only gets slow at night, did I choose the wrong protocol?
First, retest with the original protocol and server against the same destination at two different times, then switch local networks. If the same time pattern recurs, share your notes with your service provider so they can check load and routing. The timing alone does not prove a protocol issue.
If switching to Proxy fixes it, should I leave it there?
Switch back to Config and check the active Config file for the rule matching the destination domain and the selected policy group. Correct any incorrect match or unavailable policy, then test again. Proxy is a comparison condition, not necessarily a permanent fix.
It got slower after a subscription update. Should I add it again?
First, check whether the selected server in Home has changed, then open its entry and verify the address, port, and protocol. If your service provider has updated the settings, use the current configuration. Don’t repeatedly overwrite the existing entry just to reproduce an earlier speed test.
After troubleshooting, your notes should let someone else reproduce the conditions, rather than just saying “it’s really slow.” Use the checklist below to record what you actually observed. You don’t need to disclose authentication details.
- Time and network: Include the local time, whether you were on Wi-Fi or cellular, and what happened after switching networks.
- Connection details: Server alias, protocol, port, Global Routing option, and active Config filename.
- Destination and symptoms: Domain, whether the issue affects the first connection or sustained transfers, and whether it affects only one site.
- Comparison results: Another network, another server you already have, and whether temporarily switching to Proxy changed anything.
- Error details: Include the exact error message. Before sharing, remove subscription tokens, user IDs, passwords, and keys.
Shadowrocket is a paid Apple platform app, primarily used on iPhone and iPad, and is available exclusively from the App Store. The developer is Shadow Launch Technology Limited, and the app ID is 932747118. The one-time app purchase and the cost of any service you already have are separate. Check the App Store listing for system requirements and compatible devices.