Shadowrocket
Complete User Guide

Get Shadowrocket on the App Store and verify the listing

First, open the App Store listing verification page. Check the app name, developer, and app ID before purchasing. Shadowrocket is a paid, closed-source app for Apple platforms, available exclusively through the App Store. The steps below focus on iPhone and iPad. For compatibility, system requirements, and whether a purchase can be used across devices, follow the App Store listing; do not infer availability from a device name.

Check these three details before purchasing

On the product page, confirm that the name is Shadowrocket and the icon matches the official icon shown on this site, then scroll down to check the developer. It should be Shadow Launch Technology Limited. Search results may include similarly named apps, so do not rely on a nickname or ranking alone. The name helps identify the app; the developer and app ID help confirm the specific product.

Check the product link for id932747118. The number 932747118 is the app ID, not proof of purchase or the current version. Shared product links can also use it to identify the same app. If a link opens a different product, stop and return to the verification page to open the listing again. Do not substitute a similar icon, keywords in a description, or someone else's account of the listing for this check.

Confirm the purchase and device requirements

Check the current price near the purchase button, then complete the system purchase confirmation. The US price is about $2.99 as a one-time purchase; the actual price, taxes, and currency depend on the App Store listing. The purchase covers use of the client, not a server account. A one-time app purchase does not include a service plan: connecting still requires your own existing subscription or server details. This site explains how to use that information but does not provide connection services.

Check the Compatibility section to see whether your device and system are supported. System requirements are as listed on the App Store page; do not use system versions from an old guide to judge current compatibility. If the store cannot complete the purchase, check your account, payment method, and storefront availability first. This is a store transaction issue, unrelated to Address, Port, or routing rules in the app; changing server settings will not affect the purchase.

Keep recovery options in mind after installation

After installation, open Shadowrocket from the Home Screen and confirm that it launches normally before importing a configuration. Purchases are associated with your App Store account. If you change devices or reinstall the app, look for it in Purchased using the same account. Family Sharing eligibility, cross-device use, and specific recovery conditions depend on the App Store listing and what your account displays; a successful installation on one device does not guarantee availability on every device.

When restoring, distinguish purchase eligibility from app data. Your purchase history can help you download the client again, but it does not restore server lists, subscription URLs, rule changes, or private keys. Check each of these separately after reinstalling. If the app is restored but no configuration is present, an empty server list in Home is normal; it does not mean the purchase has failed. Configuration backup and migration are covered in the maintenance section.

First launch and VPN configuration permissions

When you first open Shadowrocket, locate Home, Config, Data, and Settings before importing or connecting. Home is mainly for viewing servers, selecting an entry, and controlling the connection; Config manages routing configurations; Data shows traffic and request records; Settings contains operational options. Layouts can vary by device, so identify controls by their English labels rather than relying on fixed screen positions.

Handle the system prompt when connecting for the first time

When you turn on the connection switch in Home, the system may ask to add a VPN configuration. Confirm that the prompt is for Shadowrocket, allow it through the system flow, and complete device authentication. This permission creates the network extension configuration needed to process traffic through the tunnel according to the current mode. It does not purchase connection access from a provider or confirm that the server details have passed remote verification.

If you denied the request, return to the app and try connecting again to see whether the authorization flow reappears. If you still cannot continue, look for VPN-related settings in system Settings and check for a corresponding configuration or management restriction. The exact system settings path can vary, so follow the labels shown on your device. Do not delete network configurations in bulk if you are unsure what they do, especially if the device has connections needed for work.

After allowing the configuration, check the connection status in Home. System authorization only lets the device establish the network extension; it does not correct fields such as Address, Password, or SNI. If authorization is complete but the connection fails, move on to checking parameters and network conditions rather than repeatedly revoking permission. Treat system permissions and remote authentication as separate steps to avoid repeating the wrong action.

Know which permissions are conditional and which features are optional

When scanning an existing server QR code with Scan QR Code, the app may request camera access. This permission is only needed if you use the scanning feature; it is not required to enter or paste existing details manually. Check the protocol and key fields in the scan result before saving. QR codes may contain server authentication details, so avoid storing the original image in a public album or uploading it when asking for help.

When importing from the clipboard, the system may prompt you to allow pasting. First confirm that the copied content is your own configuration, then allow access for this paste. A regular web address is not necessarily a subscription URL, and a copied block of instructions may not be recognized. If parsing fails, return to the source and copy only the complete link, keeping necessary punctuation and encoding intact. Do not remove trailing characters unless you know what the format requires.

Check how the device is currently routing network traffic

Before the first test, confirm that the device can access the current Wi-Fi or cellular network. If Wi-Fi requires a sign-in page, complete that authentication before connecting Shadowrocket, then return to the app. Server tests will also fail if the underlying network is unavailable. This order separates local network access problems from server problems, so not every timeout is blamed on the same subscription.

If the device has other VPN configurations, confirm which one is currently active. Multiple configurations that route network traffic can interfere with each other, so keep only the connection needed for this test while troubleshooting. Organization-managed devices may have restrictions; follow the applicable management requirements and do not change policies you do not understand. A VPN indicator in the system only suggests that a tunnel is running; check the app status and actual requests to determine whether it works.

For the first test, leave On Demand off and use the manual switch to connect and disconnect once. Otherwise, a network change might trigger an automatic connection and make it unclear whether the switch worked. After manual connections are stable, configure automatic behavior one option at a time in Settings. This makes each status change easier to explain and helps pinpoint the cause if automatic reconnection occurs later.

Add an existing server or subscription

First identify whether your existing details are individual server parameters, a server sharing link, a subscription URL, or a routing configuration file, then choose the appropriate import method. These are different types of data: a server entry describes how to connect to a remote server, a subscription updates a group of servers, and a configuration file describes routing and other runtime settings. Importing a rules file as a subscription, or pasting a product information page as a server link, can cause a parsing error rather than create a usable connection.

Check the fields in Add Server

In Home, open Add Server, choose Type, then enter Address and Port exactly as provided. Address is usually a domain name or IP address; do not append a webpage path. Port is the server's listening port, not a protocol name. Then enter the authentication fields required for that type, such as Password, UUID, or a key. Choosing the wrong Type gives you the wrong fields, so the expected handshake will fail even if the address and port are correct.

For TLS, check SNI and certificate requirements against the provider's documentation. Address is the connection target; SNI identifies the server name during the TLS handshake. They may or may not be the same, so do not copy one into the other automatically. For certificate errors, check the name, device time, and server certificate; do not treat Allow Insecure as a routine fix. For details on specific fields, see the Trojan parameter guide.

Import using Subscribe or a link

If you have a subscription URL, paste the full address into Subscribe or the subscription entry in the current interface, give it a recognizable name, and update it. The remote configuration entry in Config may also accept a routing configuration URL, so check the data type before importing; do not assume that every entry accepting a URL serves the same purpose. After a successful import, you should see the expected servers or configuration. If you only see webpage content, check whether you copied an information page instead of the resource URL.

Query parameters in a subscription URL often identify your account; capitalization, encoding, and trailing characters can all matter. Remove spaces or line breaks introduced during copying, then check that the URL is complete. Do not delete parameters to shorten it. If an update fails, note whether the problem is DNS resolution, a request timeout, authentication rejection, or content parsing. Each points to a different stage; adding the same URL again usually just creates duplicate groups.

A single server sharing link can be imported using a link format supported by the app, the clipboard, or Scan QR Code. After import, open the entry details and check Type, Address, Port, and authentication fields to make sure the result is complete. Automatic detection saves manual entry but does not guarantee that every optional parameter matches the server's requirements. For the differences between import methods, see subscription and server import methods.

Save entries in a list you can maintain

Select the server you just saved and confirm that the selection indicator moves to the intended entry before testing. Use a note to identify its purpose or source, not its password. Keep subscription-generated entries distinguishable from manually added ones; an update may regenerate some fields, so changes made directly to a generated entry may not persist. Before maintaining a lasting difference, check how the app handles overrides or separately saved entries.

For your first import, keep one entry from a known source rather than importing several configurations of uncertain origin. If the provider supplied only some fields, confirm the rest with the original source instead of guessing the authentication type or port. This site does not provide, sell, or recommend servers or subscriptions. By the end of this section, you should know which server entry you are using, which existing information it came from, and where to go to update it.

Three Global Routing modes and rule order

Open Global Routing in Home and check whether Config, Proxy, or Direct is selected. These modes correspond to configuration-based routing, proxy routing, and direct connections; they determine how applicable traffic is handled, not which of three servers is used. Selecting a server answers “which server handles the proxy connection?” Global Routing answers “how should each request be handled?” Keeping these two choices separate helps explain why different websites can behave differently with the same server.

Confirm which Config is active

In Config, check which configuration is currently enabled and, if needed, inspect its contents rather than relying on the filename alone. A file appearing in the list does not mean it is active. In Config mode, rules are generally matched from top to bottom, and the first match determines the handling policy. Put specific conditions before broader ones and leave FINAL as the last fallback, so earlier matches do not prevent later rules from being used.

The following .conf snippet illustrates rule syntax; it is not a complete configuration containing server details. example.com is an example domain, and PROXY refers to a proxy policy. Before using it, confirm that the active configuration defines that policy. Copying these lines does not provide a server or link the rules to an existing server automatically. Back up your current content, then adapt the snippet to the structure of your configuration.

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

Understand match conditions and handling policies

DOMAIN matches an exact domain, DOMAIN-SUFFIX matches a domain suffix and its subdomains, and DOMAIN-KEYWORD matches a keyword in the domain. The last option has a broad scope; a word that seems distinctive can still produce unintended matches. IP-CIDR and IP-CIDR6 match address ranges, and their prefix lengths must be preserved. These are different conditions from domain-based matching.

GEOIP matches against IP geolocation data; it does not determine a website's language or place of business. A website may serve content from multiple distributed addresses, so identical page text does not mean every request matches the same region. DIRECT means connect directly, and REJECT means reject the request. Other policy names must have corresponding definitions in the configuration. FINAL is not a way to “check all the rules again”; it handles requests that did not match earlier rules.

Use comparisons to find rule problems

If a destination works in Proxy mode but not in Config, first note the rule and policy that matched the request, then check the order and conditions. Do not immediately replace every server; the proxy path already provides a useful comparison. If the destination also fails in Proxy mode, check the server, authentication, TLS, and network conditions first. Whether it works in Direct mode only tells you about the direct path; it does not prove that the proxy settings are correct.

Change one rule at a time, save it, and apply the configuration as required by the current interface before making the same request again. Existing long-lived connections may continue using the previous path, and a browser may serve a cached page; close the relevant pages and retry if needed. Test the failing subdomain, not just the homepage domain: page images, APIs, and login requests may use different domains and match different rules.

Connection, testing, and step-by-step troubleshooting

In Home, select the server you have checked, confirm Global Routing, and turn on the connection switch. Wait for the status to change, then visit a familiar destination you can test again and check the actual request records. Do not treat “the switch is on,” “the system shows a VPN indicator,” and “a test returned a value” as the same proof of success. They reflect runtime status, system tunnel status, and results under a particular test condition, respectively.

Separate test results from actual access

Run a test in Connectivity Test to see whether the selected server responds under that test method. Results depend on the test target, protocol support, and network conditions. A single duration does not represent the speed of every website, and a failed test does not prove that every request is unavailable. If the test succeeds but a webpage fails, check the destination domain, routing policy, and actual requests in the app rather than simply running the test again.

Keep conditions consistent when testing: use the same device, underlying network, server, and request. First note the result in Config mode; if you need to isolate the effect of routing rules, switch briefly to Proxy and test again, then restore the original setting. If you change networks, servers, and DNS at the same time, you will not know which change made a difference, and the result will not provide a useful basis for future troubleshooting.

Troubleshoot based on where the failure occurs

If the connection switch quickly turns off again, first check whether the problem is system authorization, network extension startup, or a local configuration error. Confirm that the VPN configuration exists and the device allows it to run, then check for configuration parsing or policy reference errors in the app. There is no need to start with a website's rules if the client has not reached a stable running state. Keeping the exact error message is more useful than saying only that “it won't open.”

If the switch stays on but no destinations load, check the underlying network, then the server Address, Port, authentication details, and service status. A connection timeout means a step did not complete in time; it does not by itself mean the password is wrong. An authentication rejection points more directly to an account or parameter issue. For TLS errors, check SNI, the certificate name, and device time rather than guessing the cause from a generic failure icon.

If only some destinations fail, find the destination and its related subdomains in the records, then check whether the matched policy is expected. A homepage may load while images or login requests fail because different requests use different paths. Also distinguish a business error returned by the remote service from a network error: if a page displays an account permission message, at least part of the connection succeeded. Repeatedly changing local VPN permissions will not fix that.

Keep the smallest record that reproduces the issue

Note when the problem occurred, whether you were on Wi-Fi or cellular, the current mode, the destination domain, and the error type. If logs contain subscription URLs, authentication fields, private keys, or complete request parameters, hide sensitive details before sharing them. The protocol and error stage are usually enough for an initial diagnosis; there is no need to publish your entire configuration. Turn off temporary detailed logging after testing to avoid retaining unnecessary access records.

After switching networks, reconnect and make a new request; do not treat a result from before the switch as the current state. Some protocols require specific transport conditions, so success on one network does not guarantee success on another. If the issue is still difficult to reproduce, restore the most recent configuration known to work, note the differences, and test them one at a time. For the main connection workflow, see the connection and testing tutorial. The goal here is to narrow down the cause, not change every setting at once.

Data, traffic, and request records

Once connected, open Data and check the reporting scope shown on the page before reviewing upload, download, and request activity. These figures help explain network activity visible to the client; they are not carrier billing records and may not include all network activity on the device. Counters may accumulate by session, runtime, or the period shown on the page. Check the units and scope before interpreting a value; a total alone cannot tell you how much data a particular app transferred.

Check direction, units, and time range first

Upload is data sent from the device; download is data received from elsewhere. Speed measures a rate of change over a period, while a total is the accumulated amount for the observed range. They are not directly comparable. A speed drop after a page finishes loading usually means the transfer is complete, not that the connection dropped. Background syncing may still create occasional traffic, so small changes while idle do not prove there is a problem.

Before troubleshooting, note the current counters or use the reset option provided by the page to start a new observation period, then perform one target action. Compare the change afterward to separate that request from earlier background traffic. If the page does not specify a reporting period, do not call the figure “monthly usage.” For billing information, check the relevant account records from your provider or carrier rather than relying on a partial client-side count.

Use request records to verify routing

In Data or the relevant request records view, find the domain you just visited and check the destination, policy, match details, and error information shown by the current interface. The fields available depend on the interface and logging options; do not expect every record to include every detail. Focus on three questions: did the request appear, which route did it use, and where did it stop? Rule analysis only has a clear subject once the request appears in the records.

If the expected request is missing, first confirm that the target app made a new connection. Browser cache, a reused connection, or a page that was not refreshed can make an action appear to happen without creating a new network record. Close the page and retry, or perform an action that clearly requires network access. Also check the record filters: if they show only errors or a particular policy, other requests may be hidden rather than bypassing the client.

Seeing DIRECT does not necessarily indicate a problem; check the current Global Routing mode and match conditions. In Config mode, a direct result may be exactly what the rules specify. In Proxy mode, check the applicable scope and actual records. A matched rule only shows that a route was selected; it does not guarantee that the destination server accepted the request. Treat correct rule selection and a successful destination response as two separate checks.

Use repeatable tests to explain traffic differences

If a user thinks an action consumed an unusual amount of data, repeat the same action against the same destination, then compare request counts, retries, and connection duration. Videos, images, and sync tasks naturally transfer different amounts; do not compare one text page load with one media playback. Repeated requests during a failure can still increase the total. A change in traffic does not mean the requested operation completed successfully.

If the client count differs from usage reported by a remote account, first compare the reporting periods, how upload and download are combined, and protocol overhead. The client counts traffic within its own scope, while the remote service may use different accounting boundaries. A difference alone does not prove that the records are wrong, and changing routing rules cannot guarantee matching totals. Compare the same time range, then ask the source of your existing service how it calculates usage.

Manage how request records are stored and shared

Request records may reveal destinations, timestamps, and some URL parameters, so handle them carefully. Keep only the time range relevant to troubleshooting and hide identifying information, subscription credentials, and unrelated domains before sharing. Server notes in a configuration may also reveal personal details; check screenshots and exports before sending them. Clearing records removes troubleshooting evidence, so make a necessary, redacted note before deleting them.

Settings, DNS, and On Demand

Before opening Settings, note the conditions under which the current connection works and decide what you need to change. Settings may interact with the active configuration, and some options depend on the protocol and device. Follow the fields shown in the current interface, read their descriptions, and change only what you need. Do not enable every option just to make the screen look “fully configured”; unused features do not need adjustment.

Understand DNS by following the resolution path

When looking for DNS options, first identify whether the current setup uses system DNS, a custom resolver, or settings from the configuration file. DNS converts domain names into addresses, and rules may depend on both domain names and resolution results. A DNS problem can prevent a page from opening or affect IP-based rule matching. Before changing DNS, distinguish a name resolution failure from a server connection failure; changing the resolver alone will not fix the latter.

With system DNS, results depend on the resolver provided by the current network. With a custom DNS server, confirm that it is reachable over the existing route. DNS over HTTPS carries queries over HTTPS, but its service address must also be reachable, and the initial connection may itself require DNS resolution. Enabling an encrypted transport does not prove that every part of the resolution path works; check whether queries actually succeed.

When testing DNS, change only one source at a time, keep the previous value, and make a new request. If needed, clear the relevant cache or reconnect using the method provided by the app so old results do not affect the test. If one domain fails while others work, investigate that domain and its related requests instead of resetting all DNS settings. For specific guidance, see the DNS settings guide.

Enable On Demand only after manual connections are stable

Read the trigger conditions in the On Demand section, then set the network situations in which you want a connection to start or stay active automatically. On Demand determines when to try connecting; it does not determine whether the server will authenticate and does not replace Global Routing. Enabling automatic behavior before manual connections are stable makes status changes harder to explain. First complete a manual connection, test it, and disconnect; then add On Demand conditions and test them separately.

After configuring it, switch networks as planned and check whether the expected action occurs. If the connection drops and then starts again automatically, check the On Demand conditions before concluding that the switch is faulty. If troubleshooting requires the connection to stay off, pause the relevant automatic behavior first, then observe the system status. Network changes, device sleep, and switching between foreground and background can create different conditions, so one successful trigger does not verify every scenario.

Adjust transport and advanced parameters with care

Open advanced server or configuration fields only when the problem involves a specific protocol. MTU affects how much data each transmission can carry; a value that is too large may cause problems on some paths, while one that is too small can add overhead. Do not copy someone else's value without evidence. For WireGuard, distinguish the scope of Allowed IPs from application-level rules. See the WireGuard parameter guide.

Keep the purpose of certificate and TLS settings clear. If certificate verification fails, check the name, validity, and device time first. Disabling verification changes the trust conditions and is not a routine way to improve speed. Advanced features involving additional certificate trust, request rewriting, or content handling are not required to establish a basic connection with this guide. If you do not understand their scope, keeping a known-working configuration is easier to maintain than copying a complex setup.

Check for configuration overrides and when changes take effect

After making a change, return to Config and confirm that the active file has not switched to another item, then save or reconnect as the interface requires. Some settings affect new requests; others take effect only after reconnecting. The old page showing the same result does not by itself mean the change failed to save. If a setting reverts after a file update, check whether the remote configuration overwrote it instead of repeatedly editing a value that will be replaced.

Subscription updates, backups, and routine maintenance

For daily use, keep a configuration known to work, then update subscriptions and the app as needed. Maintenance is not about repeatedly changing every setting; it is about keeping sources, changes, and results traceable. For each change, be able to answer three questions: what changed, why, and how to undo it. If the connection behaves differently, you can start with the latest change rather than troubleshooting from the initial installation.

Know which of the three items you are updating

Updating a subscription changes server details and may change the number of entries, addresses, authentication, or notes. Updating a remote file in Config may change rules and runtime options. Updating the app in the App Store changes the client itself. These operations are not interchangeable. A successful subscription update does not mean routing rules were updated, and an app update does not make expired server credentials valid again.

Before updating an existing subscription, confirm that its URL still comes from your own service information and note the currently selected entry. After the update, check the group, server details, and selection, then test the same destination. If an old entry disappears, check whether the service details changed instead of treating its former name as a permanent identifier. If the update fails, keep the exact error and determine whether the resource could not be retrieved or its contents could not be parsed. Do not immediately delete a list that still works.

Separate secrets from general notes when backing up

If you use the app's available export or backup method, first check which items it includes. Rule files, server entries, subscription URLs, and private keys may be stored separately; exporting one file does not prove that all data is included. After backing up, check what it contains and whether you can retrieve it from its storage location. If the recovery process is important, test it in a way that does not affect your active configuration rather than waiting until you change devices.

A backup may contain Password, UUID, Private Key, and subscription URLs with identifying parameters. Store it somewhere you control with appropriate access protection. When explaining rules to someone else, share only the necessary excerpt, not the complete backup. Example domains can be shared; real authentication details do not become ordinary documentation just because they appear in a configuration file. If credentials may have been exposed, use the account management tools provided by the original service to revoke or replace them.

Recovery steps for a new device or reinstall

On the new device, find Shadowrocket in your App Store Purchased items, check device compatibility, open the app, and then import your existing backup. Restoring purchase eligibility and restoring configuration are separate steps: the former depends on your App Store account; the latter depends on the data you kept. After importing, check permissions, the selected server, Global Routing, and the active Config. Do not assume that system permissions from the old device will transfer completely.

After restoring, connect manually and confirm that a request works and the routing result is correct before enabling automatic behavior such as On Demand. If the backup is old, first check whether server authentication is still valid; if the subscription needs an update, update it and check the selected entry again. Do not delete all records from the old device right away. Wait until the new device is verified and you have confirmed that any necessary data can be restored, then handle the old data as appropriate.

Keep a brief record of changes

Use personal notes to record the date, the item changed, and what you observed, but do not include passwords or complete subscription URLs. “The target API recovered after changing the policy for a DOMAIN-SUFFIX rule” is more useful than “changed settings.” If the problem occurs again, compare these changes, then follow connection troubleshooting to narrow it down through permissions, network, server, rules, and destination service.

If you have not used the app for a while, check the underlying network and the app's status in the App Store before reconnecting, then verify your existing service details. Do not use the result of an old test as proof of current conditions, or rebuild every configuration just because the interface layout changed. If an entry has moved, look for its English label. The troubleshooting methods in this guide still apply where the parameter meaning has not changed; available options depend on the current app interface.

After maintenance, return to a minimal working state: the selected server is clear, the active configuration is known, test results are reproducible, and temporary records have been handled. For the full first-time workflow, return to the quick start guide; for more protocol context, see the technical articles. This guide explains the boundaries between each stage; it does not replace account management or parameter documentation for your existing service.