Seeing Connected in Shadowrocket doesn’t guarantee that every part of the route has enough bandwidth. For users who already have a configuration or subscription from their own provider, this guide checks a direct-connection baseline, Global Routing, protocol settings, network paths, and server load. Keep the test target fixed and change one variable at a time to distinguish slow initial page loads, slow sustained downloads, and connection timeouts—without repeatedly changing unrelated settings.
1. Tell latency, throughput, and connection failures apart
Several factors affect speed: the connection from your iPhone to a Wi-Fi access point or cellular tower, the path from your local carrier to the remote server, the server’s capacity, and the route from that server to the destination website. A latency result in Home reflects the response time under a particular test method; it cannot be converted directly into download speed. A low latency reading also doesn’t rule out packet loss or congestion during a longer transfer.
Start by describing the symptom, then choose a test. If a page is slow to open the first time but loads normally afterward, check DNS resolution and connection setup first. If a file is slow from the start, compare bandwidth and route quality. If download speeds fluctuate, look for wireless interference, packet loss, or shared network load. If connections keep timing out, troubleshoot reachability first; speed tuning can wait until the connection works.
For example, 80 Mbps is theoretically equivalent to 10 MB/s. Actual file transfers are also affected by protocol overhead, destination-site limits, and network fluctuations. This is a unit conversion, not a speed guarantee. For useful comparisons, note the network type, selected node, routing mode, test destination, and time of day.
2. Layer 1: Establish a direct-connection baseline
First, choose the same website or file that you can access normally without a proxy. Where it’s safe and direct access is allowed, temporarily stop Shadowrocket and run the test. If the direct connection is already slow, changing proxy protocol settings is unlikely to help. Don’t compare download speeds from two different sites to decide whether the proxy is slowing you down; they may use different servers and bandwidth limits.
-
Note your current settings
In Home, note the selected node and current Global Routing value. Then check the On Demand status under Settings → On Demand. If you need to disconnect manually during testing, temporarily turn off On Demand so the system doesn’t reconnect based on existing conditions.
-
Test the direct connection
Stop the connection in Home and confirm that its status changes. In Safari, open your fixed test target and note how quickly it loads and how a sustained transfer performs. Don’t run system updates, photo syncing, or large uploads at the same time.
-
Switch network access
On your iPhone, switch the connection under Settings → Wi-Fi, then test the same target over Wi-Fi and cellular. Keep an eye on cellular data usage, and run both tests as close together as possible.
-
Restore settings and retest
Return to Home, restore the same node and routing settings, and test again on the same network. When finished, restore your original On Demand conditions so temporary diagnostic settings aren’t left in place.
If only Wi-Fi is slow, move closer to the router, compare available Wi-Fi bands, and check whether someone is using a lot of upload bandwidth. A saturated upload can also queue web requests. If only cellular is slow, compare different locations and times, and check whether your current data plan is throttled. Signal bars alone don’t tell you whether you have enough bandwidth.
3. Layer 2: Check routing mode and protocol settings
Once the local network checks out, confirm where the test traffic is actually going. In Home → Global Routing, Proxy, Direct, Config, and Scene are different routing modes. Config routes traffic according to the current configuration’s rules. Scene applies settings according to configured scene conditions; it isn’t a fixed global proxy. If the test site matches a DIRECT rule, the result won’t measure the selected proxy node.
| Setting | What it means | What to check |
|---|---|---|
| Proxy | Use proxy routing | Make sure the selected proxy or policy group doesn’t change during the test. |
| Direct | Use direct routing | Useful for comparing routes, but it doesn’t measure proxy node speed. |
| Config | Follow the current configuration’s rules | Check the matching rule and final policy for the destination connection. |
| Scene | Apply settings based on the selected scene | Check which scene applies to the current network and review its routing settings. |
In Config, the rules below illustrate where a test destination might be routed. This is a syntax example, not a complete configuration. example.com is a sample domain, and PROXY is a proxy policy. Before using similar rules, check the policies defined in your current configuration. Rules are matched in order, so an earlier match may determine the final route.
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECTNext, open the edit screen for an existing node in Home and check its type, address, port, and authentication details. The encryption method for Shadowsocks, identity and transport settings for VMess or VLESS, and password and TLS settings for Trojan must match the server configuration. A server using TCP port 443 doesn’t mean any protocol will work if you enter 443; the same port can carry different types of traffic.
- TLS and SNI: Check the server name and certificate validation settings against your configuration. Don’t mask certificate errors by allowing insecure validation. Also check Settings → General → Date & Time on your iPhone and make sure the system clock is correct.
- Transport settings: If your existing configuration uses WebSocket, the path and Host must match the server requirements. Being able to save the form doesn’t mean the server has validated the settings.
- UDP requirements: Hysteria2 uses UDP through QUIC, and WireGuard also uses UDP. If the current network restricts UDP, performance may differ from a TCP-based configuration. Don’t judge speed by protocol name alone.
- Subscription updates: Importing or updating a subscription retrieves configuration; it doesn’t increase the bandwidth of the route itself. After updating an existing subscription, check the selected entry again so changes to its address or settings aren’t mistaken for a speed fluctuation.
Error: certificate has expired
Cause and fix: This TLS error means certificate time validation failed, possibly because the certificate has expired or the device clock is incorrect. Correct the system time first, then check the certificate status with your own provider. Keep certificate validation enabled.
Error: Connection refused
Cause and fix: The destination endpoint or an intermediate device explicitly rejected the connection. This often happens when a port isn’t listening or an access policy denies the request. Check the address, port, and protocol; repeatedly running speed tests won’t fix it.
Error: Operation timed out
Cause and fix: The request didn’t complete within the time limit. Possible causes include packet loss along the route, an unreachable port, or no response from the remote end. Test the same configuration on another network, then check the remote service status with your own provider.
These are common errors in network and TLS diagnostics; the actual message may include additional context. Record the full error and when it occurred, then identify whether it happened during resolution, connection, handshake, or transfer. Don’t blame server load based only on the word “timeout.”
4. Layer 3: Use cross-tests to identify route problems
Route quality describes the path between your local network and the remote destination, including round-trip latency, jitter, packet loss, and congestion. Geographic distance can play a part, but it’s not the only factor. Two existing nodes labeled with the same region may use entirely different network paths. A node name isn’t evidence of route quality.
Cross-test your existing configurations: keep the node fixed while switching networks, then keep the network fixed while switching between existing nodes. Use the same target and test method, repeat each test three times, and record the middle result. Don’t treat a brief peak as sustained speed, and avoid frequent concurrent tests that could saturate the connection.
| Observed results | Check first | Next step |
|---|---|---|
| Same node is slow on Wi-Fi but normal on cellular | Wi-Fi access or its carrier route | Compare against the direct baseline to distinguish a wireless issue from a difference in the remote route. |
| Same node is slow on both networks, while other existing nodes work normally | The node’s route or server status | Keep the node settings unchanged and test again at a different time. |
| Only one website is slow; other destinations work normally | The destination site, DNS resolution, or route from the node to the site | Compare different resources on the same site and confirm which routing policy applies. |
| All nodes and the direct connection are slow at the same time | The local network or test target | Pause other transfers, choose a different fixed test target, and establish a new baseline. |
Takeaway: Change one variable at a time
If the same configuration is slow on only one access network, leave protocol settings unchanged and focus on that network and its route to the remote destination. Don’t change DNS, the port, and the protocol at the same time, or you won’t know which change affected the result.
Check DNS only when a page is slow to open initially but transfers normally afterward. Compare the first and second loads of the same domain, and review connection logs for resolution and connection times. A faster second load may also be due to browser caching, so that alone doesn’t prove a DNS problem. Changing resolver addresses at random can affect destination selection or rule matching; back up your current configuration before making changes.
5. Layer 4: Distinguish server load from destination limits
Server load can involve processing capacity, outbound bandwidth, concurrent connections, and server-side throttling. The client can observe response and transfer behavior, but usually can’t read the remote CPU or outbound bandwidth usage directly. So “low latency but slow downloads” shows that latency and throughput don’t match; it doesn’t prove the server is overloaded.
- Compare times of day: If the same node and destination are consistently slower on the same network during busy periods and return to normal at other times, that may indicate congestion on a shared route or changing load. Confirm the remote status before drawing a conclusion.
- Compare multiple destinations: If several unrelated destinations are slow through the same node, check its outbound route or a shared path. If only one website is slow, the site itself may be limiting speed.
- Check sustained performance: Note whether transfers stay within a steady range or pause intermittently. A stable ceiling may indicate throttling; frequent pauses may point to packet loss, retransmissions, or interrupted connections. Neither can be conclusively diagnosed from the client alone.
- Check service status: Ask your own provider whether the existing service has bandwidth, data-usage, or concurrent-connection limits. Share diagnostic notes with sensitive details removed; don’t send subscription URLs, passwords, or credentials.
Don’t increase concurrency or run downloads continuously just to get a higher speed-test result. A multi-connection test may briefly show higher total throughput, but that doesn’t mean a single web request will be faster, and it uses data. If two protocols use different servers, ports, exits, or routes, their results can’t support a blanket claim that one protocol is always faster.
Takeaway: Use evidence to locate remote bottlenecks
Prioritize checking a node’s outbound route and load with your provider only after confirming that the direct connection works, settings match, multiple destinations are slow, and the issue reproduces across access networks. Include the time of day and comparison results; this is more useful for diagnosis than repeatedly changing client settings.
6. Record results and restore your usual settings
At the end of a troubleshooting round, you should be able to answer three questions: Is the direct connection working normally? Which policy is actually handling the destination request? Does the problem follow the node or the access network? If not, preserve the simplest reproducible test case and stop layering on changes. In particular, don’t update a subscription, change rules, and adjust protocol settings all at once; that makes the original issue impossible to compare.
- Note whether your iPhone was using Wi-Fi or cellular, along with the date, time, and duration of each test. You don’t need to share your full public IP address.
- Record the Home → Global Routing value, current configuration, and a redacted name for the selected node. Note whether anything switched automatically during testing.
- Record the direct baseline, results for the same node across networks, and results for different existing nodes on the same network. Specify whether speeds are in Mbps or MB/s.
- Keep the exact error text, but redact sensitive address details, authentication fields, and subscription credentials before sharing it.
- Restore your usual Config, rules, and Settings → On Demand conditions, then confirm that common websites follow the expected routes.
For a closer look at rules and routing modes, read the technical reference or proxy mode guide. Shadowrocket is a closed-source commercial app for Apple platforms, primarily used on iPhone and iPad. Check the App Store listing for system requirements. The app is a one-time purchase and is separate from any network service plan. This guide explains how to check configurations you already have; it doesn’t provide, sell, or recommend nodes or subscriptions.