Shadowrocket Setup Guide

Choose a Global Routing mode

The server entry determines the parameters used for the proxy connection, while Global Routing determines how requests choose a route. Check these separately: selecting a server in the list does not mean every request will go through it. Return to Home, tap Global Routing, check the current selection, and choose Config, Proxy, or Direct according to the goal of this test. After changing the selection, return to Home and check the mode name again to confirm that you completed the selection, rather than just opening the menu.

Config: Handle requests using the current configuration

Use Config for everyday rule-based routing. It reads the currently enabled configuration and follows the rule match order to decide whether to send a request through a proxy, connect directly, or take another action. Before selecting Config, open Config and confirm which configuration is currently in use—not just that a file appears in the list. The file you just imported may differ from the enabled file; editing the wrong one will not change current connection behavior.

If you have your own configuration, keep a backup before enabling it. Do not simply append scattered rules found online to the end. Rule keywords such as DOMAIN-SUFFIX, GEOIP, and FINAL have different matching scopes, and an earlier rule may already have handled a request so later rules are not checked. This page only asks you to confirm which configuration is enabled and the basic route. For syntax and concepts, see the Terms Guide.

Proxy and Direct: Compare specific routes

Proxy is useful for temporarily checking whether the selected proxy route works; it does not rely on ordinary rules to decide the route for each request. It does not mean the server is necessarily reachable, nor does it guarantee that every app will behave the same way. Direct sends requests over a direct connection and is useful for comparing results on the local network. After selecting Direct, do not interpret “the app switch is on” as “requests are using the proxy.”

For initial troubleshooting, use Proxy to compare results for a specific target. Once the proxy route works, switch back to Config to verify routing. Do not treat a temporary troubleshooting mode as a completed rules setup. After each mode change, retest the same page and record the difference. This helps distinguish a server issue from a rule choosing a different route.

Turn on the connection and complete system authorization

Confirm that the expected server is selected on Home and Global Routing matches your goal, then turn on the connection switch at the top of Home. On the first connection, iPhone / iPad may show a system prompt to add a VPN configuration. Confirm that Shadowrocket initiated the prompt, allow it, and complete the process using your device passcode or authentication as required by the system. System authorization is required to establish the connection; it is not a purchase confirmation and will not fill in missing server details.

After authorization, return to Shadowrocket and check whether the switch remains on. If it turns off immediately, stays on “Connecting,” or displays another permission prompt, stop tapping repeatedly. Read the prompt and confirm whether the previous system authorization was completed. If you canceled it earlier, start the connection again and complete authorization. Do not delete configurations on your device if you are unsure what they are for. On devices managed by work or school, check the management restrictions first.

During connection testing, stop other services that may be using the system VPN connection, then enable Shadowrocket on its own to reduce interference from switching between services. If the status in system settings does not match the app, turn off the connection in the app, wait for the status to reset, and then turn it on again. Allow time for the status to change between actions; rapidly toggling the switch usually makes it harder to identify where a failure occurs.

The system VPN indicator only shows that the relevant network connection has been established; by itself, it does not prove that a webpage used the expected rules. The position and appearance of the indicator can vary by device layout, so there is no need to reconnect repeatedly just to find an icon. Cross-check with the app's tests and actual requests instead of relying only on the switch color.

For the first test, do not adjust On Demand. It triggers connections based on conditions; it does not fix an incorrect server address, authentication details, or rules. First verify the manual process of turning the connection on and off, then configure automatic triggers based on your network usage. This gives you a verified manual process to compare against if automatic connection issues arise later.

Verify with Connectivity Test and actual requests

Keep the connection on and use Connectivity Test on Home to check basic reachability for the selected server. The result can help identify obvious failures, but the test method and target are not exactly the same as how a real app accesses content. A successful result does not mean every website will open. A failed result also needs to be checked against actual requests; do not delete an entire subscription based on that result alone.

Then open a browser and visit a page you normally use where you can tell whether it has fully loaded. Check that the main content appears, then try navigating within the site or reloading the page. Do not assume the connection works just because cached content is visible. If the test target is undergoing maintenance, try another known working target. Do not use an unfamiliar testing page or submit your subscription link or server credentials to a testing service.

To verify rule-based routing, switch back to Config, confirm the currently enabled configuration, and send a new request. Use the request records available in the app to check the destination domain, matched rule, and actual route. Requests expected to connect directly should be handled by DIRECT; requests expected to use a proxy should match the proxy action in the current configuration. If a rule references a policy, check the policy's final selection rather than looking only at the rule name.

You can make a simple comparison of the local result with the connection off, the result in Proxy, and the result in Config. Change only one condition at a time, using the same device, network, and test target. If Proxy works but Config fails, check the rules and configuration first. If both fail, check the server parameters and network rather than adding more rules. After the comparison, restore the mode you use day to day.

Finally, test turning the connection off and back on: turn it off, confirm the local network still works, then enable it again and repeat the actual access test. If it works only the first time and fails after switching networks, note whether the issue occurs on Wi-Fi or cellular. Judge speed and stability in the context of how you use the connection. A single Connectivity Test result cannot be converted directly into a download speed or used to draw conclusions about long-term stability.

Troubleshoot by failure point; change one thing at a time

Start troubleshooting with the local network, not by reinstalling the app. Turn off the Shadowrocket connection and confirm the device can access the internet. If Wi-Fi still requires network authentication, complete the sign-in page before reconnecting. If the local connection itself is not working, changing the server password, rules, or DNS usually will not address the root cause. If cellular data is available, you can switch networks once for comparison, but keep an eye on your data usage.

Import failure: Check the content and update result

If no servers appear after saving in Subscribe, check whether the link was truncated or contains spaces, and whether the service allows an update. Old entries in an existing group do not mean the latest update succeeded; check the update prompt and confirm that the content is as expected. If the link returns a login page or error text, first resolve the conditions required to access it. When reporting the issue to your service provider, describe the error and when it occurred. Do not post the complete private URL publicly.

Connection failure: Check the fields, then the network

If a server fails, open its entry and compare the protocol, address, port, password, and other authentication fields with the details you have. For TLS, also check the relevant server name and transport options. Do not enable every optional setting as a troubleshooting attempt. If several entries in the same subscription fail at once, compare results on different local networks before deciding whether to contact your existing service provider. Do not repeatedly delete and re-add entries because of one failed test.

The switch is on but pages fail: Separate rule and DNS issues

First confirm Global Routing is not set to Direct, then compare the results in Proxy and Config. If only Config fails, check that the correct configuration is enabled, whether an earlier rule has handled the target, and whether the referenced policy is available. If the issue appears to be domain resolution, check the current DNS settings and network conditions rather than entering several addresses at random. Save the original value before making a change, and change only one thing at a time. Whether the issue can be reproduced after restoring the original value also helps determine whether the change worked.

If the browser works but a particular app fails, consider that app's cache, reused connections, service status, and access requirements. Fully close and reopen the app, then send a new request. Do not immediately assume the entire connection has failed. Conversely, if every target fails, recheck the three basics: server details, system authorization, and the local network. Avoid going in circles in the settings for a single app.

Keep reproducible details before investigating further

A useful troubleshooting record includes whether you were using Wi-Fi or cellular, the current Global Routing mode, whether the failure happened during import or actual access, whether all servers behave the same way, and which setting you changed most recently. Before sharing a record, hide subscription authentication details, passwords, and personally identifiable information. For more guidance on error messages, see Troubleshooting. To organize multiple subscriptions and plan updates and backups, continue with the Subscription Guide.

After these five steps, you should be able to identify the selected server, the mode in use, whether the system connection is established, and whether actual requests behave as expected. Follow the same sequence to retest after changing a configuration or updating a subscription. Save a verified working configuration before making more detailed rule changes; this gives you a stable reference and is easier to manage than changing several settings at once.