Shadowrocket Setup Steps

Add Server and Import a Subscription

Open Shadowrocket and go to Home. The goal is to add your server details to the list, not to turn on the connection yet. First, identify what you have: a subscription link usually provides a set of server entries, while details for a single server include its protocol, address, port, and authentication information. Choose either method; there is no need to add the same details twice for this guide.

Have a Subscription Link? Use Subscribe

In Home, tap the add button in the upper-right corner to open Add Server. Choose Subscribe under Type and enter your complete subscription URL in URL. You can add a note to identify its purpose later, then save and return to Home. Before and after pasting, check that the URL is complete, especially for missing trailing parameters or extra spaces. Make sure you haven't copied a webpage title or instructions along with it.

After saving, check the subscription group and its server entries. A subscription must retrieve and parse remote content, so seeing the group name does not mean the server list has been generated. If the group appears without any entries, use the update action for that subscription and wait for the request to finish before checking again. Don't add the same link repeatedly; that only creates duplicate groups and won't fix an expired URL or unexpected response.

A subscription URL may contain personal access credentials, so treat it as sensitive information. If you need to check it, ask your service provider whether the URL is still valid, supports Shadowrocket, and has any additional usage requirements. Don't post the full URL in public comments, screenshots, or troubleshooting notes. Keep only the error message and where it appeared when documenting an issue.

Have Details for One Server? Check the Type and Parameters

If you have details for a single server, start with Add Server and choose the specified protocol under Type, such as Shadowsocks, VMess, VLESS, or Trojan. Fill in the address, port, and relevant authentication details as shown. Required fields vary by protocol; don't copy a password, UUID, or transport setting from one protocol into another protocol's form.

For TLS, Server Name, or other transport settings, use the details you were given rather than guessing based on the server address. The address may be a domain name or an IP address; enter the port in its own field instead of pasting an entire block of instructions. Save, return to Home, and select the entry you want to use. For now, confirm only that the entry exists and matches the original details. Test access in the connection verification step.

Turn On the Connection

Return to Home and confirm the selected server, Global Routing mode, and—if you're using Config—the active profile. Once everything is set, turn on the main connection switch. Avoid toggling the connection repeatedly while changing configurations, updating a subscription, or editing unsaved parameters; it will be difficult to tell which settings were used for each test.

The first time you connect, the system may prompt you to add a VPN configuration. This authorization lets Shadowrocket use the system's network features; it doesn't mean the app has automatically obtained a working connection service. Review the prompt, allow it if you want to continue, and complete any authentication required by your device. Then return to Shadowrocket to check the switch and the connection status shown in the app.

If you canceled authorization, try connecting again in the app and follow the prompt that appears. If your device is managed or restricted by system settings, check the relevant restrictions rather than repeatedly tapping through. The VPN settings label and location may change between system interfaces, so follow what your device currently shows. You don't need to change unrelated settings for this guide.

After a connection is established, the system may show a VPN indicator. This indicates the system's network connection status; it doesn't verify access to a remote server or prove that every request is routed through a proxy. In particular, seeing the indicator in Config or Direct mode doesn't prove that rules are routing traffic correctly. Keep the current settings and continue to the verification steps instead of stopping at “the switch is on.”

Verify the Connection and Rules

Check three things separately: whether the server responds to a test, whether the services you need work, and whether requests follow the expected policies. These results are related but aren't interchangeable. Follow the order below to distinguish underlying network issues, destination service problems, and rule issues.

Run Connectivity Test First

In Home, run Connectivity Test to see the result for the selected server. It can provide an initial indication of whether the test path is reachable, but its target and method may differ from real requests made by your apps. A successful test doesn't guarantee every website or app will work, and a failed test needs to be considered alongside the test method, current network, and server details.

When noting the result, record whether it succeeded or failed and any error message; don't treat a single test duration as a measure of service quality. If every entry fails, first confirm that the device can access the internet, then check the subscription and connection details. If only one entry fails, check its parameters and the status of the corresponding server first.

Then Check Real-World Access

Keep the connection on and use a browser to visit a service you actually need. Check that the page loads and that essential actions work. Make a new request rather than relying on a page that's already open; caching can make an old page look successful without generating new network traffic. If only one app fails, also consider issues with its login, permissions, or service status.

For a before-and-after comparison, use the same device, network, and destination, and change only one factor at a time: connection status or routing mode. Changing networks, switching servers, and editing rules at once makes the comparison meaningless. After confirming access, check whether traffic is routed as intended. A page loading shows that the service works, but doesn't fully confirm which policy handled the request.

Finally, Check Data and the Matching Policy

Open Data and review the request information currently shown. Use the destination, time, and policy to determine how the request was handled. Refer to the records available in the current app interface. Find the request you just made and compare it with the rules in Config. If there's no matching record, first confirm that the request was actually sent again rather than immediately changing rules.

For a destination expected to use DIRECT, confirm that the corresponding policy was applied. For one expected to use PROXY, check the selected server and policy references. REJECT blocks matching requests, but it doesn't guarantee that all similar content disappears from an app. If a rule interferes with normal operation, identify the specific request and matched rule, then make the smallest change possible. Don't delete the entire configuration.

Request records may include personal information such as domain names. Keep only what is needed to diagnose the issue, and remove credentials and unrelated requests before sharing troubleshooting materials. After these three checks, the expected result is that the service works, the routing mode matches your needs, and representative requests use the intended policies.

Troubleshoot Common Issues

When something goes wrong, focus on the step where it failed instead of deleting everything and starting over. Use the checks below in order, changing one thing at a time and retesting. Keep the last working settings so you can identify which change affected the result.

Subscription Saved, but the List Is Empty

Open the subscription entry and check that the URL is complete and points to subscription content, not an information page that requires a login. Then update it once and note the app's message. If the response is a webpage, an access error, or unexpected content, the list may not populate. Ask your service provider to verify the URL and response format instead of changing Subscribe to a server protocol at random.

An update failure and missing existing entries are different issues. If your existing entries are still there, keep them and note when the update failed. Don't clear everything just to retry. After subscription content changes, confirm that the selected entry is still the one you need; an unchanged group name doesn't tell you whether its contents changed.

Server Entry Present, but Connectivity Test Fails

First confirm that your device's current network is working. Then check that Type, address, port, and authentication fields match your original details. If the details specify TLS or transport parameters, verify those too. Don't toggle every setting repeatedly in the hope of fixing it; that turns a clear parameter issue into several unknowns.

If another existing entry works, use it for comparison. If the same entry fails only on a particular network, note the network and error message, then check for network restrictions or differences in name resolution. A single Connectivity Test result is only a clue; verify it against real-world access as well.

Connection Is On, but a Destination Won't Load

First confirm that system authorization is complete and the app isn't disconnecting immediately. Then check that Global Routing is set to the mode needed for your test. In Direct mode, selecting a server doesn't mean requests pass through it. In Config mode, check the active configuration rather than simply opening a file with the same name. If useful, switch briefly to Proxy for comparison, then restore your original mode.

If Proxy works but Config doesn't, check rule order, policy references, and settings related to the destination. If both fail, check the server, underlying network, and destination service. The presence of a VPN indicator alone doesn't rule out these issues.

Behavior Changed After an Update, or After Disconnecting

A subscription update can change server entries, while a configuration update can change rules; track them separately. First identify what was updated, then check whether the current selection matches the previous one. If the connection returns after you disconnect manually, review whether On Demand is enabled and check its triggers. If only the page looks unchanged, make a new request and consider caching; don't treat old page content as a new connection result.

To continue troubleshooting, note four things: which step failed, the current Global Routing mode, whether the issue affects only one destination, and the one thing you changed most recently. Don't include your full subscription URL, password, or other authentication details. For purchases, store region, or restoring purchases, see the App Store Guide. For protocol and rule keyword explanations, see the Glossary. You don't need to change every setting to complete your first connection.