For your first connection, confirm that a server is selected, iOS allows the VPN configuration, and both the test and real-world access work as expected. This guide walks iPhone and iPad users who already have a provider and subscription through Home → Global Routing → the connection switch → Connectivity Test, distinguishing between “the switch is on,” “the test returned a result,” and “the target app works.”
1. Get your server details first—buying the app does not provide a connection service
Shadowrocket is a paid app for Apple platforms and is available exclusively on the App Store. Before installing, verify the official icon, developer Shadow Launch Technology Limited, and app ID 932747118 on the App Store verification page. This guide focuses on first-time connections on iPhone and iPad; check the App Store listing for system requirements.
Buying the app is not the same as buying a service plan. This site does not provide, sell, or recommend servers or subscriptions. Before you begin, you must already have your own provider and a working subscription, or the complete connection details for a server. Buying and installing the app alone will not add a connectable server to Home.
- Already have a subscription: On Home, tap “+” in the upper-right corner and choose Add Server. Set Type to Subscribe, enter your subscription URL, and save. When the update finishes, check that server entries appear in the list.
- Already have a server: On Home, tap “+” → Add Server, choose the Type specified by your provider, and enter the supplied Address, Port, and authentication details.
- Check the protocol: Shadowsocks, VMess, VLESS, Trojan, Hysteria2, and WireGuard use different fields. Don’t guess the Type from the server name or enter a password for one protocol in another protocol’s authentication field.
- Protect your credentials: A subscription URL, Password, UUID, or key may grant access to the service. When reporting a problem, hide these details and include only the protocol, symptoms, and error text.
2. Select a default server on Home and authorize the VPN configuration
After importing your server details, tap the entry you want to use on Home. Viewing or editing its details is not the same as selecting it as the default server; check which entry is currently marked as selected. If a subscription contains multiple entries with the same name, verify their group as well, so you don’t test one entry while another is selected.
Select a server
Go to Home, tap an existing server, and confirm that the selection indicator appears on that entry. Use this same server throughout the initial checks; don’t switch among multiple candidates.
Check routing
Go to Home → Global Routing and note the current mode. To temporarily isolate the effect of rules, you can select Proxy. You can also use Config if you’ve already verified it, but make sure you know which rule will match the test target.
Turn on the connection
Return to Home and turn on the connection switch at the top. On the first connection, iOS may ask to add a VPN configuration. Confirm that the prompt was triggered by this action, tap Allow, then complete any verification requested by your device.
Check the connection status
After authorization, return to Home and check that the switch and connection status stay active—not just that they changed momentarily when tapped. If the switch turns off immediately, address the system authorization or connection error first; don’t start by changing rules.
Run a connectivity test
On Home, run Connectivity Test and review the result for the selected server using the current test method. Then open the website or app you actually need and confirm that its requests work too.
System authorization allows a VPN configuration to be established; it does not confirm that your provider has authenticated the connection. A VPN status indicator alone does not prove that server authentication, the TLS handshake, DNS resolution, and access to your target are all working. Complete the verification steps below.
3. Understand the four Global Routing modes
Global Routing determines how traffic entering the tunnel is handled once a connection is established. To reduce variables during initial troubleshooting, use Proxy to test the selected server if you’re unsure which policy a rule will select. Then switch back to Config to check your everyday routing. This recommendation applies only to initial connectivity troubleshooting, not as a default for every situation.
Proxy
RecommendedRoutes traffic entering the tunnel through the proxy. Use it to test the selected server first, with Config routing rules out of the way. It does not replace correct server authentication or transport settings.
Best for: troubleshooting a first connection and temporarily isolating routing rules.
Config
The rules in the active configuration determine how traffic is handled. A rule may select DIRECT, PROXY, or a policy defined in the configuration; this does not mean all domains use the selected server.
Best for: everyday routing and rule testing with a verified Config.
Direct
Uses a direct connection. If a website loads in this mode, that only suggests the direct route may be working; it doesn’t confirm that the default server is in use.
Best for: comparing baseline network behavior and distinguishing direct from proxy traffic.
Scene
Uses the configured scene settings. The result depends on the active scene and its match conditions. Missing or unverified scene settings are not a reliable baseline for an initial test.
Best for: situations with clearly defined scene settings and verifiable match results.
4. Read Connectivity Test results without treating latency as the whole story
On Home → Connectivity Test, check the current test method, then review the result for the relevant entry. Different methods test different things: a TCP probe mainly reports whether a connection to the server’s address and port can be made, while a test through the proxy also depends on the relevant protocol and test target. Before comparing results, keep the server, test method, and network the same.
| What you see | What it tells you | What to do next |
|---|---|---|
| A value in milliseconds appears | The current test method completed a measurement; this does not mean every target is accessible. | Keep this server selected, then test the website or app you actually need. |
| A timeout appears | The required response didn’t arrive within the test’s wait period. This alone doesn’t identify the failing layer. | Check the address, port, and current network, then retry under the same conditions. |
| TCP test returns a result, but real-world access fails | The port is reachable, but authentication, the protocol handshake, DNS, or the route to the target may still be failing. | Check Type, authentication fields, TLS, and transport settings, then review routing. |
| One entry fails while others succeed | The issue is more likely specific to that entry or its server-side route, but keep test conditions the same to compare results. | Check that entry on its own; don’t change every server at once. |
Lower latency doesn’t guarantee bandwidth, and a single successful test doesn’t guarantee continued availability. The test target may use a different domain, connection method, or server from the app you’re trying to use. If the test succeeds but the app fails, investigate the app’s specific symptoms instead of repeatedly choosing the lowest millisecond value.
Test requests and real-world requests separately
Connectivity Test
- Keep one server and one test method fixed.
- Record whether the result is a value, timeout, or other exact message.
- Run a new test when switching between Wi-Fi and cellular; don’t compare results from different networks as if they were the same test.
Real-world website or app
- With the connection still active, send the request again.
- Distinguish between a page failing to load, a sign-in failure, and media failing to load.
- Under Config, check which rule and policy actually match the target.
The first-connection check is complete only when both the test and real-world access work as expected. If they differ, investigate the failing step.
5. If the connection fails, check these three areas first
First: system authorization and connection status
If the Home switch won’t stay on, first confirm that you allowed the initial VPN configuration request and check whether device management policies are restricting it. If another VPN configuration is already in use on the device, confirm which connection is active. Don’t mistake “the system hasn’t allowed the connection” for a server latency issue.
- Return to Home, try connecting once more, and read the full prompt. Don’t rapidly toggle the switch repeatedly.
- Open system settings and check the VPN status to make sure another configuration hasn’t taken over.
- If the connection keeps restarting automatically, check the existing enabled status and conditions under Settings → On Demand. Note the original settings before deciding whether to temporarily disable them for a manual test.
Second: selected server and subscription details
If the connection stays active but the test fails, check the specific selected entry. A subscription update may change server addresses or authentication details. After updating your subscription, confirm that the entry is still present and selected. Updating a subscription and switching Config files are separate actions; the former won’t automatically fix rules in the latter.
- In Add Server, check Type, Address, and Port against the original details from your provider.
- Check the protocol-specific fields, such as Password, UUID, or keys. Don’t reuse parameters across protocols.
- For TLS, check the server name required by your provider. For a specific transport, check the corresponding path and host fields.
- Don’t hide handshake errors by turning off certificate verification, and don’t change every entry before you know why the connection is failing.
Third: Global Routing, rules, and DNS
If real-world access works under Proxy but fails for the same target under Config, focus on the active Config’s rule order, policies, and DNS settings. This can help narrow down the cause, but one result alone doesn’t prove where the problem lies. The following examples illustrate rule syntax; they are not a complete file to replace your existing configuration with:
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYDOMAIN-SUFFIX,example.com,PROXYmatches example.com and its subdomains. An earlier matching rule may change the final outcome.IP-CIDRmatches an IP range. In the example,no-resolveprevents an active DNS lookup for this IP rule.GEOIPmatches based on IP geolocation; it is not simply a domain-suffix match.FINALhandles traffic that didn’t match any earlier rule. Check that it points to the intended policy.
A DNS resolution failure can occur even when the proxy port is reachable and the website’s domain is not. Note any DNS-related error and check the existing DNS settings in Config. Don’t change DNS, the server, rules, and protocol all at once to troubleshoot a single issue. Change one thing at a time so you can tell what affected the result.
6. Wrap up after your first connection
After a successful test, restore the Global Routing mode you plan to use and check the same target again. If you temporarily used Proxy, confirm the target’s rule and policy after switching back to Config. On Demand controls when a connection is established based on conditions; it cannot replace server authentication or fix incorrect routing rules. If you need automatic connections, check the conditions separately under Settings → On Demand.
- Confirm the default: Keep the intended server clearly selected on Home so you don’t confuse a tested entry with the current default.
- Confirm routing: Note the current Global Routing mode. If you use Config, verify that the intended configuration is active.
- Confirm real-world access: Test websites, sign-in, and any other required actions separately. One test cannot replace checks for every use case.
- Keep troubleshooting notes: Record whether you used Wi-Fi or cellular, the test method, the exact error, and any settings you changed. Hide subscription credentials.
If the issue occurs only on a particular network, compare results using the same server and test method. If only one target fails, continue by checking its rules and DNS path. For more troubleshooting steps, see Troubleshooting. For interface terms and rule keywords, see the Glossary.
App Store verification and first-time setup
Shadowrocket is a closed-source commercial app sold as a one-time purchase and available exclusively on the App Store. The purchase does not include a network service. Check the App Store listing for device compatibility and system requirements. Verify the official icon, developer, and app ID, then follow the guide to set up your own server details.