Shadowrocket Troubleshooting

Open the App Store product page from this site's download page and confirm the app ID is 932747118. Then check whether the app is available in your account's storefront. Search results alone don't confirm availability. To check your region, open Settings, tap Media & Purchases under Apple Account, then View Account and Country/Region. Labels may vary by system language. Before changing your region, review Apple's guidance on balances, subscriptions, and payment methods.

Check all three: the developer is Shadow Launch Technology Limited, the icon matches the official icon in this site's header, and the product page URL contains id932747118. Don't rely on a similar name or search result placement. On the product page, check the price and compatibility; refer to the App Store listing for system requirements. This site's download page brings these details together. Once verified, complete your purchase through the App Store.

Sign in to the App Store with the account used for the original purchase, then look for Shadowrocket in your account's purchased apps. If eligible, you can download it again. If a price still appears, check your purchase history, the account you're signed in to, and the storefront region before paying again. List labels may vary by system version. Reinstalling the app and restoring its configuration are separate tasks: back up any subscriptions, server details, and configuration files separately. Restore eligibility is determined by the App Store listing.

A one-time app purchase is not a service plan. It gives you access to the Shadowrocket app; connecting still requires your own subscription or server details. After importing them, check the settings, select a server, and authorize the system configuration. The US storefront lists the price as $2.99; other storefronts show local prices. This site does not provide, sell, or recommend servers or subscriptions. App purchases and existing connection services are managed separately.

Shadowrocket is available on iPad through the same App Store product page. Sign in with the account used for the purchase and check whether the store shows a download button or a price. Device compatibility, system requirements, and universal purchase eligibility are determined by the App Store listing. iPad has a different display area from iPhone, but you still need to check the selected server, Config, and connection authorization. Purchase eligibility doesn't mean configurations sync automatically, so check that your information is complete when switching devices.

First, make sure the device can access the internet with the connection turned off. Then prepare your own subscription or server details. Import them in Home or enter the settings through Add Server. Confirm the entry appears, select the server you want to use, and check Global Routing. When you connect for the first time, follow the system prompt to add a VPN configuration. Finally, visit a specific website to verify the connection. Test one server before changing rules so you can pinpoint where any issue occurs.

This is the system authorization that lets the app create a VPN configuration; it is separate from whether your purchase succeeded. Make sure the prompt appeared after opening Shadowrocket, then follow the on-screen instructions to allow it and authenticate your device. Return to the app and check the connection status. If you canceled earlier, try connecting again. If your device is managed by an organization, configuration permissions may be restricted. Check the system's management settings and ask your device administrator; don't repeatedly delete configurations used for other purposes.

First, check whether the app or system shows a specific error. Confirm that a valid server is selected and VPN configuration access is authorized. Check whether another VPN connection is active or device management restricts configurations. Then turn off the connection, reopen the app, and test only the currently selected server. If it still fails, note the error, the step where it occurred, and your network type. Avoid resetting the network, deleting configurations, and changing multiple settings at once; otherwise, it will be hard to tell what affected the result.

Config applies the rules in the active configuration file to choose a policy. Proxy sends relevant traffic through the selected proxy policy, while Direct connects directly. To route traffic by rules, choose Config and confirm which file is active in Config. For troubleshooting, test the same destination with each mode, record the results, then restore your usual setting. Global Routing and the PROXY and DIRECT rule policies operate at different levels; a single rule doesn't determine where all traffic goes.

Use the English interface labels to find each section: Home for servers and connections, Add Server to add a server, Config to manage configuration files, Settings for preferences, and Global Routing to choose a routing mode. The manual keeps these labels in English and explains what they do. Device and system settings may affect how labels appear; there's no need to reinstall the app just because of a language difference. If you can't find an item, check the current screen and the options available in the app, then follow the guide.

Make sure you pasted the full subscription URL you already have, not an account page or help page. Check for leading or trailing spaces, line breaks, or missing parameters. Confirm that your current network can reach the URL, that the subscription is still valid, and that its response format works with the app's import option. If an error appears, note its status or wording instead of resubmitting repeatedly. Subscription URLs may contain access credentials; redact sensitive parts and never include the full URL in a public screenshot.

Check the protocol first, then verify the server address, port, and authentication details required by that protocol. If your information also includes TLS, Server Name, a transport method, or a path, enter each exactly as provided rather than guessing from its label. The display name is just for identification; it doesn't affect connectivity. Keep explanatory text out of the address field. Change one field at a time and save and test. Make sure the device date and time are correct, keep the original details for reference, and don't share passwords or other credentials.

Make sure the QR code contains your existing server or subscription details, not just a webpage link. When using Scan QR Code, check camera access, image clarity, and that the entire code is in frame. After a successful scan, open the entry and verify the protocol and required fields; a successful scan doesn't guarantee a correct configuration. If the original details are also available as text, use the relevant import option or enter them field by field through Add Server, then compare key settings. Don't keep scanning the same incomplete image.

Before updating, note the selected server and subscription group, and back up your configuration if needed. Afterward, confirm the entries still belong to the original subscription and check whether the previously selected entry was removed, renamed, or replaced; a name change doesn't guarantee the connection details are the same. If the update fails, check the error and verify the URL instead of repeatedly deleting and re-adding entries. Subscription content and Config files are managed separately. After updating, select a valid entry again and test it; don't assume the previous selection was retained.

A server entry stores the protocol and authentication settings for a connection. A subscription fetches or updates multiple server details you already have. A Config file defines behavior such as rules and DNS. Importing a subscription doesn't mean the right Config is active, and switching Config doesn't update server credentials. First determine whether the issue concerns connection settings or rule behavior, then make changes in the relevant section. Back up important configurations separately and, after restoring them, verify which file and server are active.

Turn off the connection and test your local network, then turn it on and visit the same destination to distinguish a basic network issue from a proxy path issue. Next, check the selected server, Global Routing, and the active Config, then review the rules and errors for the destination request. If only some domains fail, check rules and DNS first. If multiple destinations fail, check the server settings and network environment. Change one thing at a time and record the before-and-after results; don't replace the entire configuration outright.

A Connectivity Test result only shows that the selected test method completed its probe at that time. It doesn't confirm that DNS resolution, authentication, rule selection, and access to the destination are all working. Make sure the test target matches the selected server, then inspect the actual request for the page that failed. If the connection probe succeeds but the domain doesn't load, check DNS. If only a specific destination fails, check the rule policy and whether the destination itself is available. Treat latency as a clue, not the only measure of whether a connection works.

Make sure Global Routing is set to Config and check the configuration file actually in use, not just another file you've edited. Rules are evaluated from top to bottom, and the policy for the first matching rule is applied. Put specific conditions first and FINAL last in the [Rule] section. Check whether a broader DOMAIN-SUFFIX, GEOIP, or IP-CIDR condition matches the destination first, then confirm that PROXY, DIRECT, or REJECT is the intended policy. Make a new request after editing to verify the result; don't judge by an existing connection.

First determine whether multiple domains fail or just one. Then check the [General] section of the active Config and the DNS settings currently in effect in the app. Look for unreachable custom DNS servers, Host overrides, or rules that affect DNS requests. Back up the original settings, change only one DNS-related item, and test again. With DNS over HTTPS, the resolver address itself must also be reachable. A successful connection or a normal latency reading on one test doesn't prove DNS is working.

Check battery usage for the relevant period in system settings, and compare screen time, network conditions, and actual data transfer. A battery usage percentage doesn't mean the app alone caused the extra drain. Then check whether On Demand conditions trigger connections frequently or cause repeated reconnects as the network changes. Compare behavior with On Demand enabled and disabled under similar conditions, then keep the settings that meet your needs. On Demand controls when connections are made; it doesn't guarantee lower battery use or replace checks for unusual network activity.