For your first Shadowrocket connection, follow this order: choose a server → confirm the routing mode → turn on the connection → run a test → check real-world access. This guide assumes you already have your own provider configuration or subscription. It explains the roles of the dot beside a server in SERVER, VPN configuration permission, and Connectivity Test, and covers three distinct issues: blank results, timeouts, and tests that succeed even though a page will not load.
Before connecting: make sure SERVER has a usable configuration
After purchasing and installing Shadowrocket, import your own server details or an existing subscription. Buying the app does not include a service plan: the purchase does not provide a server address, port, or authentication details. Before connecting for the first time, make sure Home’s SERVER section shows actual server entries—not an empty list or subscription group names only.
If you already have a subscription that has not been imported, tap “+” in the top-right corner of Home, open Add Server, select Subscribe under Type, enter your own subscription URL, and save. Then return to Home and update the subscription. Entries appearing after the subscription is parsed only means the configuration has been added to the list; it does not mean every server is currently reachable. This guide does not provide or recommend subscriptions. The steps below apply only to configurations you already have.
- Check the server details: Open the entry’s edit screen and make sure Type, the server address, and port match the original details. Authentication fields depend on the protocol in use.
- Check the subscription status: If the list is empty, resolve the import or update issue first. Repeatedly toggling the connection will not help.
- Check your network: Turn off the Shadowrocket connection and use your current Wi-Fi or cellular network to open a page that normally loads directly. If public Wi-Fi requires a sign-in, complete that step first.
- Keep the original settings: Do not change the UUID, Password, TLS, or transport settings just to try to connect. The same server address does not mean settings for different protocols are interchangeable.
First connection: select the dot, then turn on the connection
In Home’s SERVER list, tap the dot to the left of a server to select it as the default. Editing an entry and selecting the default server are separate actions: viewing a server’s details does not mean it has been selected. After returning to Home, check the selection indicator in the list.
-
Select a server
Go to Home → SERVER, find the server whose details you checked, and tap the dot to its left. Note the entry name and use the same entry for the tests that follow.
-
Confirm the routing mode
Go to Home → Global Routing and check whether Config, Proxy, Direct, or Scene is selected. When troubleshooting the server itself for the first time, you can temporarily use Proxy. Restore your usual setting when you are done.
-
Turn on the connection
Return to Home and turn on the connection switch at the top. The first time iOS prompts you to add a VPN configuration, make sure the request is from Shadowrocket, allow it, and complete authentication as prompted.
-
Run a test
Wait for the connection status to update, then tap Home → Connectivity Test. Wait for the test to finish and check the result for the selected server. Do not switch servers repeatedly while the test is running.
-
Check access
Open a browser, visit the page you need, and refresh it. Consider the actual result alongside the test result rather than relying on a latency number alone.
If you did not allow the VPN configuration to be added the first time, try connecting again and respond to the system prompt. Having a server in the list, selecting it with the dot, and establishing a VPN connection are three separate things. A connected status does not mean the remote server has authenticated successfully or that every website will load.
Global Routing: what to check during a test
Global Routing determines how traffic is routed. Changing the routing mode can change the path used for actual access, even if the default server stays the same. During troubleshooting, note the current selection and change only one variable at a time. Do not change servers, DNS, and routing together, or you will not know which change affected the result.
Config
Routes connections according to the active configuration’s rules and policies. A rule may route traffic to DIRECT, a proxy policy, or a policy group, so a request may not use the default server selected manually in Home.
Best for: everyday use with rules you can review and traffic that needs to be routed by destination.
Proxy
RecommendedFor this first-connection check, use proxy routing to reduce interference from traffic-splitting rules and make it easier to compare the selected server with actual access. System, local network, and other relevant settings may still affect the result.
Best for: temporarily checking the default server and distinguishing server issues from rule issues.
Direct
Uses a direct route. A webpage loading in this mode does not show that the selected proxy server is working; Direct is more useful as a comparison to check whether your basic network connection is working.
Best for: comparing with the proxy route to check direct access on your current network.
Connectivity Test: what the results tell you
Connectivity Test helps you check whether a test target is reachable or responding under the current test method. A numeric result means that the test received a response. It is not a bandwidth test and does not verify every app, domain, or transport method. Different test methods cover different parts of the route. A basic port-reachability check in particular cannot confirm successful proxy authentication or a complete webpage request.
Results can differ when the test target, test method, and real-world destination are not the same. A webpage may also depend on multiple domains, DNS resolution, a TLS handshake, and resource requests. Use a test to narrow down the issue, then verify with an actual visit. Do not judge whether a server suits your needs based on a number alone.
These ports distinguish webpage connections from name resolution. They are not instructions to change your server port to these numbers, nor do they mean Connectivity Test always checks them. Use the port in your own configuration. If a page will not load, first determine whether the test received no response, name resolution failed, or only one site is affected. Then decide which layer to check.
- Blank result: Make sure you started the test and waited for it to finish. A blank result alone cannot tell you whether the test has not started, is still running, or produced nothing displayable.
- Timeout: The test did not receive the required response within the allotted time. The cause could be the local network, server, test target, or test method.
- Numeric result, but access fails: Check the connection status, Global Routing, DNS, and the actual request. Do not skip authentication or rule troubleshooting based on the test result.
Blank results or timeouts: follow the appropriate troubleshooting path
Keep the same device, server, and test method, then check whether the issue happens again. A single timeout may be caused by a temporary network fluctuation. Repeating tests while changing several settings at once makes results harder to compare. Use the two paths below to distinguish “no clear result” from “a confirmed failure.”
Choose a troubleshooting path based on the result
Blank result
- Make sure SERVER contains an actual server entry, and check the selection indicator to its left.
- Run Connectivity Test once more, then stay on Home while the result updates.
- Check whether you are viewing the result for the selected server or an entry with a test that has not finished.
- If no result appears, check the test method and target settings, then check your network.
Repeated timeouts
- Turn off the connection and check your network. Rule out a Wi-Fi sign-in requirement or an unavailable network.
- Check the server address, port, authentication, and TLS-related fields. Do not guess at values.
- Keep the configuration unchanged and compare Wi-Fi with cellular data. Keep an eye on cellular data usage.
- Ask your existing provider to confirm the server status and share a description of the issue with sensitive details removed.
If the same entry fails only on one network, check that network path first. If it fails on multiple networks, focus on the server status, settings, and test target.
If you already have another server confirmed to be working, switch only the default server to compare results; you do not need to delete the entire subscription. If just one entry fails, focus on its settings and remote status. If all entries fail, consider the local network, test settings, and service status rather than assuming every configuration is invalid.
Test succeeds but the page will not load: check rules and DNS
First make sure the connection switch is still on, then check Home → Global Routing. If you use Config, open Config and check which configuration is active. A configuration appearing in the list does not mean it is active, and the policy matched by a rule may not point to the default server selected in Home.
- Check rule order: DOMAIN-SUFFIX matches domain suffixes, IP-CIDR matches address ranges, GEOIP uses the geographic location associated with an IP address, and FINAL is the fallback. Check which policy the destination actually matches; seeing the domain somewhere in the rules is not enough.
- Compare routing modes: Keep the server unchanged, temporarily switch from Config to Proxy, and try the request again. If the result changes, focus on rule matching and policy selection. Restore your original setting when finished.
- Check for a site-specific issue: If one site fails while other pages work, check the site’s status and related domains. Do not rebuild the entire connection configuration right away.
- Check DNS: Server addresses that use a domain name also need to be resolved. An unreachable custom DNS server or incorrect DNS settings can prevent a connection or webpage from getting past name resolution.
Do not test an HTTPS page by substituting a random public IP for its domain name. Many sites rely on the correct domain for TLS and virtual host selection, so an error when entering the IP directly does not prove DNS is the cause. Retry the full address you normally use and check the connection details available in the app.
Verify the connection: save a reproducible result
A successful first connection involves three checks: the expected server is selected, the system connection status is as expected, and the intended destination is accessible. Connectivity Test is supporting evidence, not a substitute for the final check. Restore your usual Config or Scene and test a frequently used destination again so temporary troubleshooting settings do not become your final configuration by mistake.
- Record the environment: Note whether you are on Wi-Fi or cellular, the server entry name, the Global Routing selection, and whether On Demand is enabled.
- Record what happened: Note whether the result was blank, timed out, or showed a response despite access failing. Include whether all destinations failed or only some pages.
- Protect your privacy: When contacting your provider, share error details with sensitive information removed. Do not send a full subscription URL, Password, UUID, or a QR code containing these details.
- Choose the next step: For server settings, review the entry in its edit screen; for subscription content, check for updates; for routing issues, return to Config; for automatic connection issues, check Settings → On Demand.
Shadowrocket is primarily for iPhone and iPad. Check the App Store page for system requirements. When obtaining the app, verify the developer, Shadow Launch Technology Limited, and app ID 932747118. If the app is already installed, you can continue troubleshooting the connection without buying it again just because a test timed out once.