How to Fix Slow Shadowrocket Speeds: Check Servers, Routes, Protocols, and Your Network

1. Establish a baseline: latency isn’t download speed

In Home, select the server you want to use and confirm the selection indicator. Turn on the connection, then run Connectivity Test. A successful test means the specific test request completed; it doesn’t mean every website, protocol, or large file transfer will work normally. Low latency in a single test doesn’t guarantee sufficient bandwidth either. Once connected, performance can still be affected by server load, congestion on the route out, or limits imposed by the destination.

Describe the slowdown in terms you can reproduce: does a page stay blank after you tap it, do text and images load at different speeds, or does the download rate keep dropping? The figures below explain unit conversions and how to record results; they are not performance guarantees for any route.

1. Pause cloud sync, system updates, and other high-bandwidth tasks on your devices. Record when you test and how you’re connected.
2. Use the same page or a test file you’re authorized to access. Run each test three times in a row, recording the first and subsequent loads separately to avoid mixing in cached results.
3. Record Connectivity Test results, time to first page load, sustained transfer rate, and any interruptions separately. Don’t combine them into a single judgment of whether the connection is “fast” or “slow.”
4. Change one condition at a time. When switching servers, keep Wi-Fi the same; when changing protocols, don’t change DNS at the same time.

For example, 5 MB/s is about 40 Mbps—not 5 Mbps. The app’s instantaneous traffic display may not reflect the average speed of the file you’re downloading. Compare it with the download tool’s average and the test duration.

2. Server layer: check the selected server, configuration, and service status

Here, “server” means a server entry in an existing service configuration, not the configuration file itself. Multiple entries in Home only show that they’re listed; the actual connection depends on the selected entry and whether the active configuration uses a policy to choose a different outbound route. After switching entries, reconnect and, where possible, start a new test request so an existing long-lived connection doesn’t keep using the old route.

• Check the entry first: Make sure the server address, port, protocol, and authentication details match the information from your service provider. Use the port specified in your configuration; don’t change everything to 443 just because HTTPS commonly uses that port.
• Then check for updates: If you already use a subscription, update it and confirm which entry is selected afterward. An unchanged entry name doesn’t guarantee that the server address and parameters are unchanged. Updating a subscription also doesn’t necessarily update the rules in your current Config.
• Finally, compare: If you have another working server, compare them on the same network, at the same time, and against the same target. If only one server consistently performs poorly, first check its status and any service limits.

These are examples of errors that may appear in network logs; the exact display can vary. Before sharing logs, hide server addresses, authentication details, and subscription credentials. This guide covers troubleshooting configurations you already have; this site doesn’t provide, sell, or recommend servers or subscriptions.

3. Route layer: narrow down the cause by comparing routing modes and timing

A request may pass through your local network, the proxy server’s inbound connection, its outbound connection, and the destination service. A fast connection to the server doesn’t mean the route from that server to the destination is fast. If only one website is slow, first consider the destination’s load, content delivery location, and any restrictions on the outbound IP address rather than changing every server.

In Home → Global Routing, check the current mode. For a speed comparison, first confirm which route traffic takes. Use a temporary mode change only to test, then restore your usual configuration.

Keep your local network unchanged and repeat the same test at different times. If several servers you already have slow down at similar times, congestion on a shared route may be involved. If only one destination remains slow, focus on its route. These are clues for narrowing down the issue, not conclusions you can confirm from a single test.

4. Protocol layer: check transport settings instead of judging by protocol name

Shadowsocks, VMess, VLESS, Trojan, Hysteria2, and WireGuard all require settings that match the server. Protocol names don’t indicate speed. Comparisons across different inbound connections, servers, or outbound routes can’t prove that one protocol is faster. You can only test a protocol if your service provider has supplied a configuration for it.

• Shadowsocks: Check the encryption method, password, and any other parameters required by the service. If authentication doesn’t match, resolve the connection issue first; this isn’t a speed-tuning problem.
• VMess / VLESS: Check the authentication ID, transport type, and any Host, path, TLS, or other parameters required by the service. Don’t copy a path from one server entry to another.
• Trojan: Check the password and TLS settings. The server name must match the service configuration. Don’t try to fix slowness by disabling certificate verification.
• Hysteria2: It relies on QUIC and UDP transport. If your local network restricts UDP, you may see connection failures or significant fluctuations. Test on another network to compare.
• WireGuard: Check the keys, endpoint, and allowed routes provided by the service. It typically uses UDP, so other TCP requests working doesn’t mean its route is working too.

If small requests succeed but large downloads keep stalling, possible causes include packet loss, retransmissions, server rate limits, or path MTU. First reproduce the issue with the same target on another network, then adjust relevant settings according to the server’s documentation. Without evidence, repeatedly lowering MTU, increasing concurrency, or entering an unrealistically high bandwidth value can make the problem harder to diagnose.

5. Local network layer: check Wi-Fi, cellular, and automatic connections

If multiple working servers and destinations slow down on the same Wi-Fi but recover on cellular, start by checking the network environment. Wireless interference, router load, or a saturated home upload can all increase latency. Cellular performance also varies with signal strength and cell tower load. After switching networks, test repeatedly from the same location rather than relying on a single peak reading.

1. Retest near the access point: If possible, compare 5 GHz and 2.4 GHz Wi-Fi while keeping the server and destination unchanged. If a stronger signal reduces fluctuations, address your Wi-Fi coverage first.
2. Pause background uploads: Pause photo backups, file sync, and uploads from other devices, then compare initial page load and download performance. Upload congestion can also slow download acknowledgments and interactive requests.
3. Complete network sign-in: If public Wi-Fi requires web-based sign-in, complete it first. A timeout before network access is granted says nothing about server performance.
4. Check for configuration conflicts: See whether another VPN configuration or network filter is enabled on the system. Keep only the connection conditions needed for the current test.
5. Check automatic reconnection: Go to Settings → On Demand and review the trigger conditions. To test a direct-connection baseline with the connection off, you can temporarily disable the relevant automatic connection conditions. Restore your original settings when you’re done.

A device that’s overheating, running low on battery, or busy with background tasks can also affect measurements. Keep device conditions similar and record whether “Wi-Fi slow, cellular normal” or “slow on every network.” This is more useful for troubleshooting than a single screenshot of instantaneous traffic.

6. Slow first loads and slow individual websites: check DNS and rules

A long wait on the first page load followed by faster visits may involve DNS lookups or connection setup, or may simply be due to caching. DNS affects name resolution and address selection; it doesn’t directly increase the bandwidth of an established large-file transfer. First confirm the active configuration in Config, then check its DNS and rules to avoid editing a file that isn’t in use.

Rules are generally evaluated in order, so specific rules should come before catch-all rules. The examples below explain syntax; they aren’t a complete replacement for your existing configuration. PROXY must point to a working proxy policy. Keep a copy of your original configuration and test local changes individually.

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

• DOMAIN-SUFFIX matches a domain suffix. example.com is only a syntax example and isn’t a service recommendation.
• IP-CIDR matches an IP range; no-resolve means the rule doesn’t trigger a DNS lookup. It doesn’t disable DNS globally.
• GEOIP matches the destination IP against a geographic database. Check the resolved address and database result rather than relying on the domain suffix.
• FINAL handles requests that didn’t match earlier rules. It can’t mask an incorrect policy destination in a preceding rule.

Test system DNS, custom DNS, and DNS over HTTPS separately; don’t change the resolver and server at the same time. DNS over HTTPS also depends on the resolver being reachable, and encryption doesn’t necessarily reduce initial page load time. If changing DNS improves only the first load while downloads remain slow, return to the route and server layers instead of repeatedly clearing DNS settings.

7. Common questions and troubleshooting notes

After troubleshooting, restore any temporary changes to Global Routing and On Demand. If you send notes to your service provider or support staff, include enough detail to reproduce the problem, but leave out authentication passwords, full subscription URLs, and keys.