Shadowrocket First Connection: Select a Server, Connect, and Run Connectivity Test

At a Glance

This guide is for iPhone and iPad users who have installed Shadowrocket and obtained connection details from their own service provider. Follow the steps in order: select a server → check Global Routing → turn on the connection → run Connectivity Test → try the destination. Learn to distinguish server selection, VPN connection status, and destination reachability so test results are not mistaken for proof of a complete connection.

Before Connecting: Check for a Working Configuration in SERVER

Shadowrocket is a client purchase; buying the app does not include a service plan. This guide assumes you already have your own service provider and subscription. Get subscription details from your provider. Installing the app does not automatically add a server to Home or activate your provider account.

Open Home and check the SERVER list. If it is empty, import your connection details before following the selection and connection steps below. If you already have a subscription link, tap “+” in the upper-right corner of Home to open Add Server, set Type to Subscribe, enter your own subscription link, and save. Wait for the server entries to load. After updating a subscription, check the entries again, especially whether the previously selected server is still there.

Server name shown: Check the entry’s protocol and purpose. A name is only a label, not a guarantee that it works.
Entry present, but details are outdated: Update the subscription and check your account status with your provider. Toggling the VPN repeatedly will not fix expired authentication details.
Manually added entry: Check Type, Address, Port, and the authentication fields required by the protocol. A server address alone is not enough.
Just changed networks: First confirm that your current Wi-Fi or cellular network has internet access. Complete any required web-based Wi-Fi sign-in first.

First Connection: Select a Server, Then Turn On the Switch

The selection indicator in SERVER marks the current server. Tapping the dot beside a server selects the connection target; it does not start the VPN. Opening an entry’s details does not select it either. After tapping, return to Home and confirm the indicator is beside the intended entry.

Select a Server

Go to Home → SERVER, tap the dot beside the server you want, and confirm the selection indicator moves to that entry. For your first test, select one server whose details you know are valid. Don’t switch between multiple entries in quick succession.
Check Routing

Go to Home → Global Routing and check the current selection. If your existing configuration is correct, you can use Config. To rule out the effects of rules temporarily, you can use Proxy. Return to Home before continuing.
Turn On the Switch

Turn on the connection switch at the top of Home. If iOS asks to add a VPN configuration, verify the app and allow it, then complete any authentication requested by your device. If you denied permission, address the permission prompt before trying again.
Verify the Connection

Check the connection status on Home, then tap Connectivity Test. When the test finishes, use a browser to visit the destination you need. Also confirm that the selected server and Global Routing settings have not changed since the test.

If the switch stays on, the VPN session has started—but that alone does not confirm successful remote authentication, DNS resolution, or access to your destination. If the switch turns off immediately after you turn it on, check system permissions and configuration errors first instead of changing rules. To make results comparable, change just one setting at a time and note what happens before and after.

Global Routing: Don’t Mistake Direct for a Server Test

Global Routing determines how requests are routed. The server selection dot and Global Routing are separate settings: the first selects a server; the second determines whether traffic uses it. Even with a server selected, successful access under Direct does not show that the server works.

Config

Recommended

Use the policies in your active configuration. Rules may route traffic to DIRECT, PROXY, or a specific policy group, so selecting a server does not mean every request will go through it. If you use a policy group, check its selected option too.

Best for: Testing everyday connections against an existing, correctly configured set of rules.

Proxy

Routes traffic handled by the app through the proxy path. Use it temporarily to rule out the effects of standard routing rules. It does not guarantee that the remote service is available or fix incorrect authentication details.

Best for: Temporarily investigating why a destination fails under Config even though the server appears to work.

Direct

Uses a direct connection. If a page loads, that usually only shows that the direct route from your local network to that destination works. It does not prove that the selected server connected successfully.

Best for: Checking your basic network connection or comparing it with the proxy path while changing one variable at a time.

Global Routing also includes Scene, which lets you choose routing behavior by scenario. For your first manual troubleshooting session, don’t change Scene and Settings → On Demand at the same time. Complete a test using explicit manual settings first, then restore your usual automation.

If some sites work and others fail under Config, check the active configuration and the policies being matched. For example, DOMAIN-SUFFIX,example.com,PROXY and FINAL,DIRECT cover different matching scopes. FINAL is a fallback rule and usually comes after specific rules. Policy names in rules must match those defined in the configuration. Avoid replacing the entire configuration just to test.

Connectivity Test: Understanding Results and Timeouts

Connectivity Test checks an entry’s reachability. Interpret results in the context of the test method: a TCP probe mainly indicates whether a connection to the server port can be established; it does not replace protocol authentication or a real web request. HTTP-based tests are also affected by the test URL, DNS, TLS, and response conditions. Results from different test methods are not directly comparable.

Test duration—not download speed

3 checks

Check in order: selection, connection status, and actual access

1 setting

Change one setting per test and keep comparison conditions consistent

What you see	What it tells you	What to check next
An entry shows a value in milliseconds	The specified test received a response. A lower number does not mean higher throughput.	Confirm the selected entry, turn on the connection, and try the actual destination.
An entry shows Timeout	The test did not finish within the time limit. This alone does not mean the entire subscription is invalid.	Check the test method, local network, server address, and port, then rerun the test on its own.
A test returns a result, but the webpage fails	A successful port probe is not the same as a successful end-to-end proxy request.	Check authentication fields, Global Routing, DNS resolution for the destination, and the destination service status.
The connection is on, but the test fails	The local VPN session may have started, while the remote route is still unreachable.	Check the selected server details first, then compare results on another network.

Don’t group results from different times, networks, or test methods into a single ranking. To compare two servers you already have, use the same network and test method, test them close together in time, and then verify access to the page you actually need. There is no universal cutoff in milliseconds that guarantees a server will work: destination location, network congestion, and test method all affect results.

Connection Troubleshooting: Check These Three Settings First

1. Check the Selected Server in SERVER and Its Details

Return to Home and confirm the selection dot is not beside a different server. Then open the target entry for editing and check its details. The Shadowsocks password and encryption method, the UUID for VMess or VLESS, and the Trojan password are protocol-specific and cannot be used interchangeably. If TLS is enabled, also check parameters such as the Server Name provided by your service provider. Don’t disable security checks to hide incorrect details.

Check Server Details

Where to find it: Home → SERVER → Edit the target entry
Type: Must match the protocol provided by your service provider.
Address / Port: Check each field. Port 443 is a common example for TLS, not a fixed port for every server.
Authentication fields: Check the password, UUID, and related parameters for the protocol. Don’t guess based on another entry.

Use the port and authentication details provided by your service provider. If something differs, correct one item before testing again.

Check Routing and Automatic Connection

Routing: Home → Global Routing
Config: Check the active configuration and matched policy on the Config page.
Automatic connection: Settings → On Demand
How to troubleshoot: Note the original settings, temporarily disable automatic triggers, and test a manual connection.

Restore the original settings when you finish to avoid leaving temporary troubleshooting changes in place.

2. Check That Global Routing Matches the Active Configuration

If the actual destination works under Proxy but fails under Config, check the rules and policy groups in the configuration before deleting a server. The file enabled on the Config page affects rule results; importing a server list from a subscription does not mean you have selected a rule configuration that meets your needs. Note the destination domain and what happens when access fails, then check which rule should match it. Avoid changing the configuration, server, and network all at once.

3. Check VPN Permissions and On Demand Before Manual Testing

If you canceled system authorization when adding the VPN configuration for the first time, the connection may not start as expected. Turn the connection switch on again and follow the system prompts. If no prompt appears, check the Shadowrocket entry in your device’s VPN settings. Also check Settings → On Demand: automatic triggers may restart the connection after a network change, making it hard to tell what happened after you disconnected manually.

Note the existing On Demand settings, temporarily turn off automatic triggers, then disconnect manually from Home.
Confirm that your basic network works, select the target server again, and turn on the connection switch.
Keep the network unchanged, run Connectivity Test, and try accessing the actual destination once.
Record the results, then restore your original automatic connection settings. Start a separate test if you need to change networks.

How to Confirm Your First Connection Is Working

A complete check covers three things: the intended server is selected on Home, the connection status stays on, and the actual destination that should use the proxy completes its request. If you use Config, also confirm that the destination matches the intended proxy policy. A page that loads through DIRECT does not prove that the proxy server was used.

Keep a brief record: Note the network type, server label, Global Routing selection, test method, and error. Don’t share passwords or subscription links.
Stop toggling repeatedly: If the same error keeps recurring, check server details, routing, and permissions. This is more likely to reveal the cause than rapidly switching the connection on and off.
Follow up with the right party: Contact your own service provider about expired accounts, server address changes, or remote authentication issues. For app navigation and settings, continue with the tutorials on this site.

After this manual test, re-enable your everyday rules, Scene, or On Demand one at a time. Check the destination after each change to identify what altered the route. You can then repeat the same troubleshooting steps when switching between Wi-Fi and cellular networks.