This guide walks through a first connection with Shadowrocket on iPhone or iPad. You’ll need your own server details or subscription. Follow the steps in order: import your details, select a default server, authorize the connection, and review the test results. It also distinguishes between an active system VPN connection, a reachable server, and an accessible website.
1. Check your installation and server details
If you haven’t installed Shadowrocket yet, visit the download guide to find the option for your device. There are two ways to get the app: the iPhone and iPad version is a one-time $2.99 purchase on the App Store; the Mac (Apple silicon and Intel), Windows, Android, and Linux versions are free. The iPhone and iPad app is published by Shadow Launch Technology Limited. Check the App Store listing for system requirements. VPN authorization prompts may vary by platform; the steps below apply to iPhone and iPad.
Installing the app does not provide a usable server. To connect, you’ll need your own server address, port, and protocol credentials, or your own subscription link. This site does not provide, sell, or recommend servers or subscriptions. Don’t post subscription links, passwords, or complete configurations in public forums; a token may grant access to your subscription.
- Using an existing subscription: Tap “+” in the top-right corner of Home, set Type to Subscribe, enter your subscription URL, and save it. Then update the subscription. Continue only after actual server entries appear in the list.
- Adding an individual server: Tap “+” in the top-right corner of Home and choose the appropriate Type for your details. Check the address, port, and authentication information field by field. Shadowsocks, VMess, VLESS, Trojan, and other protocols use different fields; don’t choose a Type based on the address alone.
- Using an existing Config: A configuration file and a server subscription are different things. A Config can include routing rules and policy references, but importing one does not necessarily create a usable server entry.
2. Select a default server in Home and connect
Seeing a server name in Home only confirms that an entry exists. For your first connection, select the server you intend to use, then turn on the connection. Tapping the dot beside a server is different from opening its edit screen. After editing an address, return to the list and check the default selection again.
-
Check the server list
Open Home, expand the list for your existing subscription, and confirm that at least one server entry appears. If the list is empty, check the subscription URL and update status before trying the connection toggle again.
-
Select a default server
Tap the dot beside the server you want and confirm that the selection indicator appears next to it. While troubleshooting, stick with the same server; don’t change both the server and routing mode between tests.
-
Check the routing mode
Open Home → Global Routing and check whether the current mode is Config, Proxy, or Direct. To test the proxy route, don’t leave it set to Direct. In Config mode, also check that the active configuration’s rules and policy references are valid.
-
Turn on the connection
Return to Home and turn on the connection toggle at the top. When prompted to add a VPN configuration for the first time, confirm the request is from Shadowrocket, allow it, and complete any device verification required by the system.
-
Check the connection status
Wait for the connection status to settle, then run Connectivity Test. If the toggle immediately switches off, troubleshoot authorization or the system connection first; don’t assume the website itself is at fault.
An active system VPN status means the device’s traffic tunnel is up. It does not confirm that remote authentication succeeded or that every request is routed through the proxy. In Config mode, a selected policy group may refer to other servers in that group, so the default server selected in Home may not determine every policy route.
3. Test connectivity in stages
Once connected, run Connectivity Test from Home and review the result when it finishes. The test checks whether its target is reachable with your current settings; it does not guarantee access to every website, protocol, or app. Note the server name, Global Routing mode, and network used so you can compare results later.
- A response time appears: The test measured the response for this run. This is not a download speed and doesn’t indicate video throughput or long-term connection stability.
- The test times out or fails: Record the full message, then check the test target, server details, and current network. One timeout does not prove the entire connection is unavailable.
- The test passes but a website won’t load: Check the rule that applies to the site, DNS resolution, and the site’s status. Don’t assume one successful test applies to every request.
- A website loads, but the proxy may not be working: Direct mode or a DIRECT rule in Config may send requests directly. A website loading does not prove that traffic went through the proxy.
After the test, open a website you actually need to use, then check your everyday apps. If only one app has a problem, keep the server and network unchanged while checking whether the app uses a separate connection or is affected by a rule. Connectivity Test latency, subscription-list latency tests, and actual download speed are different measurements.
4. How Global Routing affects your first test
A common first-connection mistake is to assume the proxy is working because a website loads in Direct mode, or to assume the server is down because one domain fails in Config mode. Identify the current routing mode before interpreting the result. The modes below are Shadowrocket routing settings, not comparisons with other products.
Config
RecommendedRequests are handled by the rules and policies in the active configuration. Requests matching DIRECT connect directly; requests matching a proxy policy use that policy. Unmatched requests are handled by subsequent rules or FINAL, not necessarily sent directly.
Best for: Everyday split routing and a final check with a working configuration.
Proxy
Routes traffic handled by the app through the proxy, making it easier to temporarily reduce the effect of split-routing rules while troubleshooting. It cannot bypass server authentication errors or fix an incorrect address, port, or TLS setting.
Best for: Temporarily checking whether a problem is caused by Config rules or policies.
Direct
Uses a direct route without the proxy. This can provide a direct-connection baseline on your current network, but it cannot test whether the remote proxy server is working.
Best for: Checking whether your local network can reach the same test target directly.
If you use Scene, check the settings for the active Scene first. It is not the same as a global Proxy switch. For an initial comparison, select one of the modes above, then restore your original configuration when you’re done. Switching modes changes routing behavior; it won’t add a subscription or correct server authentication fields.
5. Narrow down connection problems
Change one variable at a time and rerun the same test after each change. Switching servers, Global Routing modes, Wi-Fi, and cellular data all at once makes it impossible to identify the cause of a success or failure. First determine whether the toggle won’t stay on or the connection is active but requests fail, then follow the relevant steps below.
Check the two failure types separately
The toggle switches off immediately
- Make sure you completed the initial system VPN authorization and didn’t cancel device verification.
- Check in system settings that the VPN configuration exists and that device management policies don’t block connections.
- Temporarily stop any other active VPN connections, then return to Home and try again.
- Open Settings → On Demand. Temporarily turn off automatic connection triggers while troubleshooting, then test with the manual toggle.
Connected, but requests fail
- Check that the dot beside the intended server is selected in Home, then verify Global Routing.
- Check the server address, port, protocol, password or UUID, and any required TLS settings, one by one.
- Update your subscription and check for update errors or changes to the server entries.
- Keep the same server and test over Wi-Fi and cellular data separately. Note whether the problem occurs on only one network.
First confirm that the system connection stays active, then check remote reachability. Repeatedly toggling the connection is not a substitute for checking each layer.
If Wi-Fi fails but cellular data works, check whether Wi-Fi requires web authentication, restricts relevant ports, or has DNS issues. These are troubleshooting leads, not proof that the network is blocking the connection. If both networks fail, check whether your existing service is active, whether the server is still in your subscription, and whether the protocol fields match your original details.
Hysteria2, WireGuard, and other protocols use UDP. A successful TCP request alone does not confirm that their transport path is working. Don’t change Type to another protocol just to test: the remote server and local settings must use the same protocol, and changing the label won’t change the service the server provides.
6. Verify and document the connection
After Connectivity Test completes, restore the routing mode you plan to use and test the websites you actually need. If you temporarily used Proxy while troubleshooting, test again after restoring Config; the same domain may take a different route in each mode. Configure On Demand only after manual connections are stable, so automatic triggers don’t make initial troubleshooting harder to follow.
- Restore your settings: In Home → Global Routing, select your usual mode and check the active Config and policy selection.
- Run the test again: Run Connectivity Test once more and open a website you need to confirm it works outside the temporary mode.
- Check automatic connections: If you need automatic triggering, open Settings → On Demand and configure it for your network conditions. Restore any settings you turned off during testing if they’re part of your usual setup.
- Keep troubleshooting notes: Record the network type, server name, routing mode, error message, and time. Before sharing logs, redact subscription tokens, passwords, UUIDs, and other sensitive details.
A successful first connection should meet three conditions: the system tunnel stays active, the test target responds, and the apps or websites you need work as expected. If a problem comes up later, checking these layers in order is usually more useful than deleting all your settings—and preserves known-good settings for comparison.