This guide is for users who already have a service provider and subscription and are getting ready to connect to Shadowrocket for the first time. Follow the sequence: check the server list and select a server, authorize and connect, then test and try browsing. It explains the roles of the default server, Global Routing, and VPN status. If you see a timeout or a page won’t load, troubleshoot in the same order instead of changing the protocol, DNS, and rules all at once.
1. Before connecting: what the client, servers, and Config do
Shadowrocket is a paid client for Apple platforms, primarily used on iPhone and iPad, and is available exclusively from the App Store. The developer is Shadow Launch Technology Limited, and the app ID is 932747118. Check the App Store listing for current pricing, purchase terms, and system requirements. Buying the app does not include a service plan. This guide assumes you already have your own service provider and subscription; this site does not provide, sell, or recommend servers or subscriptions.
Before connecting for the first time, make sure Home shows an available server entry. A server entry contains its address, port, protocol, and authentication details; Config contains settings such as traffic-routing rules. Seeing a server list after importing a subscription does not mean you have a Config suited to your needs or that a VPN connection is active. First check that the import succeeded, then use the connection switch.
If the Home list is empty, tap + in the upper-right corner of Home to open the add screen. Set Type to Subscribe, enter a subscription link you already have, save it, then update the subscription. A link might look like https://example.com/sub?token=xxxx; this is only a format example and won’t work for an actual connection. After a successful update, you should see server names. If you see only a subscription group name and no server entries, troubleshoot the import first.
2. Select a default server in Home and allow the VPN configuration
Selecting a server and turning on the connection are separate actions. A listed server, even one with a latency reading beside it, isn’t necessarily selected. Tap the row for your chosen server in Home and check that the dot on the left moves to it, then turn on the switch at the top. Opening the server’s edit screen only shows its settings; it doesn’t select it.
-
Check the list
Open Home and confirm that your subscription has server entries. If you’ve just imported or updated it, wait for the list to finish refreshing before changing your selection.
-
Select a server
Tap the server you want to use in Home and check that the dot on the left moves to its row. Note the server name and keep using the same entry for the tests that follow.
-
Check routing
Open Home → Global Routing and note whether Proxy, Direct, Config, or Scene is selected. Review the next section to understand the route; don’t assume the initial mode is Config.
-
Turn on the connection
Return to Home and turn on the switch at the top. If iOS asks to add a VPN configuration for the first time, confirm that the request is from Shadowrocket, allow it, and complete device authentication as prompted.
-
Check the status
Return to Shadowrocket and confirm that the switch and connection status show that you’re connected, then open Connectivity Test. If the switch turns off immediately, check authorization and any error message first; don’t keep tapping the switch.
The system’s VPN configuration permission lets the app establish the connection required by the system network extension. It doesn’t replace the server account, password, or other authentication details in your subscription. If you deny permission, the server may still appear in the list, but the connection can’t be established as described above. Follow the system prompts when you try again; a server appearing in the list does not mean authorization is complete.
Here, “default server” means the server currently selected in Home. It’s generally used for connections that follow the default proxy route. A rule in Config can specify a different policy or policy group, so traffic may not use this server. The dot confirms which server is selected; it does not prove that all traffic passes through it.
3. Choosing Global Routing: understand the route used for testing
Global Routing determines how connections are handled. When troubleshooting for the first time, separate two questions: whether the server works, and whether the rules send traffic to it. The recommendations below are for everyday use with a Config you’ve prepared and checked. Until you’ve verified the Config contents, selecting Config alone doesn’t guarantee that traffic is routed correctly.
Config
RecommendedHandles traffic according to the active Config. Rules can choose DIRECT, a proxy policy, or a policy group; the outcome depends on rule order and policy definitions. It doesn’t mean that a particular type of site will always connect directly.
Use when: You have a verified, working Config and want to route traffic according to its rules.
Proxy
Routes traffic handled by the app through the proxy. For a temporary test of the same destination, this reduces variables introduced by Config rules. It can’t fix an incorrect server address, port, or authentication details.
Use when: Briefly checking whether the selected server can access sites through the proxy.
Direct
Routes traffic directly. This does not verify that the selected proxy server works. If a page opens in this mode, it only confirms that direct access to that destination succeeded.
Use when: Comparing basic network access or establishing a direct-connection baseline.
Scene
Selects how traffic is handled based on configured scene conditions. Check the scene conditions and the actual match; the selected server shown in Home alone doesn’t tell you which route traffic takes.
Use when: Scene switching conditions are understood and configured.
If a temporary Proxy test succeeds but the same destination fails after you switch back to Config, check the matching rules and policies in Config before re-importing the subscription. Common rule keywords include DOMAIN-SUFFIX, GEOIP, IP-CIDR, and FINAL. FINAL handles traffic that doesn’t match any preceding rule. Don’t replace the entire Config just to test your first connection.
4. Connectivity Test: verify access even when the test returns a result
Find and run Connectivity Test in Home, then review the result for the selected server. The test method, destination, and related values depend on what the app currently displays and how it’s configured. Keep the test conditions consistent when comparing servers. A reading reflects only that test under those conditions. Timeout means the test didn’t finish within the allotted time; a single result doesn’t show that every destination is unreachable.
Connectivity Test and the system VPN status provide different information: one shows the response along the test route, while the other confirms whether the system connection is established. Even when the system shows VPN connected, remote authentication, DNS, rules, or the destination site may still have problems. Conversely, a test result in the list alone doesn’t prove that browser traffic is passing through the selected server.
Verify in two stages: run the app test, then try browsing
Connectivity Test
- Note the selected server, test method, and result.
- Stay on the same network and retry once to see if the timeout is reproducible.
- A lower reading doesn’t necessarily mean faster downloads or access to every site.
Try browsing
- Open a known HTTPS page that you’re authorized to access.
- Refresh and confirm that new content loads; don’t rely on a cached page.
- Note whether it works under the same Global Routing mode before deciding what to do next.
Check the system connection, test result, and actual access before deciding whether the first connection is complete. If any one of them is abnormal, keep a record of the settings and what you observed.
For example, “home Wi-Fi, Server A, Proxy, Connectivity Test returned a value, HTTPS page failed to load” is more useful for troubleshooting than just “connection failed.” Server A is a label for your own notes, not a recommended server. If the page loads on cellular data, investigate restrictions or DNS on the original network rather than changing the network and server settings at the same time.
5. Troubleshooting: connection switch turns off, test times out, or pages won’t load
Start by identifying the layer based on what you observe, then change one thing at a time. The server address, port, and authentication details must match the information from your own service. Port 443 is a common destination port for HTTPS, not a universal server connection port. Shadowsocks, VMess, VLESS, Trojan, Hysteria2, and WireGuard use different parameter formats; changing Type alone won’t convert one configuration to another protocol.
| What you see | Check first | Next step |
|---|---|---|
| No server entries in Home | Check whether the subscription link is complete, the update succeeded, and the returned content is valid. | Restore the server list before selecting a server or connecting. Keep your subscription credentials private. |
| The top switch turns off immediately | Check whether VPN permission was granted and whether the app reports a configuration error. | Record the exact error message. Address authorization or configuration first rather than repeatedly toggling the switch. |
| Connectivity Test keeps timing out | Check the underlying network, test conditions, selected server status, and connection parameters. | Keep the parameters unchanged and retest on another available network. If needed, check the service status. |
| The test returns a value, but pages still won’t load | Check the route used by actual traffic, DNS, the destination site, and authentication results. | Briefly compare Proxy and Config, and check whether the same destination fails consistently. |
| Proxy works, but Config doesn’t | Check the active Config, which rules match, and the policies those rules specify. | Check which policy the destination actually matches; don’t change the server password first. |
| The connection comes back after a manual disconnect | Check the enabled state and trigger conditions under Settings → On Demand. | Check the automatic connection conditions, then test by disconnecting manually once. |
If only domain names fail, include DNS in your checks, but don’t replace all DNS settings at once. Successful domain resolution and a successful connection to the destination are separate steps. Accessing a destination by IP address may also trigger an HTTPS certificate name mismatch, so don’t assume DNS is the only cause. Record the original values, change one setting at a time, and restore the original configuration if needed for another test.
6. Confirm and wrap up after your first connection
A successful first test means more than seeing an icon: you know which server is selected in Home, why Global Routing is set the way it is, what Connectivity Test returned, and that the page you need can actually load. If you temporarily switched to Proxy while troubleshooting, restore your previously verified routing mode when you’re done, then test access again.
- Check the selection: Return to Home and confirm that the dot is still beside the intended server. Check the selection again after updating the subscription.
- Check the route: Make sure Global Routing matches your current Config. Don’t count successful access under Direct as a successful proxy test.
- Check the results: Run Connectivity Test and load a new page in your browser. Record each result separately.
- Check automatic connections: If you need connections triggered by conditions, check Settings → On Demand separately. Otherwise, leave it in the state you’ve explicitly chosen.
- Keep a baseline: Save your working Config and any useful local notes. When a problem comes up again, compare what changed instead of clearing all settings.
Updating a subscription retrieves the latest entries for a service you already have; tapping a server selects the one to use; the top switch establishes a connection; and Connectivity Test checks connectivity under specific test conditions. Keep these actions distinct and you can troubleshoot list changes, switch issues, or sites that won’t load from the relevant step instead of starting over.