The Complete Shadowrocket Handbook: From the App Store to Daily Maintenance

Shadowrocket is a paid app on the App Store, and there is no second way to get it. This chapter covers three things: how to confirm in the store that you are looking at the genuine app, what a one-time purchase actually buys, and which devices it can be installed on.

When you search for Shadowrocket in the App Store, several similarly named apps can appear in the results. Don't judge by name — check three things on the store page: the developer field reads Shadow Launch Technology Limited; the app icon is a rocket with a white background and a blue-purple gradient outline; and the store page URL contains the app ID 932747118. All three must match — that is the app you want to buy.

Why the App ID Is Worth Remembering

The app ID is the unique number for every app in the App Store. Every store link on this site is written as https://apps.apple.com/us/app/shadowrocket/id932747118 — the id932747118 you see in the address bar is the same as the app ID in the store page information. If a page gives you a link with a different number, it does not point to Shadowrocket.

What a One-Time Purchase Actually Buys

Shadowrocket is sold as a one-time purchase. The US storefront price is about $2.99; other storefronts show the price in local currency, and the exact amount is whatever is displayed when you open the store page. What you buy is the client itself — the app that runs on iPhone and iPad. There is no monthly subscription fee afterwards, and no extra payment to unlock features.

Device Coverage and System Requirements

Shadowrocket is primarily an iPhone and iPad app, and it also appears in the compatibility section of the same App Store page, covering Mac, Apple TV, and Apple Vision. Whether a given device can install it depends on whether the Apple ID signed in on that device has already purchased the app, and on the compatibility listed on the store page at that time. For system version requirements, always go by what the App Store page states — minimum versions shift with OS releases, and any number hard-coded into a tutorial goes stale quickly.

After Buying: Purchases and Updates

Once purchased, the app appears in that Apple ID's purchase history. When you switch devices or reinstall, sign in with the same Apple ID and download it again from your App Store purchases — no second payment. Whether Family Sharing applies to this app is likewise subject to what the store page states.

Updates are distributed through the App Store. There is no separate update channel inside the app, and no files to replace by hand. Keep App Store automatic updates on, or occasionally tap update manually from your account page — that is all. This site will not and cannot provide any installer package — any source claiming to offer one has nothing to do with the genuine app.

Have Two Things Ready Before You Buy

Before you tap the buy button, have two things ready: your server details or subscription link (from your provider), and confirmation that the Apple ID signed in on the device is the one you normally use. The first decides whether you can use the app right after buying; the second decides whether you can get it back when you switch devices later. If you just want to look around the interface first, the app opens fine with no servers configured — the connect switch simply cannot establish a tunnel.

The first time you open Shadowrocket, the system shows several authorization prompts in a row. This chapter covers what each one does, whether to allow it, and how to recover if you tap the wrong button — plus a quick tour of the main interface tabs.

On first launch, the first prompt is usually the VPN configuration authorization. iOS names the requesting party and asks whether to allow adding a VPN configuration. After you allow it, the system creates a local tunnel configuration for Shadowrocket, and the connect switch works through that configuration.

Why the VPN Configuration Permission Is Needed

On iPhone and iPad, an app must use the system's network extension framework to route traffic through its own logic. Shadowrocket turns server details and rules into a system-level VPN configuration: traffic enters the tunnel from the system, the app decides by rule whether it goes through the proxy or connects directly, and hands it back to the system to send out. That is why a matching VPN configuration entry appears in the system Settings app — it is a real system-level item, not a simulated switch inside the app.

What Each of the Three Prompts Is For

• VPN configuration authorization (Add VPN Configurations): required. If you decline, the connect switch cannot work.
• Notification permission: used to show alerts such as connection status changes. Allowing or denying it does not affect proxy functionality.
• Local Network: only needed when other devices on the same LAN should reach the proxy port on this device. If you don't need that, you can decline.

Only the first of the three is required. If you tap "Don't Allow" by mistake, you don't need to reinstall: flip the connect switch again and the system will ask again. If no prompt ever appears, check the VPN section of the system Settings app for an existing configuration entry.

The Main Interface Tabs

Shadowrocket's main interface is organized into bottom tabs, and everything you do starts here:

• Home: server list and connect switch. The top shows the current Global Routing mode, the middle is the node list, and the bottom is the main switch.
• Config: configuration files and rules. Imported .conf files and rule lists are viewed and edited here.
• Data: traffic statistics. Two sets of readings, by server and by app — covered in Chapter 7.
• Settings: global options. On Demand, DNS, subscription auto-update, and more live here — covered in Chapter 8.

Interface terms stay in English: Home, Config, Data, Settings, Add Server, Subscribe, Global Routing, On Demand. When these words appear in the guide, they refer to that exact button or label in the interface; keeping the original wording lets you match them one to one instead of guessing at a translated equivalent.

A Recommended Setup Order

When configuring for the first time, follow this order — it makes problems easier to pin down than flipping switches at random:

1. First, check the Global Routing mode in Settings; the default, Config, is fine.
2. Go back to Home and enter your server details with Add Server or Subscribe.
3. Run a latency test on the node to confirm the details are correct.
4. Finally, turn on the main switch and verify with Connectivity Test.

The logic behind the order: the switch only establishes the tunnel, and whether traffic can actually pass depends on the server details and rules already being in place. Fill in the details before flipping the switch, and a failure narrows down to parameters or network instead of leaving you to suspect permissions, parameters, and rules all at once. One more note: there is nothing to set up for language or appearance on first launch — the interface follows the system language and dark mode, with no separate theme options.

There are two paths for getting server details into Shadowrocket: Add Server for a single server entered by hand, and Subscribe for importing a whole subscription. The two can coexist. This chapter covers what the fields mean, how updates work, and where mistakes are common.

Add Server: Adding a Single Server by Hand

On the Home page, tap Add Server to open the parameter form. The first field is Type, which determines which fields follow:

The table is only an illustration of common combinations. Fields vary with the Type and the transport selected — enter exactly what your provider gives you. Extra fields, missing fields, or guessing names from some other interface are the most common causes of connection failures. After saving, the node appears in the Home list.

Beyond Type, a few things are easy to overlook: the Remark only affects the display name, so use something recognizable; the TLS switch and fields like SNI, Path, and Host are only needed when your provider explicitly supplies them; and if your provider gives you a share link or QR code, use Scan QR Code to import it — far less error-prone than copying by hand.

Subscribe: Importing a Subscription

A subscription is a batch of servers packaged by your provider into a single link that the client fetches periodically. The entry point is Subscribe on the Home page: paste the subscription link, add a remark, save, then tap Update to fetch it for the first time. Once the fetch succeeds, the nodes appear in the list as a group.

Subscription links come from your provider and look like https://example.com/sub?token=xxxx. They usually carry an identity token and are equivalent to account credentials — don't post them publicly or forward them to anyone who doesn't need them. This site provides no subscription links; any address shown in the guide is a placeholder.

The difference between a subscription and a manual entry is how it updates: a subscription refreshes as a whole, so when your provider changes nodes you just tap Update again; a manually added node never changes on its own, so if the provider moves the address you have to edit it yourself. Both can coexist — a common approach is to pin your regular nodes manually at the top and leave subscription groups below.

When Subscriptions Update

There are two times a subscription updates: manually, and automatically if you enable it in Settings. The manual entry point is on the subscription group — open the group details and you'll see Update. Auto-update suits users whose subscription content changes often; the cost is one extra network request each time the app starts.

When an update fails, first tell apart "can't fetch" from "fetched but unusable": the former usually means the link has expired, the token changed, or the current network can't reach the subscription domain; the latter means the subscription content itself changed and you should check your provider's announcements. The full troubleshooting order is in Chapter 9.

Importing a Configuration from a File

Besides entering servers one by one, Shadowrocket can import configuration files: once you have a .conf file, choose Shadowrocket from the system share sheet and it imports into the Config page. A configuration file can contain a server list, rules, and general parameters at once, which suits users who already have a complete config. After importing, check the selected state at the top of the Config page — when several configs exist, only the selected one takes effect.

There is also an Import from Cloud JSON entry for restoring a configuration from cloud JSON. It reads configuration content you saved yourself, which is a different thing from a node subscription.

Latency Tests and Choosing Nodes

Each entry in the node list shows a latency reading; tap it to test again. The number is the round-trip time of a single probe — useful only for comparing nodes at the same moment, and not a measure of actual speed, since it tests neither bandwidth nor long-term stability. Connectivity Test runs a more complete round of checks and separates stages such as resolution and connection.

The list supports sorting and pinning. For daily use, keep two or three stable nodes at the top so you aren't hunting through a long list every time.

Global Routing decides where traffic in the tunnel goes by default — the setting most often misconfigured in Shadowrocket, and the one most worth understanding first. It has only three modes: Config, Proxy, and Direct.

Think of the relationship this way: the main switch decides whether the tunnel is open, and Global Routing decides how traffic moves inside it. Switching to Direct does not disconnect you — it just stops sending traffic through the proxy server. Switching to Proxy does not affect the system itself either; LAN addresses in the Bypass list still connect directly.

Config Mode: The Rules Decide

Config is the only mode you need to keep for everyday use. In this mode, Shadowrocket reads the rules on the Config page from top to bottom; the first matching rule decides whether the connection goes PROXY, DIRECT, or REJECT, and later rules no longer apply. Rule syntax and order are covered in Chapter 5.

Before switching to Config mode, make sure a configuration is selected on the Config page. With no configuration file, or a file with no rules, Config mode falls entirely to the fallback rule, and the result often differs from expectations — one of the common reasons a site won't open even though the proxy is on.

Proxy and Direct: The Two Temporary Modes

Proxy mode suits the "everything through the proxy today" case: all traffic not in the Bypass list goes out through the currently selected server, and rules play no part. The side effects are direct — LAN access that should be direct and nearby requests that should save bandwidth all take a detour, changing both speed and data use.

Direct mode is best understood as an "off state that keeps your configuration": the tunnel stays up, but no traffic enters the proxy. It suits occasions when you want to pause proxying temporarily without losing your current node selection. Remember to switch back to Config afterwards, or the next connection will keep using Direct.

How It Divides Work with On Demand

On Demand handles when the connection opens and closes automatically; Global Routing handles how traffic moves once it is open. The two are orthogonal: you can have On Demand connect automatically on cellular while Global Routing stays in Config mode and routes by rule. Adjusting the two together is a common starting point for configurations that get messier the more you tune them.

How to Check the Current Mode

The top of the Home page shows the current Global Routing mode. After you turn on the main switch, a VPN icon in the status bar only means the tunnel is up — it does not mean traffic is going through the proxy. Whether it actually does shows up in the Data page readings (Chapter 7).

A useful self-check habit: after changing Global Routing or your rules, open a domain that is explicitly listed in a rule, go back to the Data page, and see which set of readings its traffic lands in before deciding whether to keep editing.

Three Common Misconfigurations

• Leaving Direct on long-term as if it were "closing the app", which makes subscription updates and node latency tests behave oddly.
• Treating Proxy as "more thorough split routing" when it actually bypasses all rules.
• Running Config mode with no fallback rule, so traffic that matches nothing has unpredictable behavior.

Rules live in the configuration file on the Config page, always in the three-part form "type, argument, policy". This chapter explains what each type matches, why order matters, and gives a minimal snippet you can copy directly.

What a Rule Is Made Of

The basic structure of a rule is type,argument,policy. The type decides what is compared, the argument is what it compares against, and the policy decides where matching traffic goes. There are three policies: PROXY goes through the proxy, DIRECT connects directly, and REJECT blocks. For example, DOMAIN-SUFFIX,example.com,PROXY means: every request to example.com and its subdomains goes through the proxy.

Common Rule Types at a Glance

The difference between DOMAIN and DOMAIN-SUFFIX is worth remembering on its own: the former matches only the exact domain written out, while the latter matches it together with all its subdomains. Under DOMAIN-SUFFIX, example.com and www.example.com are covered by one rule; under DOMAIN, they need two lines.

Order: Top to Bottom, First Match Wins

The rule list is ordered. Shadowrocket compares from the first line down, and the first matching rule decides where the connection goes; later rules no longer apply. Two practical principles follow: put specific rules before broad ones — DOMAIN before DOMAIN-KEYWORD, for example — and keep the fallback rule FINAL on the last line, or it will shadow every rule after it.

GEOIP rules need the destination IP before they can judge its region, so they usually sit after domain-based rules — decide what can be decided by domain first, and hand the rest to the IP layer. This is the most frequently asked point about rule order.

A Minimal Snippet You Can Copy

[Rule]
DOMAIN,api.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,example,DIRECT
IP-CIDR,203.0.113.0/24,DIRECT
IP-CIDR6,2001:db8::/32,DIRECT
USER-AGENT,Example*,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY

The policy this configuration expresses: example.com and its subdomains go through the proxy, except api.example.com and requests containing the example keyword, which connect directly; two sample IP ranges connect directly; IPs in mainland China connect directly; everything else goes through the proxy. Replace the domains and ranges with your own targets — the format stays the same.

If you only want to proxy a few targets and connect everything else directly, change the fallback to FINAL,DIRECT and list the domains that need the proxy above it:

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,example,DIRECT
GEOIP,CN,DIRECT
FINAL,DIRECT

Neither approach is better; it depends on your habits: the first is "proxy by default, direct by exception", the second is "direct by default, proxy by exception". Pick one and your rule list will be much clearer.

REJECT and the Limits of Blocking

The REJECT policy blocks matching connections and is often used to block specific domains. Be clear about its limits: it only works on domains or IPs that can be matched; when an HTTPS connection is blocked, the result is a failed connection or a load timeout, not "filtered content"; and requests an app makes on its own, or those using domain fronting or custom resolution, may bypass the rules entirely. So don't treat REJECT as a general-purpose blocking solution — it is only a switch at the rule level. For more detail, see the site blog post Shadowrocket REJECT Policy: How Blocking Works and Where It Stops.

After Changing Rules

After saving rule changes, the configuration needs to reload: switch Global Routing once, or toggle the main switch off and on. When changes are extensive, verify one new rule on a small scale first and add the rest in bulk only after confirming it matches — writing dozens of lines at once and then troubleshooting backwards costs far more.

With details entered and rules in place, connecting and verifying is the last step. This chapter covers how to read the switch and status, what Connectivity Test checks, and the order to troubleshoot in when nothing connects.

Turning On the Connection and Reading Status

The switch at the bottom of the Home page is the main switch. Once on, a VPN indicator appears in the system status bar and the in-app switch shows as on. Both indicators only mean the tunnel is up, not that traffic is going through the proxy — for that, look at the Data page readings and the current mode.

Node selection happens in the list: tap a node row or the dot in front of it, and the current node is clearly marked. Switching nodes does not require toggling the switch; the tunnel rebuilds with the new node.

What Connectivity Test Checks

Connectivity Test checks several things in sequence: whether domain resolution works, whether the selected server can be reached, and whether reaching external addresses through the server succeeds. The results list the status of each stage separately, and a failure stops at the first stage that goes wrong.

Read the results from top to bottom: a resolution failure points to the DNS stage; a connection failure means the server address, port, or protocol parameters don't match; if resolution and connection both succeed but external access fails, the problem is more likely on the server side, and your provider's information is the reference.

How to Confirm Split Routing Is Really Working

Verifying split routing needs no extra tools — the Data page is enough:

1. Open a domain explicitly set to PROXY, go back to the Data page, and see whether the traffic lands in the current server's readings.
2. Open a domain explicitly set to DIRECT and confirm it does not increase the server's readings.
3. If the readings in step 2 are also climbing, go back to the Config page and check rule order to confirm no earlier rule is matching first.

This three-step self-check covers the vast majority of "the rule looks right but doesn't take effect" cases.

Troubleshooting Order When a Connection Fails

When nothing connects, rule items out in this order — far more effective than reinstalling the app over and over:

1. Permissions: confirm the VPN configuration authorization was not declined and that a matching configuration exists in the VPN section of the system Settings app.
2. Parameters: check Address, Port, Password, or UUID character by character against what your provider gave you, watching for case differences and stray spaces.
3. Protocol details: check that Type is correct and that fields like TLS, SNI, Path, and Host follow your provider's instructions.
4. Time: a device clock that is noticeably off can break the TLS handshake — set time to automatic.
5. Mode: confirm Global Routing is not sitting on Direct.
6. Subscription status: if the node comes from a subscription, update it once before judging.
7. Network environment: try a different network (switching from Wi-Fi to cellular, for example) to rule out restrictions on VPN traffic in the current one.

The first four of the seven steps cover most failure cases. If everything still fails, compare the Connectivity Test results with your provider — the problem is most likely on the server side or with the account, beyond what the client can fix.

Intermittent Drops

Connecting but dropping now and then usually relates to network switching, node load, or rule conflicts. Start by observing when the drops happen: if they happen when switching between Wi-Fi and cellular, the tunnel is likely being rebuilt by the network change; if they happen at fixed times, the node side may be at fault; if they happen only in a specific app, go back to your rules and check whether that app's domain is REJECTed or wrongly pointed at a direct connection.

The Data page counts traffic through the tunnel along two dimensions: by server and by app. This chapter explains what each set counts, why they don't match the system's numbers, and the order to use them in when tracking down unusual traffic.

What the Two Sets of Readings Are

The by-server set counts the upload and download traffic each node carries; its use is telling which line traffic goes out through, and it is the most direct way to choose between several nodes. The by-app set counts the traffic each app produces; its use is telling who is using the traffic.

Both sets use B, KB, MB, and GB, converted in base 1024, and the interface usually shows upload and download in separate columns. Note that this counts traffic through the Shadowrocket tunnel, not everything the device's network interface sends and receives.

Why They Don't Match the System's Numbers

The cellular data figures in the system Settings app and the readings on the Data page often differ, for three reasons:

• Different scope: the system counts at the network interface level, including all direct traffic and the system's own requests; the Data page counts only what enters the tunnel.
• Different time windows: the system accumulates over a billing cycle or since a manual reset, while the Data page counts from your last reset or install.
• Different handling: some protocols add extra encapsulation, so a normal difference exists between in-tunnel counts and actual interface counts.

With all three combined, the two sets of numbers differing is normal — no need to conclude the stats are broken. To judge plan usage, go by your provider's dashboard; the Data page is better suited to relative comparisons.

Using It to Track Down Unusual Traffic

When traffic consumption looks off, work through "total → server → app → rules":

1. First check the overall rate of increase to see whether the anomaly is continuous or concentrated in one period.
2. Then look at the by-server readings to find the node carrying the most traffic.
3. Next, look at the by-app readings to pin down the specific app.
4. Finally, go back to the Config page and check whether that app's domain should have gone DIRECT but is being pulled to the proxy by an earlier rule.

Step 4 is the one most often skipped and most likely to produce an answer: many cases of "traffic mysteriously increasing" trace back to a broad rule sending requests that should be direct through the proxy. For more on these readings, see the site blog post Reading Shadowrocket's Data Page Traffic Stats.

Resetting and Recording

The Data page offers a reset entry, and counts start from zero after resetting. Reset before and after changing rules and compare the two segments — easier than staring at cumulative numbers to see whether a change took effect.

One last reminder: the traffic stats on the Data page and your plan usage are two different things. Remaining quota, billing cycle, and overage policy are all decided by your provider — go by the provider's dashboard. The client can only see the part that passes through it.

The Settings page gathers the global options that don't change with the node. This chapter picks out the few you'll actually touch day to day and explains what each one solves and when it needs changing.

On Demand: Connecting as Needed

On Demand decides when the app connects and disconnects automatically. Triggers fall into three categories:

• Wi-Fi: matches by the name of the connected Wi-Fi network, so you can have some networks connect automatically and others disconnect automatically.
• Cellular: connects automatically on cellular data, often used for "turn on when I leave home".
• Domain: triggers a connection when specific domains are accessed, suited to judging by target rather than by network.

The three kinds of conditions can be combined, and combining them is an OR relationship: any one matching triggers the action. A common misconfiguration is writing two contradictory conditions — for example, disconnecting on Wi-Fi while also connecting by domain — which shows up as the connection state flipping back and forth. After setting it up, verify once in a real network-switching scenario. For more on the parameters, see the site blog post Shadowrocket On Demand: Setting Up Wi-Fi, Cellular, and Domain Triggers.

DNS

DNS settings decide which path domain resolution takes. Following the system default is enough for most cases; when you need a specific resolver, enter its address here. Changing DNS directly affects how domain-based rules are judged, so run the three-step self-check from Chapter 6 afterwards.

One reminder: DNS and split routing are two layers — the domain is resolved to an address first, and then rules decide how the connection goes. If resolution goes wrong, even perfectly written rules won't take effect.

Bypass and the Local Network

Addresses in the Bypass list never enter the tunnel; common examples are LAN ranges and the device's own address. The defaults already cover the usual private ranges, so there is no need to change them unless you have a specific LAN service to reach. Accidentally adding a public address to Bypass sends traffic that should go through the proxy straight out.

Subscription Auto-Update

This controls when subscriptions refresh: auto-update when on, and periodic auto-update. Users whose subscription content changes often should enable it; those with stable subscriptions can turn it off to reduce the network request at each launch. Either way, manual Update is always available.

Proxy Port and LAN Sharing

Shadowrocket can listen on a proxy port on this device for other devices on the same LAN to use. Enabling it requires allowing the Local Network permission (the third prompt mentioned in Chapter 2). This feature has a clear use case: turn it on only when you actually need to provide a proxy to another device, and turn it off when done.

Logs and Diagnostics

The log switch records connection activity. For hard-to-diagnose problems, turn it on, reproduce the issue once, then turn it off and compare the log with your provider. Leave it off day to day — keeping it on only takes up space.

iCloud Sync and Backup

Configurations can sync between devices through iCloud. With it on, you don't have to reorganize rules when switching devices; with it off, nothing breaks — you just export and import manually. Either way works; the key is to pick one and stay consistent, so rule versions on two devices don't overwrite each other.

Settings You Don't Need to Touch

Settings also holds a batch of switches for appearance, notifications, and experimental features. Most have sensible defaults, and leaving them alone when you have no clear need is the simplest way to keep a configuration predictable. Before changing anything, ask what problem it solves; changes with no answer usually turn into fresh confusion a few weeks later.

The final chapter covers daily maintenance: how to investigate a failed subscription update, what to do when a node stops working, how to migrate to a new device, and which operations you don't actually need to perform.

Troubleshooting Order for a Failed Subscription Update

1. The link itself: confirm the subscription link has no missing characters, has not expired, and matches what your provider currently offers.
2. Network reachability: the subscription domain itself may require a proxy to reach — connect to a working node first, then update.
3. Response format: if the update succeeds but the node list is empty, the response is not in a format the client recognizes — check with your provider.
4. Account status: go by the status shown on your provider's dashboard; the client cannot see account-side information.

If all four steps fail, send your provider the exact message shown during the update — far more useful than describing it as "not working". For more on common causes, see the site blog post Shadowrocket Subscription Updates: Manual Refresh, Auto-Update on Launch, and Why They Fail.

When a Node Stops Working, and Switching

When a single node won't connect, test its latency once, then switch to another node for comparison. If several nodes under the same subscription fail at once, suspect the subscription needs updating or the account status changed rather than checking node parameters one by one. Constantly switching among many nodes does not improve stability; keeping two or three working nodes and leaving the rest as backups is the easier state to live in.

Maintaining Rules and Configurations

Rules are the part of a configuration that accumulates the most clutter. Do a cleanup now and then: delete domain rules you no longer visit, merge duplicates, and confirm the fallback rule is still on the last line. Export the current configuration as a copy before editing — config files are tiny, so backups cost almost nothing.

If your rules reference remote lists, keep an eye on how often the lists themselves update; when remote content is unreachable, the rules already stored locally keep working and connections won't break. For a systematic explanation of rule syntax, see the site blog post Shadowrocket Rule Syntax: What DOMAIN, GEOIP, IP-CIDR, and FINAL Each Match.

Switching Devices and Reinstalling

When moving to a new device, first download Shadowrocket again from your App Store purchases with the same Apple ID, then sync from iCloud or import your previously backed-up configuration, and finally re-enter the subscription link (subscription links are account credentials, so what gets synced depends on your own backup method).

Before reinstalling the app, confirm your configuration has been exported. Uninstalling wipes the local configuration along with it, and there is no undo.

App Updates and System Upgrades

App updates go through the App Store like any other app. If connection behavior changes after a major system upgrade, first check whether the VPN configuration authorization is still valid, then run the seven-step order from Chapter 6 — permissions being reset after an upgrade is a common occurrence, not a sign the app is broken.

Three Common Misconceptions

• Treating the client as a line: buying the app does not come with any traffic; nodes and subscriptions always come from your provider.
• Treating "connected" as "the line works": the status bar icon only means the tunnel is up; whether traffic actually passes shows in the verification results.
• Treating rules as an all-purpose switch: rules only decide how traffic goes — they cannot change server-side status or replace the service your provider offers.

Where to Go Next

This page covers the complete workflow. If you just want to get running quickly, go back to the five-step walkthrough in the tutorial; for specific problems, the FAQ page organizes Q&A under four headings — verifying the genuine app and buying / installing and first launch / subscriptions and node import / rules and troubleshooting; and to go deeper on one topic, look for feature articles in the blog.