Shadowrocket
Import and Connection Guide

STEP 01 / IMPORT

Add a Server / Import an Existing Subscription

First, identify what kind of details you have, then choose the right way to import them. A subscription URL usually retrieves a refreshable list of servers. A single share link describes one server. Manual details consist of fields such as server address, port, protocol, and authentication. These are different types of information; don’t paste a URL into an arbitrary field just because it starts with a familiar format. If you’re unsure what you have, check the original instructions instead of trying different protocols at random.

Import an Existing Subscription with Subscribe

1. Open Shadowrocket, tap the plus button in the upper-right corner of Home, and open Add Server. Open Type, choose Subscribe, and enter your own subscription URL.
2. Give the subscription a name you’ll recognize. Check that the URL is complete and has no missing characters, leading or trailing spaces, or line breaks introduced when copying. Subscription URLs may contain authentication details, so paste the entire URL and don’t remove anything after the question mark.
3. Save and return to Home. Wait for the subscription to load. You should see a subscription group and its servers in the list. If the subscription name appears but there are no servers, check for a fetch error before turning on the connection switch.

The Config page is for managing configuration files, which may contain rules, DNS settings, and policies. A configuration file is not the same as a server subscription. When adding information for the first time, make sure you know which type you’re adding. If you only have a server subscription, import it using Add Server → Subscribe above; don’t treat it as a rule configuration file. If you already have a complete configuration, check separately that it’s enabled and that the server list has loaded.

Enter Server Details with Add Server

If you have manual server details, open Add Server and set Type to the protocol specified in your information. Then enter the address, port, and authentication details. The form fields vary by protocol; encryption, transport, TLS, and server name settings must match the original details. Don’t assume a field can be left blank just because it has a default value, and don’t guess at fields you don’t understand. Save, return to Home, and check that the server appears with the expected name.

For a single share link, copy it and look for an import prompt in the app. Before confirming, check the parsed protocol and address. For a QR code, use Scan QR Code. QR codes may contain sensitive connection details, so don’t display them publicly. Whatever import method you use, it should produce a selectable server entry. Seeing a name means the import may have completed; it does not confirm that the details are correct or the service is working.

Once the list is ready, choose how traffic will be handled before connecting.

STEP 02 / GLOBAL ROUTING

Three Global Routing Modes

Open Global Routing in Home and choose Config, Proxy, or Direct. This setting controls overall routing behavior, not the server protocol, and it won’t fix incorrect connection details. For your first test, note which mode you selected. Otherwise, even if a webpage loads, you won’t know whether the proxy connection worked or the traffic took a direct route.

If you just want to check whether the server you imported works, start with Proxy and select the server you want to test in Home. This temporarily reduces the variables introduced by rule matching. After the test, choose the mode you plan to use day to day. A webpage loading in Proxy mode does not mean your configuration rules are correct; these are separate things to verify.

Before using Config, open Config and confirm that the configuration you intend to use is active—not just saved in the list. Rules are usually matched in order, and the match determines which policy handles a connection. Importing a server does not automatically create routing rules for your needs, so you can’t infer that a website will use the proxy just from the server name. When you’re starting out, there’s no need to change rules, DNS, and policy groups all at once. First establish a connection path you can test.

Direct can help you compare basic access with the connection switch on and off, but it doesn’t prove that a server works. If a webpage is already accessible over a direct connection, opening it after switching modes doesn’t show that the proxy is working. Return to Home and check the current Global Routing mode and selected server. Confirm both before authorizing the connection.

Check before continuing: Know whether the current mode is Config, Proxy, or Direct. In Config mode, know which configuration is active; in Proxy mode, know which server is selected.

STEP 03 / CONNECT

Turn On the Switch and Authorize the Connection

Return to Home, select a server whose details you’ve checked, and turn on the connection switch at the top. The first time you connect, the system may ask to let Shadowrocket add a VPN configuration. Confirm that the prompt follows an action you just initiated, then follow the system instructions to authorize it. You may need to authenticate on your device. This allows the app to create the relevant network connection configuration on your device; it is not a purchase prompt and does not verify your server details.

1. Check what’s selected before connecting. Expanding a subscription group does not necessarily select an individual server. If you need to compare servers, test them one at a time and note each name.
2. After turning on the connection switch, follow any system authorization prompts. If you previously canceled authorization, try connecting again in the app and watch for the prompt. You don’t need to delete the app first.
3. After authorization, return to Home and check that the switch stays on and the app shows a connection status. Don’t keep toggling the switch while the status is still settling.

A system VPN status means the corresponding connection configuration is in use. It does not guarantee that the remote server is reachable or that every website will load. Some incorrect settings only become apparent when a request is made. The goal at this step is simply to confirm that the app can establish a local connection state. Next, use both test results and real-world access to verify the connection; don’t stop at the status indicator.

If the switch turns off right away, first check whether you missed or canceled a system prompt, then see if another VPN configuration is already in use on the device. Devices managed by a school or workplace may also have restrictions; follow the device management requirements and don’t remove system configurations you don’t recognize. The layout may differ between iPad and iPhone depending on screen size. Find the controls using Home, the selected server, and the connection switch rather than tapping a fixed spot from memory.

For your first test, keep the current network unchanged and leave On Demand disabled or unchanged for now. On-demand connections can affect automatic reconnection, making it easy to mistake an automatic reconnect for a failed switch operation. If On Demand is already configured, note its status first. If the connection turns back on automatically after testing, check this setting instead of repeatedly turning off the same switch.

Check before continuing: You authorized the connection yourself, and the switch is in the expected state. You haven’t treated the system VPN indicator as the only proof that the remote connection works.

STEP 04 / VALIDATE

Connectivity Test and Real-World Access

Once connected, run Connectivity Test and review the result for the selected server. Treat it as a diagnostic clue: a timeout is a reason to check the server and your basic network first, while a response means the test received a result. The test target and method aren’t identical to a real webpage request. A reported time does not guarantee that webpages will load or verify every protocol feature. Don’t judge whether a connection suits your needs by the number alone.

Next, open a browser and visit a familiar website you’re authorized to access. Confirm that the page actually loads, rather than showing old content from the browser cache. Refresh the page and try another site; a problem with a single site could otherwise be mistaken for a failed connection. Note your network, selected server, and Global Routing mode so you can make a useful comparison later.

1. Check your basic network. If it’s safe to interrupt the connection, turn off Shadowrocket and confirm that a webpage you normally access directly still loads. If your basic connection is having trouble, first check Wi-Fi sign-in, signal strength, or cellular data permissions.
2. Check the proxy route. Return to the app, confirm the selected server and Proxy mode, reconnect, and try the destination again. If you have a trusted way to check your exit details, use that as additional evidence. A webpage loading by itself isn’t enough to prove which route it took.
3. Check the rules route. If you need rule-based routing, switch to Config, retry the request, and check the policy used in any connection logs available in the app. Keep the test conditions the same before and after switching so a network change doesn’t skew the result.

If Proxy works but Config doesn’t, check the active configuration and matching policy before replacing the server. If the same webpage fails in every mode, consider the site itself, your basic network, and DNS. Existing browser connections may also affect what you see after switching modes; close the relevant tabs and retry if needed. Change one condition at a time to identify what made a difference.

After testing, leave Global Routing in the mode you actually plan to use. Proxy may be useful for testing without being the right long-term default. Config is useful only when its rules behave as expected. Before everyday use, check your usual apps too; a webpage test can’t cover every app’s connection requirements. For more on rule keywords and DNS, see the glossary. For persistent issues, see the troubleshooting guide.

Check before continuing: You’ve reviewed both the test result and real webpage loading, and you know which mode is active. If using Config, you’ve confirmed that it behaves as expected, not just that the switch is on.

STEP 05 / CHECKPOINTS

Troubleshoot by Stage: Check One Thing at a Time

When something goes wrong, start with the last check you completed. Was the information never imported, did the switch fail to stay on, did the test time out, or did the test return a result while webpages still wouldn’t load? Each points to a different stage. Reinstalling right away or changing many settings at once can erase the original state and make the cause harder to identify. Keep your existing details and configuration names, narrow down the issue in the order below, and then decide whether you need a deeper diagnosis.

No Servers After Import: Check the Information Type and Fetch Result

Check whether you pasted a subscription URL or a configuration file URL, and whether you accidentally used a webpage with instructions instead of a subscription. Make sure the original URL is complete, has no extra spaces, and that the app hasn’t reported a fetch error. A subscription URL opening in a browser doesn’t guarantee that it returns an importable server list. Check the validity period and access requirements of your existing subscription with your original provider. Don’t post a complete URL, QR code, or authentication details in a public discussion. If you already have a server list, keep it while troubleshooting rather than repeatedly deleting the subscription.

The Switch Won’t Stay On: Check System Authorization

Return to step three and check whether you canceled the system prompt to add a VPN configuration, or whether another VPN configuration is already in use on the device. Follow management requirements for managed devices. If the connection turns back on after you turn it off, check whether On Demand is enabled and distinguish automatic connection behavior from a problem with the manual switch. At this stage, you haven’t confirmed that a request reached the server. Check the device’s local status first; don’t start by changing DNS.

Connectivity Test Times Out: Check the Server and Network

First confirm that you selected the server you intended to test. Then check that its address, port, protocol, and authentication details match the original information. For a server imported from a subscription, you can update the subscription while keeping your existing information and check whether anything changed. Next, compare with another server you already have, or—if possible—test over Wi-Fi and cellular data. Change only one condition at a time. A timeout alone doesn’t identify which setting is wrong, and a single result can’t establish the service’s status.

Test Returns a Result but Webpages Won’t Load: Check DNS, Rules, and the Website

Try another working website to see whether the issue affects one site or more generally, then compare Proxy and Config. If the problem occurs only in Config, check the active configuration and matching policy. If multiple destinations fail to resolve, review any DNS settings you’ve changed, note their original values, and adjust one thing at a time. Don’t overwrite your current setup with a complete configuration from an unknown source; that would change several variables at once. A successful test only confirms that the test completed; webpage requests can still fail at domain resolution, transport, or the site response stage.

If you still can’t identify the issue, make a record without sensitive details: device type, current network, selected mode, whether authorization was completed, the exact error message, and the individual checks you’ve tried. Don’t include server passwords, complete subscription URLs, or authentication details. Then follow the symptoms in the troubleshooting guide, or look for a matching explanation in the FAQ. There’s no need to redo every setting.