Shadowrocket Complete User Guide

Start by confirming where to get the app

Shadowrocket is a paid client for Apple platforms, with iPhone and iPad as the primary devices covered in this guide. Get it from its App Store product page. Compatibility with Mac, Apple TV, and Apple Vision is also listed on that page. Don’t infer system requirements or purchase eligibility from a device name: check the App Store listing for current requirements, supported devices, and price. Before buying, confirm which App Store storefront you’re using and whether the product page there shows the app as available for purchase. Search results are just a way to find the listing; verify the details on the product page.

Check three details to identify the app: its name is Shadowrocket, its developer is Shadow Launch Technology Limited, and the app ID in the product URL is 932747118. The icon should match the App Store listing, but don’t rely on the icon alone; search results with similar names or artwork may lead to different products. Open the product page, read the full developer name, and check the URL for id932747118. Taken together, these details are more reliable than remembering a translated nickname. For step-by-step checks and device information, see the App Store verification guide.

Separate the app’s price from connection details

The purchase is for the Shadowrocket client itself. The US storefront has previously listed it for a one-time purchase of about $2.99; check the current App Store listing for the actual price, currency, and purchase terms. A one-time app purchase does not include a connectivity plan: buying the app gives you access to it but does not provide server details. The import steps assume you already have your own subscription or server settings. If you don’t have those details yet, you can still read about routing and the interface, but an empty SERVER list does not mean the purchase failed.

After purchasing on an iPhone or iPad, return to the App Store product page, tap the install button, and wait for the system to finish. If the button offers to redownload the app, first check the Apple Account used for the purchase, then review your App Store purchases. The presence or absence of an icon on the Home Screen alone does not confirm purchase history. When moving to a new device or reinstalling, remember that your purchase record and configurations you imported into the app are separate: redownloading the app does not necessarily restore your subscription, server labels, or custom rules. Before switching devices, keep a copy of the original information you’re entitled to use, then import it according to the new device’s current state.

Check these separately: whether you have the right product, whether you’ve obtained the app, and whether you have connection details ready. This prevents common misdiagnoses. For example, if the list is empty on Home, first check whether you’ve imported anything rather than buying the app again. If a website is unreachable after connecting, check the server, routing, and network instead of blaming the icon or store account. Once these basics are covered, move on to first launch and VPN configuration permissions.

Get to know the main areas of Home

When you first open Shadowrocket, check the current state on Home before changing settings. Home is where you start a connection: the connection switch and status text at the top show the current state; Global Routing determines how traffic is routed; the SERVER section lists and selects servers you’ve added; and Connectivity Test helps check the connection. Not Connected on first launch only means no connection is currently established. If SERVER has no selectable entries, import your details first. Layouts may vary with screen size, so look for the English interface labels.

Follow this order: check the status, confirm your details, choose a routing mode, then turn on the connection. This makes it clear which action triggered a system permission prompt, rather than confusing the permission request with importing a server or choosing rules. If you turn on the switch without selecting an available server, repeatedly granting permission won’t resolve the resulting connection failure. Note the status text before you begin; it will help you tell whether anything changed when you check again.

Understand the system permission prompt

The first time you try to connect on an iPhone or iPad, the system may ask permission for Shadowrocket to add a VPN configuration. This is the system confirming a network configuration change; it does not mean you’re connected to a server. Read the app name and system message, make sure the prompt matches the action you just took, and follow the system instructions. Your device may also ask for your passcode or biometric authentication. After granting permission, return to the app and check the connection switch, selected SERVER, Global Routing, and test results. A VPN indicator in the status bar only shows that the network configuration is active; it does not confirm that every destination is reachable as expected.

If you dismiss the prompt, return to Home, check the switch, and start the connection again from the app. Don’t rapidly toggle the switch repeatedly. If you already granted permission but see another permission-related prompt when connecting, check whether your device currently allows VPN setting changes and whether any device management restrictions apply. The available options depend on your device settings. Don’t repeatedly remove the system configuration to troubleshoot an ordinary server parameter error. First identify whether the error occurs before permission is granted, after permission but before connecting, or after connection when access is affected; each case calls for different checks.

Use the same troubleshooting sequence on iPad

The wider iPad layout may arrange Home lists and controls differently from the iPhone layout, but the permission works the same way: the system confirms a VPN configuration on that device, and you still need to import SERVER details yourself. When setting up either device for the first time, check its system permission and selected items in the app separately. Don’t assume granting permission on one device also grants it on another. Check purchase history through the App Store for the same Apple Account, but check connection details in each device’s actual server list.

After granting permission, keep the connection off while you import your existing details and check the fields. If you can’t find a switch, list, or test option, see First launch and the Home screen. At this stage, the most useful things to record are whether the app opens normally, whether Home appears, whether system permission was granted, and whether SERVER is still empty—not whether a webpage opens. These observations help narrow down import issues in the next step.

Identify what kind of connection details you have

Server entries in Shadowrocket can be added manually, through a single share link, or from a subscription. First identify what you already have: server address, port, protocol, and authentication fields are entered individually; a share link that begins with a protocol prefix usually represents one server entry; and a URL from a provider that retrieves a list of entries periodically should be handled through Subscribe. A subscription URL and a server address are not interchangeable. Pasting a subscription URL into the server address field, or using a single share link as a subscription update URL, can lead to confusing errors.

To add a server manually, find the add option on Home and open Add Server. Choose the protocol that matches your existing details, then fill in each field. Enter a hostname or IP address, use the specified port, and provide authentication details as required by that protocol. A label helps you identify the entry but is not a connection parameter. When pasting, check for spaces at either end, the numeric port, case-sensitive fields, and easily confused characters. After saving, return to SERVER, confirm the new entry appears, and check which one is selected before connecting. The fields currently shown in Add Server determine what the app supports.

Check required parameters by protocol

Use this table to find what to check, not as a generic fill-in template. Even entries using the same protocol may differ in transport, security, and domain parameters; don’t replace supplied values from memory. In WireGuard, PrivateKey is local identity information, while PublicKey and Endpoint serve different purposes. See WireGuard parameter guide for details. Never expose full authentication details on public pages, in screenshots, or in support messages. Compare fields against your original information privately.

Import and update an existing subscription

If you already have a Subscribe URL, use the corresponding subscription option in the app, paste the full URL, and save it. Then run the update action provided by the app. The sample URL https://example.com/sub?token=xxxx illustrates the URL format only; it won’t connect. After a successful update, return to SERVER to check whether entries were added and whether the selected entry is still the one you need. Importing successfully and having a usable server are two different things: the first means the app retrieved and parsed the details; the second still requires connection and destination testing. For the difference between single links such as ss://, vmess://, vless://, and trojan:// and subscription URLs, see Share links and subscription URLs.

If an update fails, first check whether your device can access the subscription URL, whether the URL was truncated, and whether the original details are still valid. If the update completes but the list is empty, check the subscription contents and whether they use a format the app recognizes. Don’t paste a private URL into a public testing website. Scan QR Code can import valid details you own, but check the fields and source afterward. Once details appear in SERVER, choose Global Routing next; an entry appearing in the list alone doesn’t mean routing is configured correctly.

Choose a mode before checking rule matches

Global Routing determines how traffic is handled. Config, Proxy, and Direct in the interface mean routing according to the configuration, always using the selected proxy route, or always using a direct route. These descriptions explain behavior; look for the English labels when navigating the app. Switching modes usually doesn’t require re-entering server details, but it changes how you interpret connection results. For example, a destination may match DIRECT in Config but use the selected server in Proxy. During troubleshooting, note the current mode first; if the switch is on but traffic isn’t going through a server, the routing choice may explain why.

In Config, the most important concepts are rule order and the fallback policy. Rules typically go from specific matches to more general ones: DOMAIN matches an exact domain, DOMAIN-SUFFIX matches a domain suffix, and DOMAIN-KEYWORD matches a keyword. GEOIP, IP-CIDR, and IP-CIDR6 match address ranges. PROXY, DIRECT, and REJECT on the right side of a rule are actions, not protocol names. PROXY relies on an available selected server; DIRECT connects using the device’s current network; REJECT blocks matching requests. USER-AGENT is another visible rule keyword. Check the app’s actual matching behavior to see whether it applies to a particular request.

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,ads,REJECT
GEOIP,CN,DIRECT
FINAL,PROXY

Here, example.com is a sample domain; the snippet illustrates how rules relate and is not a complete configuration. The first line routes that domain and its subdomains through PROXY; the second shows a keyword match followed by REJECT; the third combines GEOIP with DIRECT; requests not handled by earlier rules are then routed according to FINAL. With FINAL,DIRECT at the end, unmatched requests use the direct route. Before editing, save your current Config and note the destination and expected behavior. Otherwise, changing several rules at once makes it hard to tell which change affected the result.

Narrow down issues by comparing all three modes

If a destination behaves unexpectedly in Config, compare it with Proxy and Direct within a clearly defined test. If it works in Proxy but not Config, check the matching rule and FINAL first. If it also fails in Proxy, check the selected server’s settings, authentication, network connectivity, and the destination itself. If it works in Direct but not Config, that doesn’t mean you should permanently switch to Direct; find the rule matching the request. Comparing the three modes is a diagnostic method, not a universal recommendation for every network. When testing is complete, restore the mode you need and recheck your usual destinations.

A configuration file may include settings beyond rules, such as DNS options. The result you observe for a request can depend on domain resolution, IP rules, routing mode, and the destination service. Don’t treat a single result from a test website as proof that the entire Config is correct. See the glossary for terminology and the DNS settings guide for DNS configuration details.

Break connection testing into observable stages

Before connecting, select one of your own servers in SERVER and confirm that Global Routing is set to the mode you chose. Then use the switch on Home. Check each step in order: whether system permission has been granted, whether the app status changes from Not Connected, whether the device shows the corresponding network status, whether Connectivity Test returns a result, and whether the destination is actually reachable as expected. These checks are not interchangeable. An enabled switch doesn’t guarantee successful server authentication, and a successful test to one address doesn’t mean all domains match the same rules.

Connectivity Test is useful for quick comparisons, but results depend on the test destination, current network, and routing settings. If a test fails, first check that the device itself is online, then make sure the selected server is the one you intended to test—especially after updating a Subscribe. Next, confirm whether the current mode is Config, Proxy, or Direct, then repeat the test against the same destination. Avoid changing the network and destination each time. Recording the mode, selected entry, test destination, and result makes troubleshooting more effective than simply noting “can’t connect.”

Troubleshoot based on what you observe

If the connection won’t start, check system VPN configuration permission and the status on Home before changing rules. If the app shows a connection but a destination is unreachable, first check whether a REJECT or DIRECT rule in Config handles that destination, then check the server used by PROXY. If only a few domains fail, focus on the relevant DOMAIN, DOMAIN-SUFFIX, DOMAIN-KEYWORD, and DNS settings. If all destinations fail, check the device’s basic connectivity, server fields, authentication, and selected entry first. The destination website itself may also be temporarily unavailable, so cross-check with more than one destination you know.

When you need to verify the settings for an existing server, compare them with the original details you received. Don’t randomly change the protocol, port, or security settings. If the address resolves but the connection still fails, check authentication and transport parameters. A subscription that updates successfully while its server remains unusable only confirms that the details were retrieved; the server still needs to be tested. Conversely, if a manually added server works but a subscription update fails, focus on whether the subscription URL is complete and reachable. Troubleshoot configuration retrieval, connection setup, and destination access as separate stages to avoid going in circles.

Check ongoing behavior after the connection is stable

After you first reach a destination successfully, test a few common scenarios: switch the device between two known networks, lock and unlock it, and reselect the entry after updating a subscription. A network change can affect DNS, the available route, or whether a connection is maintained, so one successful test doesn’t guarantee every situation will work. If you use On Demand, understand its triggers before including it in your tests; otherwise, automatic connection behavior may affect the results of manual switch tests. For trade-offs involving On Demand and background use, see On Demand connections and battery troubleshooting.

A successful check isn’t just an illuminated status indicator. Destinations expected to use PROXY should be reachable as expected, destinations expected to use DIRECT should still work, and the results should remain consistent when you switch back to your everyday Config. Only then can you interpret the numbers in Data in context. If the issue doesn’t fit these cases, revisit the quick-start steps and check each input, selection, and switch in order rather than making more changes without knowing the current state.

First define what the statistics cover

Data shows traffic information reported within the app. Before opening it, note the connection state, selected server, and Global Routing mode, then review the counters in that context. Some requests may use DIRECT while others may be REJECTed. Other activity on the device, background refreshes, and earlier connections may also mean the displayed figures cover more than the page you just opened. Don’t attribute a total in Data directly to a specific website, or assume the app’s statistics use exactly the same measurement as your carrier’s bill.

Before comparing figures, define the start and end of your observation. Note the current value, visit a destination you know, then return to Data and check for a change. If you switch networks, servers, or routing modes in between, record that too. Different views may group information by connection, entry, or time period, so read the page labels before comparing. The filters and reset options available depend on what the current app interface shows; don’t assume your screen has the same buttons as someone else’s screenshot.

Use statistics as a troubleshooting aid, not a substitute for connectivity tests

An increase in traffic means there was activity in the scope being observed; it doesn’t prove that the destination loaded correctly or that every request used PROXY. If Data doesn’t change immediately, check whether the connection is still active, whether a request was actually made, and whether the selected time range covers the test. Then recheck Home and Connectivity Test. In Config mode, different requests from the same app may match different rules, so a cumulative total alone can’t show the route taken by each request. To assess a specific destination, consider its matching rules, connection status, and actual behavior together.

If traffic appears unusually high, run a small, repeatable test instead of turning everything off at once. Note the starting value, pause any large transfers you’re running, then observe for a while using your usual network setup. If traffic continues to rise only in the background, compare it with the system’s battery and network usage information, and check whether settings such as On Demand affect connection timing. The two sets of statistics may cover different activity or use different measurement methods, so a difference alone doesn’t indicate an app issue. Check the units, time range, and whether background activity is included before changing settings.

Keep records you can review later

When asking your provider about connection details, share the network type, selected protocol, approximate time, and reproducible symptoms. Don’t include a full subscription URL, password, or key. Check Data screenshots for account information, server labels, or other personal details before sharing them. If you suspect a rule is sending traffic the wrong way, review the actions in Config rather than just resetting the statistics. Resetting changes the starting point for observation; it does not fix routing logic.

Data is best for answering: “Under these known conditions, did traffic change, and was the change broadly consistent with my actions?” It can’t, by itself, explain server authentication failures, identify the rule matching a domain, or confirm whether an App Store purchase succeeded. For the first two, revisit the connection and Global Routing sections; for purchase issues, see Restore previous purchases. Knowing what the tool can tell you makes its numbers useful troubleshooting clues rather than another source of confusion.

Keep a working baseline

Settings contains options that affect how the app behaves and how you connect, but you don’t need to change them all after your first successful connection. Record a working baseline: selected SERVER, Global Routing mode, current Config, and whether On Demand is enabled. Then change only the setting relevant to a specific issue, one at a time, and revisit the same test destination. If the results get worse, you’ll know what to revert instead of guessing after changing several switches. Available items may vary by device and screen; follow the labels and options shown in your app.

On Demand uses conditions you set to decide when to connect; it doesn’t make a server faster. If you want automatic connections on a particular network, first define the triggers and exceptions, then enable the relevant option. During testing, observe what happens when you join or leave a network and unlock the device again. If you’re troubleshooting a manual connection, keep the test conditions simple at first so automatic actions don’t override the switch operation you just made. For background activity or battery concerns, check the system’s battery usage information and consider how often connections occur. The fact that the app stays connected alone doesn’t establish the cause.

Keep DNS separate from routing rules

DNS resolves domain names into information needed for a connection; Global Routing and Config rules determine how requests are handled. These settings are related but not the same. System DNS, custom DNS, and DNS over HTTPS suit different situations. After changing DNS, retest the domain that had a problem and include a comparison destination unaffected by it. If the issue was caused by incorrect server authentication, changing DNS usually won’t fix it. If only particular domains are affected, check both resolution results and rule matches.

If you see items such as dns-server in Config, first confirm which configuration you’re editing and whether it is actually enabled after the change. Don’t treat a DNS address from a tutorial as a default that works on every network. Record the old value, change one item, save, test again, and check whether you need to refresh the relevant connection. For details on three DNS approaches and how to test them, see the DNS settings guide. If a Config came from details you already have, consider whether a later update could overwrite your local changes before editing it.

Account for differences between configurations and devices

The same connection details may behave differently on an iPhone and iPad because network conditions, permission status, selected Config, and local preferences must be checked separately. Import from Cloud JSON and similar options are useful only if you actually have data in the corresponding format; they are not substitutes for an ordinary subscription URL. After importing, check what was added before deciding whether to enable it. Avoid overwriting a working configuration with settings from an unknown source.

Before changing a setting, answer three questions: What behavior do you want to change? Which option could affect it directly? How will you verify the change worked? If you can’t answer these, keep the working baseline. Settings lets you fine-tune behavior as needed; it doesn’t mean every option should be set the same way. Use the glossary to look up interface labels and rule keywords, then test an actual destination using the steps in the connection section.

Keep app updates separate from connection detail updates

First, distinguish app updates from connection detail updates. Shadowrocket updates are handled through the App Store, where you can check app information, compatibility, and release notes. A Subscribe update makes the app retrieve configuration data again from a subscription URL you already have. They are not synchronized just because both are called “updates.” If a new server entry is missing, check the subscription update and SERVER first. If an app feature or interface differs from this guide, check the App Store listing and the app’s current labels. A changed server list doesn’t tell you which app version is installed, and updating the app doesn’t mean subscription details have been refreshed.

Before moving to a new device, check your App Store purchase history and make sure you can access the account used for the purchase. Then organize the subscription URLs, manual server details, personal Config changes, and useful labels you’re entitled to use. Keep private details somewhere secure under your control; don’t post a full URL or key in a public forum. After getting the app on the new device, recheck each step: permissions, import, selected server, Global Routing, and connection tests. Even when both devices use the same purchase account, check the actual entries and selected configuration in the app on each device. Purchase history does not confirm that app data is present.

Keep enough information to troubleshoot, but no more than necessary

A useful troubleshooting record includes the approximate time the issue began, whether you’re using an iPhone or iPad, network type, Home status before and after connecting, selected protocol and server label, Global Routing mode, test destination, and result. If the issue started after a change, note the setting you changed. Use labels only to identify entries; don’t record passwords, keys, or full subscription URLs. Reproduce the issue once, then change only one condition and test again. If the result changes, investigate that branch. Changing several things at once makes the next similar issue harder to diagnose.

Use a consistent sequence to narrow down an issue: Does the app open? Does SERVER contain the expected entry? Has system VPN configuration permission been granted? Does the connection status change? Does the selected server work in Proxy? Which rule handles the destination in Config? Does Data change during a known test? Each question corresponds to a stage covered earlier in this guide. If a subscription won’t update, there’s no need to start by changing DNS and every rule. If only one domain fails, you don’t need to reinstall the app first. Identify the stage where the problem occurs, then check its settings and edge cases.

Check regularly instead of resetting frequently

As part of routine maintenance, check the App Store product page, whether your saved original details are still valid, and whether common destinations behave as expected under your current Config. When your network environment changes, run a brief test before deciding whether to adjust On Demand or DNS. Domains, address ranges, and personal needs can change, so a rule that worked before may no longer be appropriate. Keep a recoverable copy of the previous configuration whenever you make changes. Clear lists, reset statistics, or reimport all details only when you have a clear reason and know what you’ve backed up—not as the default response to a failed test.

This guide doesn’t end with a “Done” button. It ends with a repeatable process: verify the app on the App Store, confirm permissions and existing details, choose a route in Global Routing, test the connection, use Data to observe traffic, and change Settings only for a clear reason. To repeat the short setup flow, return to the quick-start guide. For purchase and device eligibility, see the App Store app guide. Always check the App Store listing and the app’s current labels when locating settings described here.