Shadowrocket Setup Guide

01 · Add a Server or Import a Subscription

Open Shadowrocket and go to Home. Find the add option and open Add Server. First identify the details you have: a subscription link retrieves multiple server entries, while individual server details include a protocol, address, port, and authentication parameters. Choose the method that matches your information; there's no need to import it twice.

Have a Subscription Link? Use Subscribe

In the Add Server type picker, choose Subscribe and enter the complete link from your provider in the URL field. Make sure you haven't copied any explanatory text, quotation marks, line breaks, or extra spaces. Don't remove anything after the question mark: those parameters may identify the subscription. A link opening successfully doesn't mean it will return the same content if you edit it.

Add a note that will help you identify the subscription, then save it. Return to Home and check whether the server list has been retrieved. If no entries appear, use the update option for that subscription and check the result. Saving a subscription link and successfully retrieving its contents are separate steps. The main check is complete only when selectable server entries appear.

Subscription updates may change the list and entry names based on the source. When importing for the first time, check the group and source; don't delete an existing entry just because its name looks similar. Before replacing an old subscription, confirm that the new one updates successfully and its servers work. Then clean up the old content so you still have a reference point if something goes wrong.

Have Individual Server Details? Check the Protocol and Fields

If your details are listed as individual parameters, choose the matching protocol in Add Server, then enter the address, port, and authentication details. Shadowsocks, Trojan, WireGuard, and other protocols require different fields. Don't reuse fields across protocols just because they all have an address and port. The address is usually a hostname or IP address, not a web URL. Enter the port as provided; don't guess based on common values.

Enter TLS, Server Name, and other transport options exactly as specified. The server address and the name used for TLS verification may serve different purposes, so don't swap them. Ask the provider of the original details about any missing required fields. Don't disable certificate verification just to save the entry, or substitute a seemingly usable public address.

After saving, return to Home and find the new entry in the SERVER list. Select the server you want to use. Open its edit page once more and check the protocol, port, and authentication fields. Seeing the entry means the details were saved, not that the server is reachable. Once selected, continue to Global Routing.

02 · Choose a Global Routing Mode

Open Global Routing from Home and check how requests are currently handled. This guide refers to the three modes as Config, Proxy, and Direct. This setting determines how requests are handled; it does not select a server protocol or supply missing connection details. Note the current mode before changing it so you can restore it after testing.

Config: Apply the Rules in the Active Configuration

Choose Config for everyday rule-based routing. Then open Config and confirm that the expected configuration is enabled. A configuration appearing in the list doesn't mean it's active, and the file you're editing may not be the one currently in use. If you're unsure, check the active indicator, then open the corresponding configuration to review it.

Config uses the rules in the active configuration to determine how requests are handled. A request may use PROXY, DIRECT, or REJECT, so turning on the connection doesn't mean every request will go through the proxy. Rules are usually evaluated in order, and the first matching rule affects the result. For the full structure, rule syntax, and final policy behavior, see the configuration reference. You don't need to rewrite the entire file for your first connection.

Proxy: Check the Proxy Connection Path First

To check whether the selected server can handle traffic, you can temporarily choose Proxy. Requests handled in this mode will go through the selected proxy server, making it easier to test without rule-based routing affecting the result. Use it for a specific, one-off comparison. It doesn't guarantee that every app or destination will be accessible on every network.

Before testing, confirm that Home still has the server you just checked selected. When you're done, switch back to Config if you rely on rule-based routing for everyday use, then test the destination again. Otherwise, subsequent results may reflect Proxy mode rather than the configuration rules you're trying to check.

Direct: Check Access Over Your Local Network

Direct sends requests to their destination without using the selected proxy server. It can help determine whether your local network can reach a service, but it can't prove that the proxy server works. If Global Routing remains set to Direct after you import details, a webpage opening successfully doesn't prove that the subscription is working.

At the end of this step, you should be able to explain which mode is selected and why: use Config for everyday rule-based routing, Proxy temporarily to check the proxy path without rule interference, or Direct to check local access. Once confirmed, return to Home and get ready to connect.

03 · Connect and Approve the System Prompt

Return to Home, check the selected server and Global Routing mode, then turn on the connection. The first time you connect, the system may ask to add a VPN configuration. This lets Shadowrocket create a system connection for handling network traffic. It is not a purchase step or a way to obtain server details.

Read the app name and prompt, confirm that it was triggered by your action, then allow it and complete any device authentication required. If you cancel, the client can't connect just by saving a server entry. To try again, return to Shadowrocket and initiate the connection once more, then follow the current system prompt. Don't repeatedly tap the switch to try to bypass confirmation.

After approval, wait for the status to stabilize and check the connection status on Home. The system VPN indicator only shows a connection status; by itself, it doesn't prove that a destination is accessible or that all requests are going through the proxy. If the switch turns off again immediately, note the message from the app and troubleshoot before changing protocols, routing, or configuration files.

If another system VPN connection is active on your device, disconnect it before testing this one. On organization-managed devices, network policies or configuration management may restrict these actions. Follow your device management requirements, and don't remove system configurations if you're unsure what they're for.

For your first test, stay on the same network—for example, use the same Wi-Fi throughout. Don't switch networks while checking whether the server works. A network change alters the connection conditions and can make a local network issue look like an error in your details. Once you've confirmed a connection, test other networks separately.

This step is complete when you've finished system approval, the connection status is stable, and the selected server and routing mode are still as expected. Next, use both a test and real-world access to verify the result.

04 · Verify with a Test and Real-World Access

On Home, find Connectivity Test and run it for the selected server. Treat the result as a reachability check for a specific test target, method, and current network. A result doesn't mean every service will work. If there is no result, don't immediately assume every protocol parameter is wrong; continue by checking actual access.

Then open a browser and visit a page you use regularly where it's clear whether access succeeded. Check that new content loads rather than relying on a cached page. Login, region, account, or server-side restrictions may also affect the result, so don't attribute every issue to Shadowrocket.

After confirming access, return to the app and check that the connection is still active. If request records are available, use them to verify how the destination was handled. In Config, check which rule matched and which policy was applied. If the request matched DIRECT, the page loading shows that the direct path works; it doesn't prove the selected proxy server handled the request.

To verify a rule, keep the destination and server the same, then inspect the configuration. First confirm you're viewing the active file, then check the rule order. A destination may make requests to several domains. If the homepage loads but some resources don't, identify which requests failed rather than judging all rules by the main domain in the address bar.

Changes to uploaded and downloaded traffic in Data can indicate activity, but they don't directly prove that a specific destination used a particular route. The totals may include background requests from other apps and may differ from your provider's usage accounting. For initial testing, prioritize actual access and the corresponding policy; the figures don't need to match exactly.

Note four brief details: the network, selected server, Global Routing mode, and how the destination behaved. Don't record your full password or subscription link. This lets you repeat the test under the same conditions after changing networks, updating a subscription, or editing rules, rather than relying on memory.

Before finishing, restore Proxy or Direct to your intended everyday mode, then revisit the same destination. If the result changes after switching back to Config, check the rules first. If both modes fail, continue with the network and server checks below.

05 · Troubleshoot Common Issues Step by Step

Change only one condition at a time and repeat the same test. If you update the subscription, switch networks, and then change rules, you won't know which step fixed the issue. Follow the checks below to distinguish an import problem from a failed connection or a rule that didn't match.

Subscription Saved, but No Servers Appear

First, confirm that your device has a working local network, then check that the subscription link is complete. If an update fails, read the message and distinguish between an unreachable link, expired authentication, and unrecognized content. A link opening in a browser only means that the browser received a response; it doesn't prove the response is an importable subscription. Don't use the address of a login or information page as a subscription link.

If a previously working link no longer updates, ask your provider to check its status and content format. A failed update doesn't necessarily remove existing servers, so distinguish between old entries still being present and the latest update succeeding. Don't clear the list until you've confirmed the status of the source.

Server Appears, but Connection or Access Fails

Reopen the entry's edit page and check the protocol, address, port, password, and other authentication parameters one by one. Copies can include extra spaces, and it's easy to mistake a note for an address. For TLS connections, check the specified names and make sure your device's date and time are reasonable. Don't relax verification requirements to hide incorrect details.

Next, confirm that Home has the intended entry selected, not an older server with the same name. Temporarily switch to Proxy and test the same destination. If it still fails, check your local network and the server separately. Don't delete every server after one timeout; an unreachable test destination doesn't always mean the entire connection is down.

Connection Is Stable, but Some Destinations Don't Work

First, check the current Global Routing mode. If access works in Proxy but not Config, check the active configuration and the rule matching the destination. Pay special attention to an earlier, broader rule that may match first, or to a REJECT result. Don't start by adding many duplicate rules. Find the rule that actually determines the policy, then make the smallest necessary change.

If domain names fail while other access works, consider DNS issues. Changing a server note or reordering the list usually won't help if the domain isn't resolving correctly. Note the failing domain and current mode. For more on DNS and rules, see the FAQ and configuration reference. Don't replace all your DNS settings at once during initial troubleshooting.

Connection Switch Won't Stay On, or It Reconnects After Being Turned Off

If the switch won't stay on, check whether system approval is complete, whether the app shows an error, and whether your device restricts connections. If it reconnects after being turned off, check whether On Demand is triggering it again. These are different issues and shouldn't both be attributed to an expired subscription. When reviewing system configurations, only change items you can clearly identify as part of this setup.

When asking for help, describe in text which step failed, the protocol, the current mode, and the results of Connectivity Test and actual access. Before sharing screenshots or logs, hide subscription links, passwords, keys, and account identifiers. Keep the error type and necessary field names so others can troubleshoot without exposing your credentials.

When troubleshooting is complete, restore temporary routing and test settings, confirm the active Config and selected server, then test real-world access once more. You should have a repeatable setup: the details imported successfully, the right server is selected, system approval is complete, and the actual routing behavior is as expected. Add On Demand or more detailed rules later, only if needed.