After importing servers into Shadowrocket, select one, check Global Routing, turn on the connection, and verify that your target is reachable. This guide walks iPhone and iPad users with an existing provider configuration through four distinct states: listed, selected, tunnel on, and target reachable. It also outlines what to check when a test fails. Mac, Windows, Android, and Linux users can follow the same troubleshooting logic; control locations vary by platform.
1. Confirm that servers were imported—not just that a subscription was saved
In short: Home must show selectable server entries before you can connect for the first time. A subscription is a source for updating server details; saving its URL does not mean the servers have been retrieved. This guide assumes you already have your own provider and subscription. This site does not provide, sell, or recommend servers or subscriptions.
If Home already shows a server list, continue to the next section. If you see a subscription name but no servers, update the subscription first. Don’t repeatedly toggle the connection before retrieving server details, and don’t enter a subscription URL in an individual server’s address field.
- Add via subscription: Home → “+” in the top-right → Type → Subscribe. Enter your own subscription URL, save it, then return to Home and update the subscription.
- After updating, check that individual server entries appear under the subscription group. If the list is still empty, confirm that the subscription is valid and contains available entries, and that your network can retrieve its data.
- Add manually: Home → “+” in the top-right → Type. Select the protocol specified by your provider, then enter the address, port, and authentication details from the original configuration.
- Know where settings belong: Home manages servers and connections; Config manages routing rules; Settings manages app preferences. Importing a rule file does not add a server.
2. Select a server on Home, then turn on the connection
In short: Tap a server row so the selection dot appears next to the server you want to use. Only then turn on the connection switch at the top of Home. Latency readings, list position, and subscription group names do not indicate which server is selected. Here, “default server” means the server you selected manually. If Config uses a policy group, that group may determine the actual outbound route.
-
Find the server list
Open Home, expand your subscription group, and find the server you want to use. Confirm that the entry is there, then check for duplicate names so you don’t select one with different settings by mistake.
-
Select a server
Tap a server row and confirm that the selection dot appears next to it. Opening the server details only lets you view or edit its settings; when you return, check the selection in the list again.
-
Check routing
Go to Home → Global Routing and check the current mode. Use Config if you have a working rules file. If you haven’t confirmed that your rules are correct, temporarily switch to Proxy for comparison.
-
Turn on the connection
Return to Home and turn on the connection switch at the top. The first time you connect on iPhone or iPad, follow the system prompt to allow adding a VPN configuration and complete any required device verification. If you cancel authorization, the tunnel cannot be established using these steps.
-
Run a test
Leave the connection on, run Connectivity Test on Home, and wait for it to finish. Note the result, then use a browser to check the page you need to reach.
After turning on the connection, check both the app’s connection status and the system VPN status. Whether a system icon stays visible depends on the device interface, so don’t rely on the status bar alone. If the switch immediately turns off, check system authorization or the error message before changing DNS. After switching servers, wait for the connection status to settle. If it seems to be using the previous connection, turn the switch off and back on, then test again.
3. Choosing Global Routing: Understand Config, Proxy, and Direct
In short: Choose Config for everyday use with an existing rules configuration you’ve confirmed works. Temporarily use Proxy to check whether rules are affecting access, or Direct to see how a direct connection behaves. Global Routing controls the routing mode; it doesn’t download subscriptions or fix server authentication settings.
Config
RecommendedRoutes requests according to the rules in the active configuration. Requests may be assigned to DIRECT, a proxy policy, or REJECT—not all requests necessarily use the server selected on Home. Before use, confirm in Config that the intended file is enabled.
Best for: everyday use with a working rules configuration.
Proxy
Handles traffic entering the client in proxy mode, so you can check whether rule-based routing affects access to a target. It doesn’t mean every type of traffic on the device will be intercepted, nor can it make an invalid server work.
Best for: temporarily checking the selected server or troubleshooting the effects of Config rules.
Direct
Handles traffic in direct mode; don’t use it to determine whether a proxy server works. Even if a server is selected on Home, a page loading while Direct is active does not prove the proxy connection works.
Best for: checking whether ordinary webpages are reachable over your local network as a direct-connection comparison.
If Global Routing shows Scene, it applies routing behavior based on configured scene conditions. Before testing for the first time, confirm which mode the current scene will use. If you’re unsure, temporarily set Config or Proxy to reduce variables. Restore your original settings after testing; a temporary troubleshooting mode is not a finished everyday setup.
4. After Connectivity Test passes, check real requests too
In short: Connectivity Test checks connectivity to its test target. It is not a bandwidth test and doesn’t guarantee that every website or app will work. Server-list latency checks, the connection switch, Connectivity Test, and actual browser access are separate signals; record them separately.
| Where to check | What it confirms | What it does not confirm on its own |
|---|---|---|
| Selection dot on Home | The server entry currently selected manually | Successful server authentication or access to a target |
| Connection switch and VPN status | Whether the tunnel is on | Whether the remote server, DNS, and target site are all working |
| Server latency check | The response under the current check method | Success rate and download speed for complete requests |
| Connectivity Test | Connectivity to the test target under the current settings | That all requests use the proxy or all targets are reachable |
| Actual browser access | Whether a specific page loads under the current conditions | Whether other apps, domains, and networks also work |
For a consistent check, follow the same order: turn on the connection, run Connectivity Test, then open a browser and refresh the target page. If the test passes but the page fails, note whether the error is a DNS resolution failure, connection timeout, or certificate error instead of simply recording “can’t connect.” If the browser shows an old page, refresh it or open a new one so cached content isn’t mistaken for a successful new request.
For example, “the test passes and the target page loads in Proxy, but the same page fails in Config” points first to a difference in configuration or policy. “The test times out in both modes, but ordinary webpages work when the connection is off” calls for checking server settings and the proxy connection. These are troubleshooting branches, not results from testing any particular service. When retesting, keep the server, network, and target the same; change just one setting.
5. If a test fails, check server settings and routing separately
In short: First check whether the server can connect, then check whether requests follow the expected policy. Shadowsocks, VMess, VLESS, Trojan, Hysteria2, and WireGuard use different fields; changing only the protocol name while keeping the old settings won’t work. Make sure the address, port, authentication details, and transport-related fields match your provider’s configuration.
Server checks
- Type
- Use the protocol specified in the original configuration; a similar name is not a substitute.
- Address
- Use the domain or IP specified in the original configuration; don’t switch between them arbitrarily.
- Port
- Check every digit. Entering 443 does not necessarily mean the service uses TLS.
- Authentication
- Check the password, UUID, or key. Make sure copying hasn’t added spaces or line breaks.
A port number does not identify the protocol; use the complete settings provided by your provider.
Routing checks
- Mode
- Go to Home → Global Routing and note the current mode.
- Configuration
- Open Config and confirm that the intended file is enabled.
- Policy
- Check whether the target domain matches DIRECT, PROXY, REJECT, or a policy group.
- Auto-connect
- Go to Settings → On Demand and check whether any auto-connect conditions could affect your retest.
Keep the routing mode fixed while troubleshooting. Restore your auto-connect settings after retesting.
Config rules are matched from top to bottom. FINAL handles requests that didn’t match earlier rules. DOMAIN-SUFFIX matches domain suffixes, IP-CIDR matches IP ranges, and GEOIP matches based on the destination IP’s geographic classification. Once a broad rule matches, more specific rules below it won’t take effect. The example below demonstrates syntax and order only; it is not a complete configuration to use as a replacement for your everyday setup.
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXYexample.com in the example is used only to demonstrate rule syntax, not to recommend a service. If a rule sends the test target to DIRECT, a successful test still doesn’t prove the proxy server works. To verify the proxy connection, compare results in Proxy and check actual requests. Don’t disable certificate verification just to make a test pass; that can mask issues with the domain, device time, or server certificate.
6. Compare Wi-Fi and cellular data without changing multiple variables
In short: If the same configuration behaves differently on two networks, continue troubleshooting the network conditions first instead of deleting all your settings. Before switching networks, note the selected server, Global Routing mode, and test target. Keep all three the same on the other network, then run Connectivity Test again.
Comparison: Keep the configuration fixed and switch only the network
On Wi-Fi
- Confirm that you’ve completed any Wi-Fi captive portal sign-in and can access ordinary webpages directly.
- Note the selected server and Global Routing mode.
- Turn on the connection, run Connectivity Test, then check the target page.
- If it fails only on this network, check router restrictions, DNS, and UDP reachability.
On cellular data
- Turn off Wi-Fi and confirm the device is using cellular data.
- Keep the same server, routing mode, and test target.
- Reconnect before testing; don’t rely on the previous result.
- If the app can’t connect, check whether it’s allowed to use cellular data in system settings.
Change only the network for each test. Once you confirm a difference, check DNS, transport protocol, or network restrictions separately.
If auto-connect is configured under Settings → On Demand, turning the connection off manually may trigger it to reconnect. For a clear direct-connection comparison, note and temporarily disable any relevant auto-connect conditions, then restore them after testing. For connections that rely on UDP, such as Hysteria2 and WireGuard, also confirm that the current network allows the required UDP traffic. A TCP webpage loading does not prove that UDP is reachable.
7. First connection FAQs
I’ve imported the servers. Why do I still need to tap one?
Importing adds servers to the Home list; it doesn’t select one for you. Return to Home, tap the server you want to use, confirm the selection dot, then turn on the connection. If Config uses a policy group, check the selection in that group too.
The connection is on, but Connectivity Test times out. What should I do?
First make sure Global Routing isn’t set to Direct by mistake, then check the selected server’s address, port, and authentication details. Run a comparison in Proxy. If it still fails, leave the configuration unchanged, retest on Wi-Fi and cellular data, and note where the timeout occurs.
The test passes, but why won’t one particular webpage open?
Refresh the page first and note the exact error. In Config, check which file is in use and which policy matches the target. Then switch temporarily to Proxy and test again. If only one domain fails, check its DNS, rules, and service status. A successful test doesn’t mean every website is reachable.
How do I check whether the connection is still active after reopening the app?
Return to Home and check the connection switch, selected server, and Global Routing mode, then run Connectivity Test again. If the connection comes back automatically, check Settings → On Demand. If the switch is off, turn it on again and watch for a system authorization prompt or connection error.
Your first connection is set up when the server selection is clear, the tunnel is on, the routing mode matches your intent, and both Connectivity Test and access to the target have been verified. Reuse this sequence after changing servers, updating a subscription, or switching configuration files instead of relying on a single latency reading to judge whether the connection works.