This guide is for users who have already imported their own subscription or entered server details manually in Shadowrocket. It explains how to confirm the selected server, configure Global Routing, approve the system VPN request, and use Connectivity Test results to distinguish configuration, network, and rule issues.
Confirm the subscription and server entry first
A first connection requires an available server entry in Home. Shadowrocket is a paid client for Apple platforms; a one-time purchase covers use of the app and does not include proxy service. The subscription URL, server hostname, port, password, and protocol settings must come from a service the user already has. The app does not generate this data automatically.
If Home still shows an empty list, check the import process first. To add a subscription, open the add page from the upper-right corner of Home, set Type to Subscribe, and enter an existing subscription URL. A placeholder used only to understand the format can be written as https://example.com/sub?token=xxxx; actual use requires the user's own valid URL. Save it, return to Home, and pull down to refresh the list.
Verify the app
Get Shadowrocket from the App Store and confirm that the developer is Shadow Launch Technology Limited and the app ID is 932747118; system requirements are subject to the App Store listing.
Refresh the subscription
Open Home, pull down to refresh the saved Subscribe entry, and wait for the server list to finish updating. Do not repeatedly switch networks during the update.
Check the parameters
For a manual Add Server entry, check Type, Address, Port, Password or UUID, as well as protocol-related fields such as TLS and Transport.
Select a server
Tap the server entry you plan to use in Home and confirm that a selected dot appears on its left or in front of it. An imported but unselected server does not provide a clear target for the connection switch.
Keep the current network
During the first verification, stay on the current Wi-Fi or cellular network. Switch networks only after testing so a network change is not mistaken for a parameter error.
Select a server in Home and set Global Routing
Home may contain multiple servers. Tap one to make it the current connection target, as shown by the selected dot. The latency value reflects the response at the time of that test and does not replace full connection verification. If no latency is shown, do not delete the entry immediately; check the protocol parameters and try Connectivity Test.
After selecting a server, review Global Routing. This setting determines whether traffic follows the Config rules, goes entirely through the current proxy, connects directly, or switches according to a Scene. For the first everyday check, Config is usually the best choice because it verifies both the server connection and the rule file. If you suspect the rules are preventing a target from using the proxy, temporarily switch to Proxy for comparison, then restore the previous setting.
Config
RecommendedMatch the rules in the current Config from top to bottom. Apply the corresponding policy at the first match; traffic not matched earlier is handled by FINAL.
Best for: routine routing checks after the basic connection is working
Proxy
Send traffic through the currently selected proxy server instead of directly routing it according to the normal split-routing result. This can help determine whether the issue comes from the rules.
Best for: temporarily ruling out Config rule-matching issues
Direct
Connect directly to the destination without using the current server. Even with the main switch on, staying in this mode does not prove that the proxy server is working.
Best for: comparing whether the local network can reach the destination directly
Scene
Use the policy assigned to the configured network scene. Confirm the scene conditions and their corresponding actions first.
Best for: users who have completed the basic connection and configured network scenes
Rule order in Config directly affects the result. Shadowrocket searches from top to bottom and stops after the first match. The syntax below explains the matching relationship only and should not replace the user's complete configuration:
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYDOMAIN-SUFFIXmatches domain suffixes; for example, a subdomain can also matchexample.com.IP-CIDRmatches an IP address range; the private address range in the example remains Direct.GEOIPmatches based on geographic data for the destination IP. The result depends on the data used by the current configuration.FINALhandles traffic that matched none of the preceding rules and is usually placed at the end of the rule list.
Turn on the main switch and approve the system VPN request
After confirming the server and Global Routing, turn on the main connection switch in Home. The first time a system VPN configuration is created, iPhone or iPad displays a system authorization prompt. Follow the system interface and confirm with the device passcode, Face ID, or Touch ID. Apple manages this authorization; Shadowrocket must receive permission before it can create the connection configuration.
After authorization, return to Home and watch the switch state. If it immediately turns off, do not retry repeatedly; check the error shown by the app first. Any mismatch in a key field such as the port, password, UUID, certificate name, TLS, or Transport can terminate the connection during setup.
Before-connection status
- Page
- Home
- Server
- A selected dot appears in front of the entry
- Routing
- Global Routing is set to Config
- Network
- Wi-Fi or cellular data can access the internet normally
These four items provide repeatable conditions for the first test.
System authorization
- Trigger
- Turn on the Home main switch for the first time
- Authorization target
- System VPN configuration
- Confirmation
- Complete authentication as prompted on the device
- After completion
- Return to Home to check the connection status
Rejecting authorization prevents the system VPN configuration from being created. Turn the switch on again and follow the system prompt.
- Keep the selected dot for the Home server unchanged, and note the current Global Routing mode.
- Turn on the main switch and respond only to the VPN configuration request actually shown by the system.
- After authorization, wait for the connection state to stabilize. Do not repeatedly toggle the switch within a short period.
- If the connection drops automatically, check the error message first, then review the server's protocol fields.
- Once the switch stays on, run Connectivity Test. Do not treat the switch state alone as the final result.
Use Connectivity Test to verify the connection
With the main switch on, open Connectivity Test from Home. This performs an actual connectivity check and is more representative of the current connection than a single latency result in the server list. Keep the app in the foreground during testing, wait for all checks to return, and do not change Global Routing while the test is running.
Interpret the result together with the test target. A duration usually means a response arrived within the allowed time; Timeout means the request did not complete within the waiting window. A timeout may result from an unreachable server, incorrect protocol fields, failed DNS resolution, network restrictions, or an unexpected Config route. One Timeout alone cannot identify the cause.
The test returned a result
- Entry point
- Home → Connectivity Test
- Observation
- The test item returns a duration or success status
- Next step
- Access the actual destination that needs verification
- Recheck
- Switch back to Config and test again
A successful test means that request completed; still evaluate the actual destination and the matched rule before drawing a conclusion.
The test timed out
- First
- Confirm that the server is still selected
- Second
- Temporarily compare Config with Proxy
- Third
- Check Address, Port, and authentication fields
- Fourth
- Switch back to the original network that can access the internet normally and test again
Change only one variable at a time so the affected layer can be identified from the before-and-after results.
Distinguish latency tests from actual connectivity
- A millisecond value in the server list means that the latency probe received a response; it does not mean every destination is reachable.
- If the server list shows Timeout, check the current network and server parameters first. Do not immediately attribute the issue to the rule file.
- Connectivity Test succeeds but a specific domain fails: check which
DOMAINorDOMAIN-SUFFIXrule matched the domain. - Proxy works but Config does not: focus on rule order, policy names, and where
FINALsends the traffic. - Direct works but Proxy times out: focus on the currently selected server and its protocol fields.
For example, if a domain cannot be reached under Config but completes the test under Proxy, the server itself is responding, so troubleshooting should focus on the Config match. Check whether an earlier DOMAIN-SUFFIX, GEOIP, or IP-CIDR rule sends the request to Direct, and confirm that the policy name matches a policy defined in the configuration.
Troubleshoot a failed first connection by symptom
When the first connection fails, the most effective approach is to keep variables fixed: use the same network, server, and test target, changing only one setting at a time. Confirm the Home selection first, check whether the main switch stays on, and then compare Connectivity Test under Config, Proxy, and Direct.
What if the switch turns off immediately?
Check the error currently shown by Shadowrocket, then return to the server details and verify Address, Port, Password, or UUID. For Shadowsocks, also check Method. For VMess and VLESS, check UUID, TLS, and Transport. For Trojan, check Password and TLS. For Hysteria2, check the port, authentication details, and TLS name. For WireGuard, check the keys, Address, and Peer parameters.
What if there is no selected dot in front of the server?
Tap the server entry you plan to use directly in Home and wait for the selected dot to appear before turning on the main switch. If the list is empty, refresh the existing Subscribe entry first; if the refresh fails, verify that the subscription URL is complete.
What if the switch shows connected but webpages still do not open?
Make sure Global Routing is not set to Direct, then run Home → Connectivity Test. If Proxy returns a result but Config fails, check rule order and FINAL. If both time out, check the server parameters and current network.
What if the server changes unexpectedly after a subscription update?
An update may change the list names, order, or entry contents. Confirm again which server has the selected dot, and check that the updated Type, port, and transport parameters match the current configuration provided by the service provider.
What if the connection fails after switching to cellular data?
Without changing the server parameters, run Connectivity Test first, then switch back to the original Wi-Fi network for comparison. If only one network fails, check Settings → On Demand for Connect or Disconnect conditions targeting that network type.
Do not mix fields between protocols
Different Type values in Add Server use different fields. Common core fields for Shadowsocks are Address, Port, Password, and Method. VMess and VLESS usually use UUID and may include TLS and WebSocket Transport settings. Trojan focuses on Password and TLS-related fields. Hysteria2 uses UDP and QUIC; in addition to authentication, check the TLS name. WireGuard uses a local private key, Address, DNS, and the Peer's public key and Endpoint. Similar field names do not make them interchangeable.
| Observation | Check first | Next action |
|---|---|---|
| The switch turns off immediately | Protocol auth and transport fields | Check Type, Address, Port, and auth details |
| Proxy succeeds, Config fails | Rule matching and policy names | Check the order of DOMAIN-SUFFIX, GEOIP, IP-CIDR, and FINAL |
| Wi-Fi succeeds, cellular fails | Network conditions and On Demand | Keep the server unchanged and test on both networks |
| Cannot connect after an update | Currently selected server | Select the entry again and review the updated parameters |
A fixed check sequence after the first connection
Once Connectivity Test returns a result and the actual destination is reachable as expected, use a fixed troubleshooting sequence. For future connection issues, check the selected server in Home first, then Global Routing, then connectivity, and only afterward modify protocol parameters or rules. This avoids changing several locations at once and losing a reliable comparison.
On Demand is a later automation setting, not a requirement for the first manual connection. To connect automatically on Wi-Fi or cellular networks, open Settings → On Demand and configure the conditions. First complete one stable manual connection, then confirm that each condition maps to Connect, Disconnect, or another expected action so automation does not interfere with troubleshooting.
Daily connection sequence
- Step 1
- Confirm the selected server in Home
- Step 2
- Set Global Routing to Config
- Step 3
- Turn on the main switch
- Step 4
- Run Connectivity Test
- Step 5
- Verify the actual destination
Once the sequence is fixed, it becomes easier to identify the step where an issue occurs.
On Demand
- Entry point
- Settings → On Demand
- Prerequisite
- Manual connection has been verified successfully
- Condition
- Match by Wi-Fi or cellular network
- Action
- Apply the connection behavior defined by the existing rules
- Recheck
- Observe the actual state after switching networks
Test automatic connection conditions one by one, separately from the first manual troubleshooting session.
- After a subscription update, confirm the current server again because the list contents and order may have changed.
- After editing Config, check the rule syntax before running Connectivity Test.
- When switching between Wi-Fi and cellular networks, keep the server unchanged and use the same target for comparison.
- When troubleshooting, note whether Global Routing is currently Config, Proxy, Direct, or Scene.
- Do not treat one latency value as proof of continuous availability; rely on an actual test on the current network.