Keep the test target, Global Routing, and local network fixed, then change the server, network connection, and protocol one at a time. This guide is for users with their own service and subscription who can connect but are experiencing slow access. Compare each variable to distinguish server load, route congestion, protocol connection issues, and Wi-Fi problems, and keep notes you can verify later.
1. Identify where the slowdown occurs
When Shadowrocket shows that a connection is on, that confirms its connection status—not that the entire path to a website is working properly. Loading a webpage typically involves DNS resolution, establishing a connection, the TLS handshake, and content transfer. A delay at any stage can make the page appear slow to load. Record what happens before changing settings so you don't mistake a delay in name resolution for a lack of bandwidth.
| What you notice | Check first | How to compare |
|---|---|---|
| The first page load takes a long time, but transfers are normal afterward | DNS, connection setup, TLS | Reload the same page, then compare it with another target; account for caching |
| Pages load, but large files transfer slowly | Server load, link bandwidth, target-side throttling | Keep the server fixed and test a different permitted resource |
| Only one website is slow | Target service, rule match, specific exit route | Check the policy for that request and try other targets |
| Slow on Wi-Fi, normal on cellular | Wireless signal, router, access link | Keep the server fixed and switch only the network connection |
Latency is not download speed. A latency test measures the time taken by a specific probe; it does not measure sustained throughput for real-world traffic. A single failed test also doesn't prove that a server is unavailable. Check video startup, webpage rendering, and file transfers separately rather than relying on one measurement to describe the whole experience.
2. Establish a baseline: check Global Routing first
In Home, check the current server and Global Routing. Proxy, Direct, Config, and Scene are different routing modes, not speed settings. To check whether rules are affecting a request, temporarily compare Proxy with Config while keeping the server fixed. If the target works in Proxy but remains slow in Config, check the rules and the policy the request follows first. This doesn't mean you should leave Proxy enabled.
-
Record the original settings
In Home, note the selected server and Global Routing. In Config, confirm the selected configuration. Keep a record of the original values and restore them after testing.
-
Choose a fixed test target
In Safari, choose a webpage you can revisit and a file resource you're permitted to test. Use the same targets in each round and pause other high-traffic tasks.
-
Compare routing modes
Go to Home → Global Routing and temporarily select Proxy without changing the server. Then switch back to Config and test again. Note whether the request followed the expected policy.
-
Check On Demand
Go to Settings → On Demand and review the connection conditions. If you need a baseline test while disconnected, temporarily disable relevant conditions to prevent an automatic reconnection during the test.
-
Restore and verify
After comparing results, restore the original Global Routing and On Demand settings. Visit the same target again to confirm that the same issue recurs, rather than a different connection state.
Direct is useful for checking targets that are accessible over your current network, but a target that normally can't be reached directly is not evidence of a local network problem. What happens in Scene also depends on its configuration, so the mode name alone doesn't tell you where traffic goes. For rule-related issues, check the order in Config and which rule actually matches the request. DOMAIN-SUFFIX, IP-CIDR, GEOIP, and FINAL serve different purposes; changing DNS won't automatically correct a routing policy that selects the wrong path.
3. Server layer: change only the server on the same network
Here, “server” means a specific server entry provided by your service provider. Keep Wi-Fi, the test target, and routing mode unchanged, and switch between two entries you already have. Where possible, choose entries with the same protocol and related settings. Otherwise, the results reflect protocol differences too, so you can't attribute them to server load alone.
- Only one entry stays slow: Note its address, port, and when the slowdown occurs, then ask your service provider about load, maintenance, or throttling.
- All entries are slow: Continue by checking the shared route, local network, and target service. Don't immediately change settings across every entry.
- The same entry is fast at times and slow at others: Retest at different times under similar conditions. Slowdowns in the evening may point to congestion, but they don't show which part of the route is congested.
- Switching entries restores speed: Switch back to the original entry and test once more to rule out caching, a temporary recovery, or a background task finishing.
Your service provider may change subscription entries. If you think an address or port has changed, update your own subscription in Home and check whether the server details have synced. Get the subscription link from your service provider. Updating a subscription fixes configuration sync issues; it doesn't increase server bandwidth, and a successful update doesn't prove that the route is working properly.
Takeaway: keep a working comparison point
Once you find a server that reliably completes the same task, keep its settings unchanged for now. Use it to compare other entries one at a time; don't update the configuration, change protocols, and switch DNS all at once.
4. Route layer: compare Wi-Fi and cellular
The route includes the path from your device to the server and from the server to the target service. Switching your local network changes only part of that path. If access works on cellular, the issue may involve the local connection or its route, but that alone doesn't prove the router is faulty. If your iPad doesn't support cellular, compare another Wi-Fi network or personal hotspot you control.
| Test combination | Keep fixed | What to record |
|---|---|---|
| Original Wi-Fi + original server | Target resource, routing mode | Time to first screen, whether transfer works, interruptions |
| Cellular + original server | Server settings, target resource | Whether switching networks resolves the issue |
| Original Wi-Fi + comparison server | Original Wi-Fi, target resource | Whether switching servers restores access |
| Cellular + comparison server | Comparison server, target resource | Whether both network connections are stable |
These are test scenarios, not measured results. Repeat each combination three times and record the time and number of failures. Large file tests use data, so check your plan before testing on cellular. If both servers are slow only on the original Wi-Fi, focus on the wireless environment, router, and access link. If one server is slow on both networks, continue checking that server and its route to the target.
If only one website is slow while other targets work normally, consider the target's CDN assignment, restrictions on the exit IP address, or throttling by the app or service itself. Don't assume that a geographically closer server will be faster: actual routing, peering quality, and load all affect performance.
5. Protocol layer: verify settings, then check transport conditions
A protocol name doesn't guarantee speed. Shadowsocks, VMess, VLESS, Trojan, Hysteria2, and WireGuard use different connection mechanisms, but performance still depends on the server setup and network conditions. Compare only configurations your service provider has supplied with complete settings. Don't change an entry's Type to test another protocol; the server won't automatically support it.
- Address and port: Use the values provided by your service provider.
443is commonly used for HTTPS, but it isn't a universal port for proxy services. Don't change every port to443just because a connection is slow. - TLS and SNI: For configurations such as Trojan, check that the certificate name and SNI are correct. A certificate verification failure is a connection issue; enabling Allow Insecure is not a way to improve speed.
- Transport settings: If your service provider uses a transport such as WebSocket, settings like the path and Host must match the server. Being able to resolve the server address doesn't mean these settings are correct.
- UDP conditions: Hysteria2 is based on QUIC, and WireGuard uses UDP. Restrictions on UDP in some networks can cause connection failures or instability. Compare with other working configurations provided by your service provider.
If the logs show errors, address them before testing throughput. The examples below are common snippets in network diagnostics; prefixes and full messages vary, so they won't appear in every slow-speed scenario.
Error: connection refused
Cause: The connection was actively refused, often because nothing is listening on the target port or an intermediary device rejected it. Fix: Verify the server address and port, and ask your service provider to confirm the service status. Don't rotate ports at random.
Error: no such host
Cause: Domain name resolution returned no usable result. First determine whether the name belongs to the server or the target. Fix: Check the spelling and subscription update status, then check whether DNS is reachable on your current network.
Error: context deadline exceeded
Cause: An operation exceeded its time limit. This message alone doesn't identify where packets were lost. Fix: Check nearby log entries to identify the stage that failed, then keep the server fixed and retest on another network connection.
Takeaway: compare protocols only after verifying settings
A speed comparison is meaningful only when both configurations can establish a stable connection and reach the same target. Record handshake failures separately from slow sustained transfers and troubleshoot them as different issues.
6. Local network layer: check Wi-Fi, DNS, and background traffic
If cross-testing points to a local issue, start with reversible steps. Retest near the router and pause high-traffic transfers on other devices; these steps preserve more evidence than resetting all network settings. A strong wireless signal doesn't rule out interference or queues at the broadband connection. Heavy uploads from other devices on the same Wi-Fi can also slow webpage loading.
- Check the connection: Keep the server fixed and retest near the router. If the router offers different bands, test each one under controlled conditions and note which network you're connected to.
- Pause competing traffic: Temporarily pause photo syncing, system updates, and large file transfers on other devices. Visit the same target, then resume those tasks when you're done.
- Check the direct-connection baseline: After confirming that On Demand won't reconnect automatically, disconnect and visit a webpage normally accessible on your current network. If it's still slow, investigate the local connection first.
- Separate DNS delays from throughput: Focus on DNS settings when the first connection is noticeably slow. Don't replace a domain with a website's IP address to test HTTPS: the certificate, SNI, and virtual hosting may all depend on the domain name.
- Allow connections to stabilize: After switching between Wi-Fi and cellular, wait for the current connection to stabilize before testing again. An interrupted old connection doesn't mean the server is unavailable over the new network.
MTU shouldn't be the first setting you change. If small requests work but larger transfers repeatedly stall, you can investigate MTU later; packet loss or target-side throttling can cause similar symptoms. Change it only if the configuration provides a relevant option and your service provider has given you a specific value. Keep the original value and don't apply supposed universal settings found online.
7. Record your findings and confirm recovery
The goal isn't a faster result in a single speed test; it's completing the same task reliably in your usual setup. Restore your original Config and On Demand settings, then check the webpages and apps you normally use. If the slowdown returns when you restore Config, revisit the rule match and policy selection instead of continuing to switch servers.
- Environment: Note whether you're using an iPhone or iPad, the type of network connection, when the issue occurs, and whether it affects only one target.
- Configuration: Record Global Routing, the protocol in use, the server port, and the selected configuration. Don't share passwords, keys, or subscription authentication details.
- Comparison: Notes such as “the original server is slow on both networks” or “the same server is slow only on the original Wi-Fi” are more useful for troubleshooting than “the speed is bad.”
- Evidence: Keep the actual error snippets and number of test runs. Before sharing logs, check for and redact authentication parameters, full subscription links, and personal browsing history.
- Restore: Undo temporary changes and retest the original target. Report issues you can still reproduce to your service provider instead of piling on unverified settings.
To investigate rules and DNS further, see the Global Routing and rule-based routing tutorial and the DNS troubleshooting guide. These checks address different parts of the connection; use them one at a time based on the evidence rather than changing everything in a single test.