When Shadowrocket shows Connected, it means the system VPN tunnel is established—not that every server, destination, and transport protocol is working properly. This guide assumes you already have a provider and subscription. Keep test conditions consistent, then compare servers, routes, protocols, and local networks one layer at a time. Use initial page load, sustained transfers, errors, and network-switch results to narrow down the specific point of failure.
1. Check the request path before diagnosing a slow connection
Takeaway: Verify that requests follow the expected policy. Don’t judge server speed by the connection toggle or VPN indicator alone. In Home, check the selected server, then review Global Routing. Proxy handles traffic in proxy mode, Direct handles it as a direct connection, and Config applies the rules in the active configuration. Keep results from different modes separate.
With Config, first check which configuration is active in Config. One website may match DIRECT while another goes through the proxy. If Global Routing is set to Scene, review that scene’s settings before testing. Keep conditions consistent; don’t change the scene and server at the same time. If you briefly switch to Proxy for comparison, note the original mode and restore it when you’re done.
- Choose one website to test, and distinguish a long wait for the first page load from slow transfers after they begin.
- Run Connectivity Test in Home and record the test method, result, and selected server. Treat the value as a reference for that test destination only.
- Retry the request and, if connection logs are available, check the destination domain and the policy actually applied. Don’t count a DIRECT request as a server speed test.
- If the connection drops intermittently, check the connection conditions under Settings → On Demand. Make sure network changes aren’t triggering repeated reconnects during testing.
2. Keep a comparison log and change one variable at a time
Takeaway: Change only one condition per test so the results are meaningful. Don’t update the subscription, switch servers, change protocols, and switch Wi-Fi all at once. Pause heavy transfers on other devices, use the same iPhone or iPad, destination, and test method, and note the time. Cached webpages can load much faster on a second visit, so record cache hits separately from newly fetched content.
Use the table below as a logging template; it does not show test results from this site. A and B refer to two servers in your existing subscription. When choosing B, keep other conditions such as protocol and region as similar as possible. If there’s no suitable comparison, note what differs rather than attributing the result to a single factor.
| Test round | Conditions held constant | Condition changed | What to record |
|---|---|---|---|
| Baseline | Server A, original configuration, same destination | No change | Initial page-load time, sustained transfer, and any errors |
| Server comparison | Original network and routing mode | Switch from A to B | Whether improvement is consistent and whether pauses persist |
| Network comparison | Server A, original protocol, same destination | Switch from Wi-Fi to cellular | Whether the same request completes; record reconnect time separately |
| Time-of-day comparison | Server A, original network and configuration | Test time | Whether results differ consistently between peak and off-peak hours |
Takeaway: Look for repeatable differences
If only one request gets faster, repeat the same test first. Follow up on a variable only when other conditions are held constant and the difference persists. This helps avoid mistaking a cached response or brief fluctuation for a fix.
3. Server layer: low latency doesn’t mean fast sustained transfers
Takeaway: Server tests can help assess reachability and response time, but they don’t directly measure bandwidth. A short request transfers little data; a quick response doesn’t mean large files or video segments will transfer quickly. Server load, egress capacity, and the route to the destination can all limit throughput even when latency looks normal.
- Only one server is slow: In Home, switch to a similar server in your existing subscription and repeat the same test. If A is consistently the only one with problems, check its status and connection settings first.
- Only one destination is slow: Keep the server unchanged and test another destination you use regularly. If other destinations work normally, check the destination’s rules, DNS resolution, and the route from the server to that site.
- All servers are slow: Keep the current configuration and compare local networks next. Don’t immediately assume every server in your subscription is faulty.
- Subscription information may be out of date: Use the in-app subscription update option to get the latest information from your provider. Confirm the update succeeded, then select the server again. Don’t permanently overwrite incorrect entries by editing subscription-managed items.
Region names are labels supplied by your provider; they don’t reveal the actual relay route or available bandwidth. When contacting your provider, include the server name, test time, network type, and affected destination. This is more useful than simply saying, “Latency is low, but everything is sluggish.”
4. Route layer: use time-of-day and destination comparisons to spot path issues
Takeaway: A single latency figure usually can’t tell you whether congestion is on the access link, relay route, server egress, or destination site. Look for patterns: does the same server slow down only at certain times? Are several servers unstable on the same network? Does the issue disappear when you change destinations?
- Keep the server fixed and compare times. Repeat the same requests at different times. If performance consistently drops in the evening and recovers at other times, that suggests a time-related congestion pattern, but doesn’t identify where it occurs.
- Keep the destination fixed and compare routes. Compare servers you already have. If only some are slow to the same destination, note their shared characteristics and ask your provider to investigate.
- Separate waiting from transferring. A long wait for the first response followed by normal transfers points to DNS resolution or connection setup. If a transfer starts but repeatedly stalls, investigate possible congestion, packet loss, or destination-side throttling.
- Test webpages and media separately. Adaptive video quality and buffering affect playback, so one smooth viewing session doesn’t prove that the route has enough capacity.
Don’t replace test logs with repeated disconnects and reconnects. A reconnect may create a new session or happen to avoid a brief congestion spike. Without keeping the server, destination, and network fixed, you can’t tell what caused the improvement. Your provider must confirm server route and egress details; observations in the app can only help narrow down the possibilities.
5. Protocol layer: check settings before changing protocols
Takeaway: The protocol must match the server. Changing it to a different type won’t make the connection faster. Shadowsocks, VMess, VLESS, Trojan, Hysteria2, and WireGuard use different authentication, transport, and server configurations. You can compare protocols only when your provider has supplied the corresponding connection details. Note whether the server and route are the same.
| Protocol or transport | Check first | What this can tell you |
|---|---|---|
| Shadowsocks | Address, port, password, and encryption method | The encryption method must match the server configuration. |
| VMess / VLESS | UUID, transport type, TLS, Host, and Path | Whether Host and Path are required depends on the transport. They aren’t interchangeable. |
| Trojan | Password, port, TLS, and server name | If the certificate name doesn’t match, check the configuration. Don’t disable verification to try to improve speed. |
| Hysteria2 | Authentication, TLS, UDP reachability, and bandwidth-related settings | Uses QUIC and depends on UDP. If the network restricts UDP, the connection may not establish properly. |
| WireGuard | Key, Endpoint, address, and MTU | Uses UDP. Validate MTU against the route; there’s no single best value for every network. |
Check each port against the original configuration. For example, HTTPS commonly uses TCP 443, but entering 443 doesn’t mean every protocol can use that port—or that the connection uses TCP. Don’t confuse Hysteria2’s UDP connection with TCP 443 reachability. For bandwidth-related fields, don’t enter values far above the route’s actual capacity in an attempt to increase speed.
If small requests complete but large responses often stall, MTU or path MTU issues may be worth investigating, but that isn’t a diagnosis. First rule out destination-specific and local network issues, then run controlled tests using the settings supplied by your provider. Record the original value before changing anything, change one parameter at a time, and restore it if the test fails. Don’t apply generic “optimized” values in bulk.
6. Local network layer: compare Wi-Fi with cellular
Takeaway: If the same server and configuration are slow on just one local network, check that network’s wireless quality, upload usage, and transport restrictions first. Wi-Fi signal bars don’t indicate usable capacity, and interference can occur even near the router. Cellular performance also depends on location, signal quality, plan status, and tower load.
- Keep the server and destination fixed. Run one test over your current Wi-Fi, pausing heavy uploads or backups on your device and other devices.
- Switch to cellular, wait for Shadowrocket to reconnect, then make the same request. Record reconnect time separately from page response time, and keep data usage in mind.
- If cellular works normally but Wi-Fi remains slow, move closer to the router and test again. If possible, compare different Wi-Fi bands on the same router.
- If the Wi-Fi network requires a web login, complete it first. A VPN indicator doesn’t prove internet access is available while the login page is still pending.
- Check the On Demand conditions under Settings so automatic connection behavior doesn’t affect tests after a network switch. Record the original settings before changing them, then restore them afterward.
Check DNS separately. Standard DNS queries commonly use UDP or TCP port 53, while encrypted DNS uses different transports. If the first visit takes a long time but transfers are normal once connected, check the DNS settings in the active configuration, whether resolution succeeds, and whether retries occur. One faster result after changing DNS doesn’t prove that DNS caused every speed issue.
7. When errors appear, use the original message to identify the failed stage
Takeaway: An error tells you that a particular stage failed; it doesn’t necessarily reveal the cause. The examples below are common snippets that may appear in network diagnostics or connection logs. Refer to your device’s full records for the exact message. Save the time, destination, and server involved, but don’t share subscription URLs, passwords, UUIDs, or keys.
Error: connection refused
Possible cause and next step: The connection was explicitly refused, possibly because nothing is listening on the port or it was actively rejected. Check the server address and port, then ask your provider to confirm that the endpoint is listening.
Error: i/o timeout
Possible cause and next step: A network read or write didn’t complete within the time limit. This message alone can’t tell you whether the issue is local or remote. Keep the server fixed, compare Wi-Fi with cellular, and use the full log to identify which stage timed out.
Error: TLS handshake failed
Possible cause and next step: The TLS handshake didn’t complete. Possible factors include the server name, certificate, device time, or an interrupted connection. Check the original TLS settings and system time, then compare another network. Don’t routinely disable certificate verification.
If there’s no error but the connection remains slow, keep records of both successful and failed tests. A stall after the connection is established is different from an authentication or TLS handshake failure. Don’t decide to change protocols based on the last log line alone; review the surrounding requests and conditions that reproduce the issue.
8. Common questions and when to stop troubleshooting
Latency is low, so why does video keep buffering?
Keep the server fixed and compare sustained transfers to the same destination. Then check playback quality and buffering. A brief latency test doesn’t measure sustained throughput or capture the entire path from the server to the video host.
It’s faster in Proxy. Should I leave it there?
First switch back to Config and check the rule and policy matched by the destination. DOMAIN-SUFFIX, GEOIP, IP-CIDR, and FINAL affect where requests go. A speed difference between modes is a reason to check the rules, not sufficient grounds to switch permanently.
Only Wi-Fi is slow. Should I import the subscription again?
Keep the server fixed and repeat the test on both Wi-Fi and cellular. If the same configuration works reliably on cellular, investigate Wi-Fi access and the router before deleting the subscription. Updating a subscription won’t fix wireless interference.
Will switching to Hysteria2 definitely make it faster?
No guarantee. First confirm that your provider has supplied Hysteria2 settings and that the current network allows the required UDP traffic. Keep the destination and test time consistent, note any differences in the server route, and don’t infer performance from the protocol name alone.
Before you stop troubleshooting, write down at least one reproducible finding—for example: “With the same server and configuration at the same location, requests repeatedly stall on Wi-Fi, while all three requests complete on cellular.” This points to the local network or access route as a priority for further checks, but still needs verification. It’s more useful than simply saying, “It connects, but it’s slow.”
- Restore test changes: Restore the original Global Routing mode, On Demand conditions, and any temporary protocol settings. Confirm that your everyday configuration is still correct.
- Share the relevant details: Include the test time, network type, server entry name, destination, and error snippet. Redact authentication details and subscription tokens.
- Follow up with the right party: Check the router and access conditions for local network issues, ask your provider about server endpoints or routes, and review rules in Config.