Shadowrocket Setup Guide
Import a Subscription and Verify Your Connection

STEP 01 / IMPORT

Add Server and Subscribe Import

Open Shadowrocket and go to Home. First identify what information you have: a subscription link usually fetches and updates a group of servers, while details for a single server include its protocol, address, port, and authentication settings. These use different setup paths. A long-looking URL doesn’t necessarily mean it’s a Subscribe link. If you’re unsure what type of information you have, check the provider’s instructions first.

Have a subscription link? Choose Subscribe

In Home, tap the plus button in the upper-right corner to open Add Server. Open Type and choose Subscribe. Paste your complete subscription link into URL, enter a name you’ll recognize, and save. Check the beginning, end, and query parameters after pasting. Remove any quotation marks, spaces, or line breaks added by a messaging app, but don’t delete the end of the link. Subscription URLs may contain access credentials; use them only in the app on your own device.

After saving, return to Home and wait for the first fetch to finish, or update the subscription. Server entries should appear under the subscription group to confirm that the app retrieved and recognized the contents. Seeing only a subscription name doesn’t mean the servers imported successfully. If the list is empty, check the link and update result before trying to connect.

https://example.com/sub?token=xxxx

This example illustrates the URL structure only; it is not a working subscription. Paste your own link into the app, not the example.

Have server details? Enter them for the specified protocol

If you have details for a single server, use the plus button in Home to open Add Server, but choose the specified protocol under Type—not Subscribe. Then check Address, Port, and the authentication fields required by that protocol. Protocols such as Shadowsocks, VMess, VLESS, and Trojan use different fields. Don’t copy settings from another protocol’s form or guess the encryption method or transport parameters.

Enter TLS, server name, and transport settings as provided. The address and the name used for certificate validation may be different, so don’t combine them arbitrarily. If you import your own server using a share link or Scan QR Code, open the entry and check its key fields. Saving only confirms that the entry format was accepted; it doesn’t guarantee that the remote server is available.

Return to Home, tap the server you want to use, and confirm that the selection indicator is on the intended entry. For your first test, use one clearly identified entry rather than switching between several servers and trying to interpret the results. Import is complete when the list contains a server entry, its settings are viewable, and the selected server is clear. Next, choose how those servers will be used for the connection.

STEP 02 / GLOBAL ROUTING

The Three Global Routing Modes

Open Global Routing in Home and choose a mode for your test. This controls how traffic is handled; it’s separate from which server is selected. This guide uses the interface labels Config, Proxy, and Direct.

After importing a server, if you want to check whether it can handle a real request, start with Proxy. After one test, switch to Config if needed. This is a troubleshooting sequence, not a recommendation to leave Proxy enabled for everyday use. After switching modes, return to Home and check the displayed value so you know the change took effect.

Before using Config, open the Config page and check which configuration file is selected. A subscription’s server list and the rules file in Config serve different purposes: the former provides server entries; the latter determines which rules requests match and which policies apply. Updating a subscription doesn’t update your rules, and importing servers doesn’t select a rules configuration. Before using your own configuration, keep a copy of the original and confirm that its referenced policies point to the intended server or policy group.

Don’t copy a complete set of rules you don’t understand just to get a first connection. Verify the route for a single server first, then work on traffic routing. For definitions of keywords such as DOMAIN-SUFFIX, PROXY, and DIRECT, see the glossary. This guide doesn’t cover rule priority or complex policy combinations. Once you’ve chosen a mode, continue with system connection authorization.

STEP 03 / CONNECT

Turn on the connection and authorize it in iOS

Return to Home. Check the selected server, the current Global Routing mode, and that your Wi-Fi or cellular connection works. Then turn on the connection switch at the top. The first time you connect, iOS may ask to let Shadowrocket add a VPN configuration. This authorization is required to establish a system network connection; it doesn’t update a subscription or require you to buy the app again. Confirm the app name, then follow the system prompts and complete device authentication.

After authorization, return to Shadowrocket and check that the switch stays on. The VPN status in iOS can also indicate that a system connection is established, but it doesn’t prove that every destination is reachable or that every request passes through the selected server. Continue with the next step to test real requests—don’t stop at seeing the switch on.

If you previously denied system authorization or the switch turns off shortly after you turn it on, don’t delete the server right away. Try connecting again and check for an authorization prompt. Then check the VPN configuration status in system settings and whether another VPN connection is active. Disconnect other VPNs while troubleshooting to avoid switching between multiple network configurations. If your device is managed by an organization, its policies may restrict adding configurations; check with your device administrator about what’s allowed.

If a manual connection isn’t stable yet, don’t configure On Demand. It triggers connections under specified conditions; it won’t fix an incorrect subscription URL or server settings. First confirm that manual connections turn on and off as expected, then set up automatic triggers separately. Follow the same sequence on iPad. The layout may vary by device and app version; use the English labels in the current app to find settings.

STEP 04 / VERIFY

Connectivity Test and Real-World Verification

Once connected, run Connectivity Test for the selected server and check the result. The test provides clues about connectivity, not a guarantee that everything is reachable. Its target and protocol route may differ from those used by real website requests, so one successful test doesn’t mean every request will work. A single timeout doesn’t prove that the server is permanently unavailable. Keep the current server and mode unchanged while testing to avoid adding variables.

Next, open a browser and visit a familiar site you’re authorized to access. Reload the page and check that it completes a normal request. Don’t rely only on a page that was already open; cached content can hide the connection status. To compare results, record how the same destination behaves when disconnected, in Proxy, and in Config. Send a new request after each change, and don’t switch networks and servers at the same time.

A Site Loads—But Which Route Did It Use?

A site loading doesn’t mean its traffic went through a proxy. In Config mode, some requests may match DIRECT by design. To check how traffic is routed, look at the relevant request log in the app and consider the destination domain, matched rule, and resulting policy. Traffic changes on the Data page can provide additional context, but background activity also uses data, so don’t attribute a change in the numbers to a specific page visit.

If Proxy works but Config doesn’t, first check the matching rules and policy targets in the active configuration. If Direct works but Proxy doesn’t, check the selected server and its remote connection route. If neither works, first confirm that your local network and the destination are working. This comparison helps narrow down the issue, but you still need to review the specific error details.

Define success in concrete terms: the selected server’s test has an explainable result, the destination request completes, and traffic that should be routed follows the expected path. When you’re done, switch back to the Global Routing mode you need for everyday use and test the same destination again. Note the working server and configuration names so you have a clear baseline if issues arise later.

STEP 05 / CHECKPOINTS

Troubleshoot by the Step Where It Fails

When something goes wrong, start with the earliest step that didn’t complete. If the server list is empty, fix the import first. If the switch won’t stay on, resolve the system connection issue. If only one destination fails, check its rules and DNS. Don’t treat every issue as a reason to reinstall the app: reinstalling may erase local configurations and won’t fix an expired remote link.

No Servers Appear After Saving Subscribe

Reopen the subscription settings and check that the URL is complete and contains no extra spaces, line breaks, or punctuation from a message. Make sure you pasted a subscription URL, not an account webpage URL. Update it once and check the result. If the contents are empty, can’t be recognized, or the link has expired, ask your provider to confirm its status and supported format. Don’t post the complete subscription URL in a public forum; it may contain personal access credentials.

If the subscription updated successfully before but suddenly fails, first confirm that regular network access works, then check whether the same subscription can be fetched on your current network. Don’t keep adding duplicate subscriptions in the hope that one will work; duplicates make it harder to identify the selected entry later. Updating a subscription is different from updating the app: the former refreshes server details, while the latter updates the client through the App Store.

The Switch Is On, but the Server Test Times Out

First check that the server address, port, and authentication settings match the original details. Then check any TLS or transport settings required by the protocol. Try another local network that you can use, keeping the server unchanged so you can compare results. If it works on the other network, focus on the original network route. If it fails on multiple networks, ask your server administrator to check the remote server instead of changing ports arbitrarily or disabling required validation.

If only one imported entry fails, compare it with another entry you already have in the same subscription, and record the result before and after switching. Change only the server; don’t change Config and DNS at the same time. If the test occasionally succeeds but real requests still fail, check the specific destination and error logs. Don’t keep toggling the connection based only on the test result.

Proxy Works, but Some Destinations Fail in Config

Confirm that the intended file is selected on the Config page, then check which rule matched the failed request. A rule may specify DIRECT or REJECT, or point to a policy group that isn’t configured correctly. A working server doesn’t mean every rule uses it. Find the relevant rule before making changes, and keep the original file so you don’t obscure the cause by replacing everything.

If domain access is unreliable while other connections seem normal, include DNS in your checks, but don’t change multiple DNS settings at once. Record the current setup and compare one setting at a time after confirming what the original configuration does. Don’t dismiss certificate warnings; check the destination name, device time, and relevant connection settings. For a full workflow covering DNS, TLS, and rules, see the troubleshooting guide.

Issues After Switching Networks or Returning to the App

Disconnect manually and reconnect, confirm the new network works, then check that the server and Global Routing mode still match the combination that worked before. If you’ve set up On Demand, note its trigger conditions and temporarily disable automatic triggers if needed to test a manual connection. Don’t add automation until the basic connection is stable, or it will be harder to tell whether the issue is with the trigger conditions or the server connection.

By the end of this guide, you should be able to find your server in Home, explain the current mode, turn the connection on and off manually, and verify the result with a real request. For everyday use, update your subscription as needed, keep a working configuration, and repeat the checks after making changes. For purchase and authorization questions, see the FAQ. Look up unfamiliar interface labels in the glossary, and follow the troubleshooting guide for persistent issues.