This guide is for iPhone and iPad users who have already imported their own configuration into Shadowrocket. Follow the steps in order: check the server list, select a default server, authorize and connect, then test and verify access. These are separate states: a server can be selected, the system VPN can be connected, and a destination can be reachable. If a test times out, check the network, server settings, and routing configuration one at a time.
Before you connect: confirm you have a configuration
This guide assumes you already have your own provider and subscription. Shadowrocket is a closed-source commercial app; purchasing the app does not include a network service plan. After buying the app, you still need to import server configuration you are authorized to use. The app purchase itself does not provide connection credentials. This guide does not provide, sell, or recommend servers, subscriptions, or related services.
Shadowrocket is available only on Apple platforms, exclusively through the App Store. Verify the developer, Shadow Launch Technology Limited, and app ID 932747118 on the product page. Check the App Store listing for the price, system requirements, and purchase availability. If you haven't installed the app yet, read how to get the app and verify its authenticity.
Open Home and confirm that the list contains actual server entries, not just a subscription name. If you have added a subscription but the list is empty, update it and check the import results first. For servers added manually, compare the Type, address, port, and authentication fields with your original details. A server name alone isn't enough to confirm that it was imported correctly.
- Home: Select a server, check Global Routing, control the connection, and run Connectivity Test.
- Config: Manage routing configurations. Server entries and routing configurations are different things; importing one does not mean the other is ready.
- Settings: Review app settings. During your first connection check, leave existing settings unchanged and avoid changing multiple options, such as DNS and On Demand, at once.
First connection: select, authorize, connect
A successful import means the app has saved connection details. It does not mean a server is selected or that the system VPN is connected. For your first connection, complete these five steps in order. Check the corresponding status at each step before continuing.
-
Check the list
Open Home, expand your existing server group, and confirm that individual entries are visible. If there are none, return to the import or update step. Don't keep toggling the connection switch.
-
Choose a default
Tap the server entry you want to use and confirm that a dot appears beside it. Open the entry's edit screen only if you need to change its settings. Editing an entry and selecting it as the default server are separate actions.
-
Check the routing mode
Go to Home → Global Routing and check the current selection. If you have a usable routing configuration, choose Config and confirm that the intended configuration is selected. To troubleshoot basic server connectivity, you can temporarily use Proxy.
-
Authorize and connect
Turn on the connection switch at the top of Home. When prompted for the first time to add a VPN configuration, allow it and complete device authentication as instructed. Return to the app and check the switch and connection status.
-
Run a test
Once connected, tap Connectivity Test on Home and wait for the result. Then use a browser to visit the destination you need. Don't stop after checking the latency shown in the server list.
Global Routing: check the traffic route first
The same server can produce different results under different Global Routing modes. When connecting for the first time, don't assume that turning on the switch means all requests go through the selected server. Note the current mode first, then consider what the test result can tell you.
Config
RecommendedUse the selected configuration to route traffic according to its rules. Requests may match DIRECT, a proxy policy, or another configured policy. Requests that don't match earlier rules are handled by later rules such as FINAL; they are not necessarily sent directly.
Best for: everyday use after confirming that a valid routing configuration is selected.
Proxy
Route traffic handled by the app through the proxy mode to narrow down the effects of routing rules. This does not replace server authentication or guarantee that every type of system traffic is handled.
Best for: temporarily checking basic proxy connectivity to the selected server.
Direct
Handle traffic in direct mode. If a website opens, this only confirms that the direct route on your current network works; it does not show that the selected proxy server works.
Best for: checking direct network access as a comparison, not testing the proxy route.
Global Routing also offers Scene, which uses predefined scenarios. You don't need to create a scene just to test your first connection. If your existing configuration uses Scene, check its conditions and related settings first. For details on the available options, see feature and settings guide.
- If access works after temporarily switching from Config to Proxy, check the rules and policy selection in the current configuration first. Don't immediately re-enter the server password.
- If both Proxy and Config fail, continue checking the underlying network, server settings, and service status. This alone does not prove that the rules are at fault.
- After troubleshooting, restore the mode you normally need and test the actual destination again. Don't leave a temporary troubleshooting setting in place for everyday use.
Connectivity Test: understanding the results
Connectivity Test runs a connectivity check. Before running it, confirm that Home shows an established connection. Then check whether a result appears or the test times out or fails. The wording depends on the current interface; don't use one fixed latency threshold as a pass mark for every network.
Latency tests in the server list and Connectivity Test after connecting serve different purposes. Latency results depend on the test method. A response to one kind of probe does not guarantee successful protocol authentication, DNS resolution, TLS connection, or access to a destination website. Likewise, a failed probe alone does not prove that all application traffic will fail.
Check the test result and actual access separately
In-app test
- After connecting, run the check from Home → Connectivity Test.
- Note the default server, Global Routing mode, and network type at the time of the test.
- A result confirms connectivity for that test path; it does not mean every website is reachable.
Test access to the destination
- Use a browser to open the full address you need to visit again.
- Confirm that the page actually reloads, rather than displaying previously cached content.
- If only one destination fails, check its domain, matching rules, and service status.
Check the test result and destination access separately. Your use case is verified only when both are confirmed.
For example, Connectivity Test may return a result in Proxy mode while an HTTPS website still won't open. Narrow the issue down to that destination's resolution, connection, or access restrictions rather than assuming the VPN failed to connect. HTTPS destinations commonly use port 443, but the server connection port must match your own original configuration. Don't change the server port to 443 just because you're accessing HTTPS.
Troubleshooting: change one condition at a time
When something fails, note what happened before changing one condition and testing again. Switching servers, changing DNS, and rebuilding configurations in quick succession makes results difficult to compare. The checks below follow the connection sequence; start with the earliest potential failure.
| What you see | Check first | Next step |
|---|---|---|
| No server entries on Home | Was the configuration imported? Did the subscription update succeed? | Check your original source details again. Connect only after individual entries appear in the list. |
| Entry appears, but has no dot | Did you only open the edit screen? | Return to Home, select the server, and check for the selection indicator beside it. |
| The switch won't stay on | Has authorization for the system VPN configuration been completed? | Follow the system prompts to authorize the configuration. On a managed device, also check for device restrictions. |
| Connected, but the test times out | Underlying network, server address and port, and authentication details | First check that direct network access works, then compare each setting with the original details. |
| Test returns a result, but some websites fail | Global Routing, routing policies, destination resolution, and service status | Compare Proxy and Config temporarily, and note whether only specific destinations are affected. |
Check the network and server settings separately
- Underlying network: Turn off the connection first and confirm that your current Wi-Fi or cellular network can access the internet directly. If the Wi-Fi network requires sign-in, complete its own authentication first.
- Switch networks: If system permissions allow and you're aware of cellular data charges, test on a different network. If it fails on only one network, the issue is related to differences between the two network paths; that alone doesn't identify a single cause.
- Protocol fields: Type must match your server details. Shadowsocks, VMess, VLESS, Trojan, and other protocols use different authentication fields. You can't switch Type while keeping only the address and port.
- Transport settings: If your original details include TLS, Server Name, a transport method, or a path, keep each setting consistent. Disabling certificate verification is not a routine fix.
- Subscription changes: If an update replaces or removes an existing entry, recheck the current selection indicator and available entries. A successful update means the data was retrieved and parsed; it does not mean every server in it has been connection-tested.
After verification: keep a reproducible setup
You can finish the first connection check once the default server is selected, the connection is established, Connectivity Test returns a result, and the actual destination is accessible. If you later change servers or routing configurations, repeat the test and destination access checks. You don't need to recreate the system VPN configuration each time.
- Restore your usual mode: If you temporarily used Proxy for troubleshooting, switch back to Config or your usual mode and verify access to the destination again.
- Set up automatic connection if needed: To connect automatically, go to Settings → On Demand and configure the relevant conditions. On Demand isn't required for a successful first manual connection. Don't enable multiple sets of conditions before confirming basic connectivity.
- Understand manual disconnects: If On Demand is enabled, the system may reconnect when its conditions are met. If you need to stay disconnected, check the relevant conditions as well as the Home switch instead of repeatedly turning the switch off.
- Keep a record of what worked: Note the verified server name, routing mode, and test network. If a problem occurs later, compare the current setup with these details before changing one setting at a time.
The key to a successful first connection isn't a single status icon; it's a complete chain of evidence: the correct entry is selected on Home, system authorization is complete, the connection is on, the test returns a result, and the actual destination is accessible. For more on configurations and settings, see the settings guide. To repeat the steps in order, use the tutorial links at the end of this article.