Seeing Connected in Shadowrocket does not mean every request has reached its destination successfully. This guide is for users with their own provider and subscription who can connect but experience slow-loading webpages or video. Start by keeping test conditions consistent, then check local access, protocol settings, the route between networks, and node load in turn. Use Ping and Log to capture evidence you can review afterward.
1. Standardize test conditions and distinguish latency from throughput
“Slow” can mean several things: a long pause before a response, slow loading after a page starts, or speeds that fluctuate. The first may involve DNS resolution or a handshake; the second calls for checking available bandwidth and congestion; the third requires looking at network changes, packet loss, and server load. The VPN indicator in the status bar cannot tell these cases apart.
Before testing, note the selected node on Home and the current Global Routing setting. Don’t update the subscription, switch protocols, and change DNS all at once; even if speed improves, you won’t know what made the difference. The test counts below are troubleshooting suggestions, not app defaults.
- Choose one webpage you can already access and a specific video clip. Check the initial response and ongoing playback, using the same targets throughout troubleshooting.
- Pause photo syncing, system updates, and other high-bandwidth tasks. Keep the device in the same place and on the same network.
- Repeat each test condition three times. Record the network type, node label, time, and what failed—not just the fastest result.
- Change one condition at a time. After each comparison, restore the original routing and configuration before starting the next test.
2. Local network: compare Wi-Fi and cellular first
Start by checking the connection between your iPhone or iPad and the local network gateway. A strong Wi-Fi signal only indicates good wireless reception; it doesn’t rule out congestion at the router’s internet connection. If the same node works over cellular but is slow on a particular Wi-Fi network, that points to a difference in the access network or its route to the node—not necessarily a server problem.
- On the current Wi-Fi network, first open a familiar webpage that normally works without a proxy and check for unusual delays. If you temporarily disconnect Shadowrocket to compare, visit only content that is suitable for direct access.
- Go to Settings → On Demand and note the current conditions. Defaults depend on what the app currently shows. If On Demand interferes with manually disconnecting for comparison, temporarily turn it off for this test and restore the original setting afterward.
- Keep the same node and configuration, turn off Wi-Fi, and repeat the test over the cellular network available to your device. Be mindful of data usage.
- If the issue occurs only on Wi-Fi, retest closer to the router and check whether the network is handling heavy traffic. Don’t start by changing every protocol setting.
Port numbers are clues when checking a connection path, not speed settings. Changing a provider-specified proxy port to 443 at random, or assuming all DNS traffic uses port 53, can create new connection problems.
3. Protocol settings: check the original configuration instead of guessing which is faster
Next, check whether the settings in the client match the server’s requirements. Shadowsocks, VMess, VLESS, Trojan, Hysteria2, and WireGuard in Shadowrocket use different protocols and configuration fields; they are not speed modes you can switch between by changing a name. If you already have a subscription, compare its settings with the valid parameters provided by your service provider.
| Protocol or field | What to check | What not to assume |
|---|---|---|
| Shadowsocks | Check that the server address, port, password, and encryption method match. | A reachable port does not guarantee successful authentication or forwarding. |
| VMess / VLESS | Identity parameters, transport method, and any TLS or transport-related fields enabled in the configuration. | Don’t keep only the address and port while omitting other required parameters. |
| Trojan | Password, TLS requirements, and whether the server name matches the server configuration. | Disabling certificate verification is not a routine way to improve speed. |
| Hysteria2 | Authentication details, TLS requirements, and whether UDP is available on the current route. | Using QUIC does not guarantee better performance on every access network. |
| WireGuard | Check that the keys, endpoint, addresses, and routing scope match the existing configuration. | A visible handshake does not confirm that DNS and routing to the destination are correct. |
There are no universal recommended values for these fields across all servers. Use the defaults currently shown in the app, and follow the settings provided for your existing server. If the issue began after a subscription update, note any changes to the address, port, or transport fields and check with your provider. Don’t delete the original entry and repeatedly import it—you could lose the conditions needed for comparison.
Bottom line: verify that the settings match before comparing protocols
If one configuration repeatedly fails during the handshake, check authentication, TLS, or transport settings first. Comparing speeds only makes sense once both configurations can reliably complete the same request.
4. Route quality: interpret Ping separately from actual requests
Next, look at the paths from your local network to the node and from the node to the destination. Interpret in-app Ping results in light of how the test works: an ICMP response, a TCP connection, and a webpage request completed through a proxy do not measure the same thing. A node that doesn’t respond to ICMP is not necessarily an unavailable proxy service.
Low latency means a particular probe had a short round-trip time; it doesn’t mean there is enough bandwidth for sustained transfers. If the probe looks fine but video keeps buffering, compare actual transfer performance and test at different times. Don’t use a single timeout to estimate packet loss across the entire route.
- Ping is fast, but webpages take a long time to respond: Check Log for DNS delays, connection retries, or TLS errors, and verify which route the request actually used.
- Fast initial response, but slow ongoing loading: Retest with the same target and check local bandwidth usage, route congestion, and any server-side speed limits.
- The same node is slow on just one access network: Save the Wi-Fi and cellular comparison results first to identify differences along the access route.
- Only one website is slow: Compare it with another working destination. The destination, its content delivery route, and the node’s exit can all affect performance.
Don’t assume a shorter distance means a faster route. Geographic distance, peering between networks, congestion, and the content delivery location chosen by the destination are separate factors. Compare requests under the same conditions.
5. Node load: confirm requests actually use the selected node
Only then compare the performance of your existing nodes. Go to Home → Global Routing and note the current setting. Config (rule-based routing), Proxy, Direct, and Scene have different meanings; use the value currently shown in the app as the default. Follow your existing configuration for everyday use. If you temporarily switch to Proxy for comparison, restore the original setting when testing is done.
Under Config, selecting a node does not mean every request will use it. DOMAIN-SUFFIX matches domain suffixes, IP-CIDR matches address ranges, GEOIP matches geographic IP locations, and FINAL is the fallback rule. The actual result also depends on rule order and policy. For Scene, check the existing scene definition; it is not a fixed proxy policy.
- Send a new request to the same destination and check Log for its policy, outbound, or related connection records. Field names depend on what the app currently shows.
- If the request used Direct, investigate the routing first. Don’t attribute that speed result to the selected proxy node.
- If you already have multiple working nodes, change only the node while keeping the destination, access network, and routing mode the same.
- Repeat the same test at different times. Slower performance only during peak hours may indicate congestion or load, but client-side results alone cannot confirm server CPU usage, the number of active users, or any speed limit.
6. Log errors: troubleshoot by stage, not by guessing from keywords
Open Log in the app (the entry point and available records depend on what the app currently shows), reproduce one slow or failed request, and inspect only the entries around that time. The English phrases below are common network log errors. Prefixes, capitalization, and surrounding context can vary; these are not fixed messages that appear with every issue.
Error: i/o timeout
Cause: A network operation did not complete within the allotted time. This line alone can’t tell you whether the delay occurred during DNS resolution, connection setup, or later reading and writing.
What to do: Check the destination and operation stage in nearby entries. Keep the same node, switch access networks, and retest before deciding whether to check with your provider.
Error: connection refused
Cause: The connection was explicitly rejected. The destination port may not be listening, or a network device may be actively rejecting the connection.
What to do: Check that the server address and port still match your existing settings, then ask your provider to confirm the service status on that port.
Error: certificate has expired or is not yet valid
Cause: Certificate validity verification failed, possibly because of the certificate status or an incorrect device clock.
What to do: Check the device’s date and time first. If they’re correct, check the server certificate; don’t hide the issue by disabling verification.
- If a log error points to the subscription update URL, it only indicates a problem with the update operation. It does not prove that forwarding speed for an already imported node is affected.
- Before sharing logs, hide subscription credentials, passwords, keys, and unnecessary browsing records. Keep the timestamps, error stage, and test conditions.
- Don’t use repeated reconnects as a substitute for collecting evidence. Retrying can change the connection state without explaining where the original delay occurred.
7. Common questions and restoring settings
Why does video keep buffering when Ping is only a few dozen milliseconds?
Ping does not measure throughput. Choose a specific video clip and compare sustained playback on Wi-Fi and cellular using the same node. Then check Log to confirm the request actually used the selected outbound.
It works after switching to Proxy, but it’s slow again in Config. What should I check?
Reproduce the issue with the same destination under Config, check which rule and policy matched, then go to Config and review the relevant rule order. Focus on how DOMAIN-SUFFIX, IP-CIDR, GEOIP, and FINAL handle the request. Don’t leave the entire configuration set to global proxy as a permanent fix.
Will changing protocols always make the connection faster?
No. A comparison is valid only if your server supports the protocol, all required settings are present, and the route allows the required transport. First confirm that connections and requests are stable, then compare using the same destination and access network.
Which settings should I restore after troubleshooting?
Restore the Global Routing setting, Settings → On Demand conditions, and any temporary configuration changes you noted before testing. Reopen the original destination to verify. Keep any effective individual fix, but don’t treat a temporary test setup as your everyday default.
After a round of checks, you should be able to state which network, node, routing mode, and destination were involved, and at what stage the delay occurred. If those conditions aren’t clear yet, changing DNS, ports, or protocols will only add variables. Record a proper comparison first, then address the part you’ve identified.