Shadowrocket Server Setup, Routing, and Connection Verification

Preflight checks: Confirm that your information is complete

Before your first setup, sort the information you already have into two categories. The first is a single server profile, usually including the protocol, server address, port, and authentication fields; some protocols may also require transport, TLS, SNI, Public Key, Private Key, or other parameters. The second is a subscription link supplied by your provider for importing and updating multiple server records. Choose one import method; there is no need to add the same information twice.

After opening Shadowrocket, stay on Home. This page shows the current server, lets you choose a connection target, set Global Routing, and control the connection switch. The bottom Config tab manages rule configurations, Data shows connection records, and Settings contains client options such as DNS, On Demand, and Log. Learn these entry points first to avoid moving to the wrong screen later.

If Shadowrocket is not installed on the device, first check the product page through the App Store download guide on this site. The developer should be Shadow Launch Technology Limited, and the app ID is 932747118. For iPhone, iPad, and other Apple devices listed in the store compatibility section, system requirements are as stated on the App Store page. The rest of this guide covers basic operation on iPhone and iPad only.

Add a Server or Import an Existing Subscription

From Home, open Add Server. Choose the path that matches your information: use manual entry if you have a defined set of server fields; open Subscribe if you have a subscription link. After completing either path, return to Home and confirm that the server entry appears before configuring Global Routing.

Path 1: Enter the details manually with Add Server

In Add Server, first choose the protocol that matches your information, such as Shadowsocks, VMess, VLESS, Trojan, HTTP, SOCKS5, WireGuard, or Hysteria2. Protocol names identify different entry types and cannot substitute for one another. Enter the server address, port, and authentication fields exactly as provided. Fill in additional fields only when your provider has supplied the corresponding values.

Watch for three common input problems. First, do not include spaces before or after the server address, and do not copy explanatory text into the field. Second, enter the port in the port field rather than combining it with the address. Third, preserve the exact capitalization of case-sensitive authentication data. Save the entry, return to Home, find it in the SERVER list, and select it. The selected server is usually shown with a distinct list state.

If your existing information is saved as a QR code, use Scan QR Code from the relevant entry point. Confirm that the QR code comes from your own server information before scanning. After recognition, open the entry and check the protocol and key fields to avoid proceeding with expired QR content. If you have compatible Cloud JSON, use Import from Cloud JSON; then return to Home and check the entry as well.

Path 2: Import through Subscribe

In Add Server, open Subscribe, enter a name you can recognize, then paste and save your existing subscription link. Run an update and wait for Shadowrocket to parse it. After a successful update, the server list in Home should show entries from the subscription. If nothing changes, do not immediately create another copy; open the existing subscription, confirm that the link is complete, and check for an update error.

A subscription updates server records; it does not mean the connection is already active. After importing, select a specific server from Home and configure Global Routing and the connection switch. When the subscription changes, update the existing record instead of creating the same link again. This avoids duplicates and makes it easier to identify the information currently in use.

The completion criterion is simple: after returning to Home, you can see at least one server entry created from your own information and select it. If Add Server saves nothing or Subscribe updates to an empty list, the problem is still at the import stage; there is no need to adjust DNS or Config yet.

Choose a Global Routing mode

Once the server entries are ready, return to Home and find Global Routing. This determines the basic way traffic is handled. Shadowrocket commonly offers three modes: Config, Proxy, and Direct. They serve different purposes, so decide first whether you are testing the server itself or setting up rule-based use.

For a first setup, use Proxy for a basic connectivity check. Once the selected server works, switch to Config and observe whether routing follows the expected rules. This separates a server connection problem from a rule-matching problem and makes troubleshooting clearer.

Before selecting Config, open the bottom Config tab and confirm that the required configuration file is selected. An empty or unselected file, or rules that do not match the intended use, can send requests somewhere unexpected. Rules are usually matched in order, so more specific rules should be placed appropriately; unmatched requests are then handled by rules such as FINAL. For more on rule syntax and DNS interaction, see the Settings guide.

Turn on the connection and complete system authorization

Stay on Home, confirm the current server name and Global Routing again, then turn on the connection switch. The first time a connection is established on the device, the system asks for permission to add a VPN configuration. Confirm the prompt shown by iOS or iPadOS and complete the required device verification. Without system authorization, Shadowrocket cannot create the corresponding system network configuration.

After authorization, return to Shadowrocket and wait for the connection status to settle. Do not rapidly switch between servers, Config, and Global Routing immediately after turning the switch on; changing several variables at once makes the cause of a failure difficult to identify. If the status quickly returns to disconnected, note the selected server and mode, then continue to verification instead of judging every network component by the switch color alone.

Even after authorization, changes in system settings may require permission to be confirmed again. Turn off the connection, wait a few seconds, and turn it on again. If it still will not stay connected, check whether the device has a working Wi-Fi or cellular connection. Shadowrocket first depends on a functioning local network; changing Global Routing usually cannot fix a basic local network failure.

Do not enable On Demand immediately after establishing the connection. On Demand starts the connection automatically under specified conditions and is better configured after the manual workflow is confirmed. During initial troubleshooting, keep the switch manual so each action is easy to track. For long-term On Demand use, configure it in Settings after completing the basic flow and see the On Demand guide.

Verify the result with Connectivity Test

Once the connection switch is on, first confirm that the Home status is stable, then run Connectivity Test for the current server. The same function is available from the server entry actions; if the current layout places it in a related menu, use the English interface label Connectivity Test as the reference. The test checks the server connection path, but one test result cannot replace verification through actual access.

Next, open a page or app that you actually need to use and check whether it loads normally. Return to Shadowrocket and see whether new connection records appear in Data. With Config, also check which rule matched and whether the request used PROXY or DIRECT. If connection records appear but the page does not finish loading, the system switch is working; the issue may be with the server response, DNS, routing policy, or target service.

For more detail, open the Log entry in Settings. Log can help confirm DNS resolution, rule matches, connection establishment, and failure messages, but it may contain domains, server addresses, and other runtime information. Review it before sharing it with anyone. After troubleshooting, adjust logging for your needs rather than keeping the most detailed level enabled permanently.

Use the following order to assess the result instead of relying on a single status:

1. The expected server is selected in Home, and the connection switch remains on.
2. Global Routing matches the test purpose; it is not Direct when verifying a server.
3. Connectivity Test completes the relevant check or provides a clear diagnostic message.
4. The actual page loads, and new connection records appear in Data.
5. With Config, the matched rule and its PROXY or DIRECT result match expectations.

If access works under Proxy but fails under Config, the server itself has usually passed the basic check. Focus on the configuration file, rule order, policy names, and DNS. If Proxy also fails, check the server fields, local network, and subscription status first rather than rewriting rules.

Common failure points: Check each layer in order

Different problems can look alike: the switch may not stay on, a test may fail, a page may load indefinitely, or only some domains may be unavailable. Start with the outermost layer, change one variable at a time, and repeat the same verification after each change. The sequence below covers the areas most often involved during first use.

1. No server entry appears in Home

Return to Add Server and check that saving completed. For manual entry, confirm that the protocol, server address, and port were saved. For Subscribe, open the existing subscription, run an update, and look for a parsing message. Do not create multiple records with the same name, as this makes later selection harder. An expired subscription link, changed authentication information, or service-side issue must be checked with the provider that supplied the information.

2. The server appears, but the connection switch will not stay on

Confirm that the device has a working local network, then check that system authorization is complete. Turn the switch off, wait until the connection has fully stopped, and turn it on again without repeated rapid taps. If the behavior changes on another network, record the results separately for Wi-Fi and cellular data. Then check the selected server's protocol, address, port, and authentication fields, paying particular attention to spaces or omissions introduced during copying.

3. Connectivity Test fails

Temporarily set Global Routing to Proxy and test a server whose details are known to be complete. If several servers fail, check the local network, subscription update status, and shared fields first. If only one entry fails, focus on that entry's individual parameters. Connectivity Test is a diagnostic tool; repeated tapping is not a substitute for checking the fields.

4. Proxy works, but access fails under Config

Open Config and confirm that the configuration file is selected and the policy names exist. When rules are matched from top to bottom, a broad rule near the top may take over before a more specific rule can apply. Use Data or Log to see whether the target matched DOMAIN, DOMAIN-SUFFIX, GEOIP, IP-CIDR, or FINAL, then decide which rule to adjust. Do not delete an entire rule set at once, or comparing the results before and after will be difficult.

5. The test returns a result, but the webpage still will not open

Treat DNS as a separate layer in this case. A successful server test only shows that some connection conditions are met; it does not guarantee that domain resolution completed. First determine whether all domains fail or only certain domains, then check Log for resolution-related messages. DNS settings, remote resolution, and rules interact; see the DNS settings reference for the relevant fields and troubleshooting order.

6. Some apps work, but some requests fail

With Config, first check which policy matched the failing requests. Some connections may match DOMAIN-SUFFIX while others fall through to GEOIP or FINAL, so one app can produce different results internally. After confirming the rule, check whether its policy points to the currently working server. If only specific targets fail even under Proxy, retain the test time and error type from Log to distinguish a target-service issue from a client configuration issue.

7. Servers change after a subscription update

An update refreshes the related records according to the subscription content. After updating, return to Home, confirm the selected server again, and run Connectivity Test. If the original entry is no longer listed, do not continue troubleshooting by its old name. Keep servers entered manually in separate entries rather than mixing them with records created by subscription updates.

Setup order after basic connectivity is confirmed

The basic flow is complete when the Home connection switch stays on, Connectivity Test returns a clear result, actual access works, and Config matches the expected rules. Only then adjust DNS, On Demand, Ping, Log, Widget, iCloud sync, or the Proxy port as needed. Do not change all of these while basic connectivity is still unconfirmed.

The recommended next steps are to lock in a verified server first, confirm the Config rules next, check DNS afterward, and enable conveniences such as On Demand or Widget last. This gives each layer a comparison baseline. If a later change causes connection problems, return to the Proxy verification step in this guide, confirm that the server still works, and then inspect the newly changed setting.