Shadowrocket Complete User Guide

Stage 01 / Access

App Store access and authenticity checks

Shadowrocket is a paid, closed-source commercial app distributed on Apple platforms. The App Store is the only place to get it. Before you begin, check the store account on your device, your purchase history, and your available payment method. Buying the app and obtaining server details are separate steps: installing Shadowrocket only means the app is ready to run; it does not mean you have a service you can connect to. This site explains how to import and use information you already have; it does not provide connection services.

Check these three details on the App Store page

Open the official App Store download guide and go to the App Store product page. Check the name, Shadowrocket, then verify the developer, Shadow Launch Technology Limited, the official app icon, and the app ID, 932747118. The name alone is only a preliminary check; the developer and app ID are better ways to rule out similarly named search results. The app ID appears at the end of the product URL as id932747118; it is not the app's current version number.

The icon should match the official icon shown in this site's header. Search results, the product page, and the payment confirmation screen may involve redirects, so check the product name again before confirming a purchase. If the developer shown is different, stop and return to the official download guide to open the product page again. Do not skip the developer check just because an icon looks similar, and do not treat search ranking as proof of authenticity.

Understand the one-time purchase and device compatibility

Shadowrocket is sold as a one-time app purchase. The actual price, currency, and taxes are shown on the App Store page. A one-time app purchase ≠ a service plan: the app price does not cover the cost of a service you already use or replace its expiration date, data allowance, or account authentication. If a connection fails later, check the app and the service separately. Do not assume a server should work just because you purchased the app.

This guide focuses on using Shadowrocket on iPhone and iPad. The same App Store page also lists compatibility with Mac, Apple TV, and Apple Vision; system requirements, device support, and whether a purchase can be used across devices are as stated on the App Store page. Layouts and input methods vary by device, so do not assume a button appears in the same place on every device.

After installation, keep purchase records separate from configuration data

When installation is complete, open Shadowrocket from your device's Home Screen and confirm that it launches before you start importing anything. Keep your App Store purchase record and server or configuration data separately. They are not interchangeable: restoring a purchase does not restore all local settings, and reinstalling does not guarantee that subscription groups, manually added servers, or custom rules will return.

When moving to a new device or reinstalling, first check the purchased items under the original account in the App Store, then follow the guide to restoring a purchase. If the store shows a price again, check the account and purchase history before taking further action. Whether a purchase appears in the store may also depend on the current storefront and account status. Troubleshoot this in the App Store first rather than changing connection settings.

Stage 02 / Permissions

First launch and the system VPN configuration

When you first open Shadowrocket, get familiar with the roles of Home, Config, Data, and Settings. Home is mainly for viewing servers and connection status; Config manages routing configurations; Data shows traffic-related readings; and Settings contains common behavior options. The exact layout may vary with the current app version. Learning where these sections are before making changes makes it easier to identify the cause of a problem than changing several switches at once.

Why does the system ask to add a VPN configuration?

When you first turn on a connection after preparing a server, the system may ask permission to add a VPN configuration. This authorizes Apple’s system to manage the network extension connection, allowing the app to handle traffic through the system’s networking mechanisms. It is separate from the rule file in Config: the system VPN configuration determines whether the app can handle relevant network traffic, while Config determines how requests are handled afterward.

Once you confirm the prompt was triggered by an action you just took in Shadowrocket, follow the system instructions to grant permission. The system may ask you to authenticate on the device. Afterward, return to the app and check the switch and connection status. Allowing a VPN configuration does not mean server authentication succeeded; system authorization does not verify the address, password, UUID, or availability of the remote service. The system configuration may be in place even when the server is unreachable.

What to do if you deny, delete, or repeatedly see the prompt

If you denied permission, return to the app and make sure the server details are saved before trying to connect again. Check whether the system shows the authorization prompt this time. If the expected prompt does not appear, look for the configuration in the VPN section of your device's system settings. The layout may vary between system versions; search by the VPN entry's name rather than relying on a fixed menu path. Do not delete a configuration for another purpose unless you have confirmed what it is.

If you deleted the VPN configuration for Shadowrocket in system settings, you may need to grant permission again the next time you connect. Disconnect first, then start a new connection request from the app. If authorization still fails after repeated attempts, note the exact system prompt, whether device management restrictions are in place, and whether another VPN connection is running. Resolve permission issues first; do not change the protocol, DNS, and rules at the same time.

Understand camera, photo, and network permissions

Scan QR Code requires camera permission to scan with the camera. Scanning a QR code from an image may instead use the system photo picker. These permissions are only needed for the relevant import method; you do not need to scan a code before entering details manually in Add Server. A QR code may contain complete authentication details, so make sure it comes from a service you already use. After scanning, verify the protocol, address, and port.

If a prompt asks for local network access, consider which feature you were using—for example, accessing a device on your local network. This permission does not replace VPN configuration authorization. Notification and other auxiliary permissions are not connection permissions either. Read each prompt in order rather than assuming that allowing one request satisfies every permission. Note which permission you denied so you know what to address later.

Set up repeatable conditions for your first connection

For your first setup, stay on a stable network and avoid switching back and forth between Wi-Fi and Cellular. First confirm that ordinary internet access works when Shadowrocket is disconnected. Then save one set of verified parameters, complete system authorization, and check whether the app and system report consistent statuses. If your device is managed by an organization, policy may restrict some network extension actions. Follow the device management requirements rather than mistaking a restriction for a server problem.

At the end of this stage, you have confirmed only that the app launches and the system authorization flow works. After connecting, you still need to verify that requests reach their intended destinations and that Global Routing behaves as expected; see Chapter 5. For more on how permission prompts relate to system configurations, read the guide to the VPN configuration prompt on first connection. When troubleshooting, the exact prompt is more useful than simply saying that it will not connect.

Stage 03 / Import

Add Server and manage Subscribe

Before importing, identify what you have: individual server details, a QR code containing server information, or a subscription link. Each requires a different workflow. A regular webpage URL is not a subscription, and a subscription link should not go in the address field for an individual server. Use information from a service you already have. This chapter explains how to enter and verify it accurately; it does not recommend any service.

Match each Add Server field to your details

In Add Server, first choose the protocol that matches the information you have, then enter the address and port. The address is usually a domain name or IP; do not append a path yourself. The port must match the remote listening port. Next, fill in the authentication fields required by that protocol. Do not guess values just because a field is empty, and do not copy labels from the instructions along with the values. Save your entries, then reopen them to check your work.

Successful authentication does not mean the transport settings are correct. TLS server names, WebSocket paths, and Host fields belong to different layers. Enter each according to the details you have; do not substitute one for another just because the server addresses look similar. If certificate verification fails, check the name, device time, and remote certificate. Disabling verification should not be your routine fix. See the guide to VMess and VLESS parameter differences.

Subscribe: importing and updating are separate actions

Importing a subscription reads the content returned by its link and creates the corresponding server group. Updating a subscription fetches the content again to sync changes to addresses, ports, and other parameters. Enter the link using the subscription method provided by the app, save it, and wait for the request to finish. Then confirm that servers appear in the group. If you see a group name but no usable entries, check the response content; the import has not necessarily succeeded.

Subscription links often contain personal authentication details. Do not share them in public conversations, screenshots, or troubleshooting reports. When copying a link, check that the end has not been cut off, that no spaces were added, and that you copied the actual URL rather than its display text in a rich-text document. If an update fails, note the exact error, then check whether your ordinary network can reach the subscription address, whether the service is still active, and whether the response is a login or error page. Repeatedly tapping Update is not a substitute for troubleshooting.

Check the result after importing a QR code

After scanning with Scan QR Code, check that the new entry's protocol, label, and address match your expectations. A QR code may represent an individual server or a subscription entry; use the object created by the app to determine which one it is. If the scan succeeds but the expected content does not appear, identify the input type before doing anything else. Do not try to assemble the link manually right away. If you cannot verify the source or its contents, stop and obtain accurate information for a service you already use.

Manual edits and subscription overwrites

Subscription entries are maintained by the subscription content. If you edit a parameter manually, the next update may overwrite that field. For a temporary test, note the original value first and, where possible, use a separate test entry rather than making the whole group difficult to track. A server's displayed name is only a label; matching names do not mean the addresses are the same. Check the actual protocol, address, and port to identify duplicates.

After importing, select one server for a single test instead of testing every entry at once. If an old entry works but a new one does not, first compare their parameters and service status. If all entries fail, check system permissions, the local network, and the import method. Before deleting an old group, verify that the new one works for actual access so you do not remove data you may still need to fall back on.

Stage 04 / Routing

Global Routing: three modes and rule order

Global Routing determines how requests handled by the app are processed. Config applies the rules in the current configuration; Proxy sends relevant requests through the selected proxy; Direct handles relevant requests directly. These modes apply to requests within the app's handling scope. Do not assume that any one mode controls every network activity on the device; system mechanisms, app behavior, and connection type can all affect what you observe.

Choose a mode before interpreting access results

For everyday rule-based routing, use Config and confirm which configuration is active. For troubleshooting, briefly compare Proxy and Config: if the same destination works in Proxy but fails in Config, check the rules, policy references, and DNS handling first. This is not conclusive—caching, connection reuse, or network changes may affect either request—so repeat the comparison under similar conditions.

Rules are generally evaluated in order

In a rule file, put specific matches before broader ones, then use FINAL to handle requests that do not match earlier rules. DOMAIN matches an exact domain, DOMAIN-SUFFIX matches a domain suffix, IP-CIDR matches an address range, and GEOIP checks an address against a geolocation database. Keep rule keywords distinct from policy names: keywords define what to match; policies define how matching requests are handled.

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY

This Shadowrocket .conf snippet illustrates rule order; it is not a complete configuration for every network. The first rule sends the example domain suffix to PROXY, the second sends the specified private address range to DIRECT, the third uses GEOIP, and the last handles remaining requests. In practice, check it against your local network addresses, destinations, and available policies in your configuration. Do not assume that copying the snippet alone will provide complete routing.

Why domain rules and IP rules can behave differently

Domain matching depends on the request containing identifiable domain information; IP rules match destination addresses. Some apps connect directly to an IP address, or use a cached DNS result, so a domain rule alone may not cover every related request. A webpage may also request resources from multiple domains. If the main page loads but images do not, check the resource requests rather than stopping after adding a rule for the main domain.

GEOIP results depend on the database and the resolved address. They do not indicate a site's language, brand location, or the content a user sees. A destination that uses multiple or changing addresses may match differently over time. For edge cases, check the actual destination first, then decide whether to use a specific domain, an address range, or another rule. Do not broaden an entire address range to fix a one-off access problem.

Recheck after changing Config

Save a copy of the original configuration before changing one rule with a clear purpose. Make sure the change is saved and that the updated configuration is the one currently in use. A file appearing in the configuration list does not mean it is active; check carefully when filenames are similar. If a policy reference is missing, the rule format is invalid, or a remote resource update fails, fix the configuration before testing network access.

Stage 05 / Verification

Connection status, Connectivity Test, and real-world access

Connection checks involve three layers: whether the system allows the connection to start, whether a server connection can be established, and whether the destination request completes as expected. An enabled switch only reports the state of one layer; it does not by itself prove that webpages will load. Likewise, a timeout in one test does not necessarily mean that every network path is unavailable. Record results by layer to avoid masking important differences with a vague “sometimes it works.”

Establish a baseline for comparison

Disconnect first and confirm that your current Wi-Fi or Cellular network supports ordinary internet access. If the network itself requires a login or keeps disconnecting, resolve that first. Then select one verified server and one Global Routing mode, connect, and wait for the status to stabilize. Keep the destination the same during testing; do not change networks, servers, and rules all at once.

For real-world access, check whether the destination page loads fully, its resources continue to load, and new requests succeed repeatedly. A page that is already open may be served from cache, so a refresh icon that stops spinning is not enough to confirm success. If needed, close the existing connection in the destination app and make a new request, or cross-check with another clearly new request. You do not need to clear all device data to test access.

What Connectivity Test results can tell you

Connectivity Test helps you check whether a test destination is reachable. Results depend on the test method, destination, and network conditions at the time. A lower reading does not necessarily mean higher download speed, and it does not guarantee that every website will work. A server may pass the test while DNS, TLS, the app protocol, or resource domains required by a real destination still fail. Consider the test result alongside real-world access.

When comparing two servers, keep the test method and network conditions as consistent as possible; readings from different conditions cannot be ranked directly. Retry a one-off timeout to check whether it recurs, but there is no need to run frequent tests on every entry. Excessive testing generates extra requests and can make results harder to interpret. Representative successes and failures are more useful than a single momentary reading.

Narrow down the problem based on where it occurs

If the switch turns off immediately, start with the system VPN configuration, permissions, and app messages. If it stays on but all real requests fail, check the server address, port, authentication, transport, and underlying network. If only one destination fails, check its DNS resolution, rule matching, and remote status. Authentication errors, certificate errors, and timeouts mean different things. Keep the original error text instead of labeling everything “can't connect.”

If the test succeeds but a webpage will not open, first check whether DNS returns a valid result, then compare the same request in Config and Proxy. A successful lookup may still return an address that is unreachable on the current path, so check the subsequent connection error too. See the DNS resolution troubleshooting checklist; do not change every DNS option at once and hope for the best.

Troubleshoot speed and connection issues separately

If a connection works but speed is inconsistent, first distinguish a slow initial connection, a slow individual request, and slow sustained transfers. The first two may involve DNS resolution and handshakes; sustained transfers also depend on remote load, local signal, network congestion, and destination limits. Latency is only one indicator and cannot be directly converted into throughput. A change in performance after switching networks may point to the local path, but does not prove it is the cause.

Use the layered speed troubleshooting guide to compare results under consistent conditions. After temporary tests, restore your usual mode. In particular, do not leave Proxy or Direct enabled if it does not suit your everyday needs. If the cause remains unclear, note the network type, protocol, mode, exact error, and steps to reproduce it, then check the relevant category in FAQ.

Stage 06 / Monitoring

Data readings and what they do—and do not—measure

Data helps you observe traffic activity that the app can measure, such as whether requests and data transfers occur during a connection. It is not a service bill or the sole way to determine how every request was routed. Before interpreting a number, check the current statistics range, grouping, units, and start and end times. Two numbers from different ranges should not be subtracted just because they look similar.

How to read upload, download, and rate

Upload and download describe data moving to and from your device. Upload usually includes requests, submitted content, and connection exchanges; download includes returned data and responses. Loading a webpage also generates upload traffic, so a nonzero upload reading does not mean the device is sending a large file. Connection setup, retries, and background activity can also affect the reading; interpret it in context.

Rate describes data changing over a period; cumulative traffic describes the total over a statistics interval. A momentary drop in rate may simply mean there is no new data, not that the connection has dropped. A cumulative number that continues to rise does not prove the destination page has loaded successfully. Check whether the interface shows byte-based or bit-based units; the difference can make the numbers look very different.

Limits of viewing data by server or app

When viewing data by server, focus on the data attributed to that server over the same statistics interval, not just the name of the currently selected server. After switching servers, interpret readings in light of the connection lifecycle and the actual interface. A change in the selected server does not necessarily rewrite all historical statistics. If the interface offers different views, first check the current view's title and how it groups data.

If the current interface offers data grouped by app or process, treat it as activity the client can identify—not a complete audit of all traffic from every app on the device. System-provided information, shared connections, and background requests can affect attribution, and unrecognized requests should not be assigned to an app without evidence. The range shown depends on the current app interface. An item not being listed does not prove that it never connected to the network.

Why the numbers may not match service records

Client statistics and records in the dashboard for a service you already use may use different start and end times, billing cycles, unit conversions, and accounting for protocol overhead. Server-side records may combine other devices or connections on the same account, while the client shows only activity it can measure on this device. Align the time period and device first, then check whether both counts include uploads, downloads, retransmissions, and connection overhead. This is usually more useful than comparing totals directly.

If background requests were already running when you started monitoring, the initial reading is not a zero baseline. Automatic subscription updates, connectivity checks, and syncing by other apps may also generate traffic during a test. For a small comparison, note the starting and ending readings and keep the test duration and destination consistent. Do not delete statistics or reset all configuration just to “zero” the numbers.

Use Data for focused troubleshooting

If you make a new request after connecting but do not see the expected change in Data, first check whether the request is within the current view and whether it was served from cache. If uploads rise but downloads remain low for an extended period, treat that as a reason to investigate the remote response, not proof of a particular authentication error. Also check connection messages, resolution results, and rule handling.

Record the start time, destination, mode, and server for one test, then observe the corresponding change in Data. Change just one condition and repeat the test to connect the statistics with the action you took. For more on how to interpret the readings, see the guide to Data traffic statistics. If you report a problem, share only the necessary summary and hide server addresses, personal identifiers, and authentication details. You do not need to publish the entire page of records.

Stage 07 / Settings

Settings, DNS, and On Demand

Settings affect client behavior, while items in Config may affect how requests are handled under the current configuration. The location of a feature may vary; follow what the current app shows. Before making a change, identify the issue you want to address and whether the setting applies globally or to a single configuration. If you are unsure of its scope, leave the default in place and check what it does. Do not enable every switch that seems related.

On Demand: trigger conditions and manual connections

On Demand requests that a connection start or stay active when system conditions are met, commonly based on Wi-Fi and Cellular. It does not guarantee that a server is available, nor does it mean a different server will be selected automatically if a connection fails. Before enabling it, make sure a manual connection works reliably. Then choose the network conditions that should trigger it, keeping basic connection problems separate from automatic triggering behavior.

Check the rules on one stable network first, then switch to another network and observe what happens. Whether the connection is triggered again after you turn it off manually depends on the current conditions and system state. If it keeps reconnecting, check whether the On Demand conditions are still met instead of repeatedly toggling the main switch. If you need to disable it temporarily, review the automatic trigger settings as well and confirm the system stays in the state you expect.

Check Wi-Fi name conditions carefully; similar names do not necessarily identify the same network. When connecting to Wi-Fi that requires a web login, complete the network sign-in first and then test automatic connection. The system may reevaluate conditions after sleep, network reconnection, or a network switch. Consider brief changes in context and over time; one network switch does not prove every scenario has been tested.

Understand the role before changing DNS addresses

DNS resolves domain names to addresses, but the resolution path and the subsequent connection path are separate issues. Before changing DNS, identify whether the failure occurs during resolution or connection. A domain that returns no result or an error calls for a different approach than a valid address followed by a connection timeout. Changing DNS whenever a webpage will not open can add variables to an otherwise simple problem.

If you use a custom resolution method, make sure it is reachable on the current network and understand how its requests will be handled. Local network names, internal domains, and public domains may have different requirements; one configuration may not suit every environment. After changing a setting, make a new request and account for caching or existing connections that may briefly preserve old results. Do not keep adding options just because a result did not change once.

Logs, tests, and privacy

When reproducing a problem, check logs as needed and note the exact error, time, destination, and conditions. Keeping detailed logs for a long time may use local storage and accumulate information about your activity. Before sharing, remove full subscription links, authentication fields, and personal identifiers. Even a list of domains may reveal usage patterns, so share only what is necessary.

Connection test options can change the destination or method used. After changing one, do not compare its readings directly with results from the old conditions. If the destination itself is unstable, test results may vary too. Keep test conditions consistent during troubleshooting and use access to real destinations as an additional check. Do not keep changing settings just to get a lower number.

Keep a way to revert every change

Before changing Settings, note the original value, why you are changing it, and what result you expect. Save a separate copy before modifying Config. If the app says a new connection is required, wait until any important transfer has stopped before proceeding. If a change does not help, restore the original value before checking the next item. Do not leave behind several experiments whose effects you cannot explain.

Stage 08 / Maintenance

Updates, backups, and troubleshooting records

Once Shadowrocket is working reliably, maintenance is about preserving a recoverable setup and knowing what changed—not making frequent adjustments. An app update, subscription update, Config update, and system update are separate events that can affect different layers. Make one major change at a time and verify the result before moving on. This makes issues much easier to trace.

Update the app through the App Store

Check Shadowrocket's update information and compatibility with your device in the App Store, then update using the method provided by the store. Before updating, make sure you have backups of your parameters and local configurations. Afterward, test with the same server and mode you used before; do not replace all your settings at the same time. If behavior changes, record what you did before and after, along with any app messages. There is no need to guess whether a particular version must be the cause.

A system update may also change permission prompts, network switching behavior, or where settings appear. If the system asks you to confirm a connection again after updating, read the prompt and check the relevant system configuration rather than deleting all your data. System requirements are as stated on the App Store page. If the app opens normally but connections do not work, continue checking permissions, servers, rules, and DNS in that order.

What is worth backing up?

Keep separate copies of the parameters needed for manually added servers, subscription sources, the current Config file, and the original values of important Settings. A subscription link is not a long-term snapshot of server details; its contents may change, so importing it again can produce a different result. Label backups with when they were saved and what they are for, but do not put authentication details in public filenames, screenshot titles, or shared documents.

If you use the app's current export or save feature, confirm what it exports and check that the file contains what you expect. A success message does not prove that the data can be restored; make sure important configurations are readable while keeping the original data intact. Store backups somewhere you control with restricted access. Before sharing a rule example, remove personal server and subscription details.

Maintain subscriptions and Config separately

After updating a subscription, check that the number of entries and key parameters look right before testing a connection. If entries are missing, check the response and service status before deleting old information. For a Config update, check rule order, policy references, and remote resource status. Updating both at once makes the cause of a failure harder to identify, especially when you are already unable to connect.

When removing duplicate entries, compare the actual protocol, address, and port rather than relying on the label. Keep one verified configuration as a fallback, then tidy up old files after the new setup is stable. Do not add configurations if you do not know their source or purpose. More files do not mean more complete functionality; the goal is to know what is active and ensure its references work.

Keep troubleshooting records that reproduce the issue

Useful notes include the network type, whether you had just switched networks, the protocol, Global Routing mode, the exact error, which destinations failed, and the last known working state. Also note each change you tried and its result. This helps distinguish between all requests failing, one destination failing, and a test failing while real-world access still works.

Do not include passwords, UUIDs, full subscription links, or personally identifying information in your notes. If needed, replace real addresses with descriptions while keeping the protocol, error category, and sequence of events. When checking FAQ or revisiting the basics in Getting Started, compare each step with your notes instead of repeating the entire import process to see if anything changes.