Shadowrocket Rules Reference

Configuration structure and loading scope

A Shadowrocket configuration file can contain multiple sections marked with square brackets. The section name determines how the lines that follow are interpreted; it isn’t just a visual grouping. A domain rule under [Rule] and an address mapping under [Host] can refer to the same domain but serve different purposes. Before editing, check which configuration is active, then edit the relevant section. Saving a file to the Config list doesn’t automatically select it.

First, distinguish server details, subscriptions, and configuration

Server details specify where to connect, which protocol to use, and how to authenticate. A subscription retrieves and updates these entries in bulk. Rules determine how different requests are handled. These may all be part of the same workflow, but they aren’t interchangeable. A working server connection doesn’t mean a rules file is active, and a readable rules file doesn’t guarantee that its referenced proxy is available. If an import doesn’t produce the expected result, first determine whether the missing piece is a server entry or traffic-routing configuration.

When checking a file in Config, note its name, whether it’s selected, and where it came from. Updates to a remote file may overwrite local changes, so keep an untouched copy before experimenting. Don’t replace the entire contents with an online snippet before you understand the original configuration. The examples on this page explain syntax only; they contain no authentication details and aren’t complete, ready-to-connect configurations.

What each section does

[General]
dns-server = system

[Rule]
DOMAIN,portal.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,PROXY

[Host]
fixed.example.com = 192.0.2.10

The 192.0.2.10 above is a documentation example, not a usable server. When reading this snippet, check the section name first, then how each line is delimited: General and Host use an equals sign for key-value pairs, while Rule typically uses English commas to separate the rule type, condition, and policy. Full-width commas, invisible spaces, or punctuation copied from rich text can turn apparently identical content into different input.

Make a short checklist before editing

Note the current Global Routing mode, then check which server is selected in SERVER and which file is active in Config. Recording all three helps distinguish an exit change from a rule change. To compare before and after, change one condition, save, and run the connection test again. Don’t change the server, DNS, and rule order at the same time, or you won’t know what caused the result.

When evaluating a configuration, distinguish between “parses successfully” and “does what you want.” The first only means the syntax was accepted; the second requires testing real requests. For example, a domain rule placed after FINAL may be syntactically valid but never handle requests already caught by the earlier fallback. Conversely, a comment may describe the intended behavior clearly, but comments don’t affect matching. Check the rules that are actually active.

General, DNS, and rule inputs

General affects the environment in which rules run. How domains are resolved and which destinations use the system network path can change the request information available to later rules. So don’t inspect the Rule section in isolation. The same rule may produce different results under different resolution conditions, especially GEOIP, IP-CIDR, and IP-CIDR6, which depend on the destination address. Treat DNS resolution and routing as separate stages before deciding what to change.

DNS resolution isn’t policy selection

DNS translates domain names into addresses; traffic policies determine how connections are handled. A successful DNS lookup only confirms that an address was returned. It doesn’t tell you whether a request will use PROXY or DIRECT. Domain rules don’t necessarily need an address to match: if the client knows the destination domain, it can match DOMAIN or DOMAIN-SUFFIX directly. Address rules need a destination address, so the two types have different input requirements.

[General]
dns-server = system

[Rule]
DOMAIN,portal.example.com,DIRECT
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
FINAL,PROXY

dns-server = system means this setting uses the system-provided DNS. It’s a useful starting point for understanding the syntax, not a universal recommendation. If the existing configuration specifies another resolution method, note what it’s for before changing it; don’t overwrite it just to match the example. Network changes, system DNS status, and how the destination service is deployed can all affect the address returned.

What no-resolve does

The no-resolve option at the end of an address rule means not to trigger a DNS lookup solely to try that rule. It doesn’t disable DNS or prevent the connection from being resolved later. If the request already has a usable destination address, the rule can still evaluate it. If the request has only a domain name and no corresponding address is available, this rule can’t create one to match; later rules may still process the request.

This distinction matters when troubleshooting: after adding no-resolve, a domain no longer matching an address rule doesn’t necessarily mean the address range is wrong. There may simply be no address available when matching occurs. Don’t remove every instance of no-resolve just to force a match. First determine whether the request targets a domain or an IP address, then check whether resolution is needed and weigh its cost against the routing goal.

Caching, network changes, and timing

Browsers, apps, the operating system, and the client may each retain DNS or connection state. After changing DNS, a page refresh may reuse an existing connection and fail to show the new setting. Start a new request when testing; if needed, close the app’s existing session and clear relevant caches using the app’s available options. One unchanged refresh doesn’t prove the configuration failed to load; likewise, one successful request doesn’t prove the issue is fixed.

After switching between Wi-Fi and cellular, check that the underlying network is working. If the system itself can’t reach a known-accessible destination, changing Rule settings is unlikely to fix the underlying connection problem. You can briefly compare results in Direct mode, then return to Config to test the rules. Restore your usual mode when the comparison is done so a global direct connection isn’t mistaken for rule-based routing.

Don’t treat bypass scope as an ordinary Rule

Some General settings determine which traffic enters the subsequent processing path. They aren’t equivalent to DIRECT in Rule. Expanding the bypass scope may keep requests from reaching the rules you expect, so the presence of FINAL doesn’t mean every request will reach that fallback. Before changing these settings, review the existing file notes and in-app options. If you’re unsure what a setting does, preserving its current value makes results easier to reproduce than removing settings in bulk.

For IPv6 issues, check whether the domain returns addresses from both address families. An IPv4-only address rule won’t necessarily cover IPv6 requests. Prefer domain rules that accurately describe the intended scope, then add address ranges only when needed. Don’t disable an address family as a first step; record the actual destination address to determine whether the issue lies in resolution, matching, or the connection path.

How DOMAIN rules match

Domain rules are often a better way to express traffic-routing intent than changing destination addresses that may vary, provided the client can identify the destination domain when matching. DOMAIN, DOMAIN-SUFFIX, and DOMAIN-KEYWORD differ mainly in scope, not in which one is “stronger.” Before choosing a rule, define exactly which domains you want to cover, then use the narrowest condition that fits. Avoid adding broad matches just to save a line.

DOMAIN: match one exact domain

[Rule]
DOMAIN,login.example.com,DIRECT
DOMAIN,api.example.com,PROXY
FINAL,PROXY

DOMAIN matches an exact domain. The first rule applies only to login.example.com; it doesn’t automatically include example.com or cdn.login.example.com. Use it to handle a standalone login endpoint or API domain. Enter only the domain as the rule condition—don’t include a scheme, port, or path. Pasting a full web address won’t turn a domain rule into a path rule.

If you want to handle one API request differently while leaving other paths on the same domain unchanged, DOMAIN can’t express that level of detail. First decide whether path-based handling is truly needed; adding a slash after the domain won’t achieve it. A domain rule selects a connection policy, and matching a login domain doesn’t automatically handle other domains the login process may rely on.

DOMAIN-SUFFIX: match the root domain and subdomains

[Rule]
DOMAIN,portal.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT

DOMAIN-SUFFIX matches a domain suffix at a label boundary. Here, example.com covers the root domain and its subdomains, such as www.example.com and a.b.example.com. It doesn’t match any name that happens to contain the same characters. notexample.com isn’t within this domain boundary, and example.com.other.test isn’t a subdomain of it.

In the example, the exact exception for portal comes first and uses DIRECT; the suffix rule sends other domains under example.com to PROXY. If the suffix rule were first, the portal exception wouldn’t get a chance to match. An exact rule doesn’t automatically have higher priority—the list order determines which rule is checked first.

DOMAIN-KEYWORD: a broader character match

[Rule]
DOMAIN-KEYWORD,example,PROXY
FINAL,DIRECT

DOMAIN-KEYWORD matches a keyword anywhere in a domain name. It may match example.com as well as myexample.test. If your actual goal is to handle one domain and its subdomains, a keyword match is usually broader than a suffix rule and can include unrelated sites whose names contain the same characters. Short, common keywords are especially prone to hard-to-trace false matches.

As a general approach, use DOMAIN for exact exceptions and DOMAIN-SUFFIX for clearly defined groups of domains. Consider DOMAIN-KEYWORD only when you genuinely need to group unrelated domains by a shared name fragment and have checked the potential scope. Don’t use keywords as a substitute for maintaining a domain list; it makes it harder to explain why a request matched.

Domain match boundaries and missing information

A webpage may request content from several domains, including the main site, static assets, authentication services, and APIs. A match for the main site doesn’t mean every resource uses the same policy. If the page loads but images or login fail, check the domain of the failing request instead of adding more rules for the main domain. Base third-party exceptions on request records, not guesses that broaden the scope in bulk.

A direct connection to an IP address may not have a usable domain name, leaving a domain rule with nothing to match. The domain information available for encrypted traffic also depends on the connection; don’t assume every request reveals its original name. If the log shows only an address, check address rules instead of disguising it as a DOMAIN condition. For definitions, see the glossary.

GEOIP, IP-CIDR, and USER-AGENT

Use address rules when the destination is an IP address or when routing genuinely depends on the address’s location. They match alongside domain rules; they aren’t automatically placed after them. USER-AGENT relies on visible request-header information, so its input is different again. When these types appear in the same list, understand where each condition’s input comes from to avoid mistaking missing information for a syntax problem.

IP-CIDR and IP-CIDR6

[Rule]
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
IP-CIDR,198.51.100.8/32,PROXY,no-resolve
IP-CIDR6,2001:db8::/32,DIRECT,no-resolve
FINAL,PROXY

IP-CIDR describes an IPv4 address range. The number after the slash is the network prefix length, not a port or priority. /32 represents one IPv4 address; /24 covers a larger address block. Use IP-CIDR6 for IPv6 ranges; a single IPv6 address can be represented with /128. The addresses in these examples are for documentation only and can’t be used to test connectivity to a real service.

A shorter prefix usually covers a larger range. Don’t widen a network block arbitrarily just to “make sure the target is included”; that could reroute unrelated connections. First confirm the actual address, then the network boundary. If the address came from a DNS lookup, also consider whether the domain may return different addresses later. A single lookup doesn’t represent every address the service may use over time.

GEOIP: match using an address database

[Rule]
DOMAIN,service.example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY

GEOIP matches based on regional classifications in an address database. The example handles a specific domain exception first, routes destinations classified as CN through DIRECT, and sends everything else to FINAL. A regional classification isn’t the same as a domain’s registered country, the language of its content, or the location of its organization; it also says nothing about connection speed. Database updates may lag behind actual network allocations, and deployments across regions or changes to address assignments can make database results differ from expectations.

If an important destination can’t be handled reliably by region alone, add a more specific domain or address exception before GEOIP and document why. Don’t repeatedly switch an entire regional policy without checking the results. When using GEOIP,CN,DIRECT,no-resolve, also consider the resolution limits described above: without an available address, this rule may not be able to make the intended decision.

When to use USER-AGENT

[Rule]
USER-AGENT,ExampleClient*,DIRECT
FINAL,PROXY

USER-AGENT checks the User-Agent request header when it’s available to the client. The example uses a wildcard to show a value starting with ExampleClient; it illustrates the rule format and doesn’t refer to a real app. This isn’t a general way to route traffic by an app’s system name, and it can’t retrieve arbitrary request headers from encrypted connections. An app’s display name, process name, and User-Agent can all differ; don’t use them interchangeably.

With HTTPS, ordinary connection handling generally can’t read encrypted HTTP request headers. Don’t rely on USER-AGENT to cover traffic from every app. The examples here don’t require adding a certificate or expanding decryption. If you can’t confirm that the header is visible, prefer a domain or address rule you can verify. If the request doesn’t include that header, the rule has no input to match.

Choose a match type before adding exceptions

For business domains, consider domain conditions; for fixed address ranges, use IP-CIDR; for classifications from an address database, use GEOIP. Consider USER-AGENT only when you’ve confirmed the request header is readable and need to match on it. More rule types don’t automatically mean better coverage. Stacking conditions for the same destination only makes the configuration harder to understand, especially if they use different policies.

When testing address rules, record the address family, actual destination address, and matched rule. A domain may use IPv4 in one test and IPv6 in another, naturally matching different rules. Keep the network and destination consistent for comparisons. If you need an IPv6 exception, base it on a confirmed range instead of routing all IPv6 requests the same way to hide a local configuration issue.

Policies, Global Routing, and priority

A rule condition answers “does this match?”; a policy determines “what happens after it matches?” This page uses three basic policies: PROXY, DIRECT, and REJECT. They’re not the same layer as Global Routing in Home. Global Routing determines whether the client uses configuration-based routing or a global mode; policies in Rule determine how an individual connection is handled during configuration-based routing. When troubleshooting, check the outer mode before inspecting the rules inside it.

What the three policies do

PROXY requires existing, usable server details and a valid exit selection. If exit authentication fails, a rule that matches PROXY may still be correct; the connection simply can’t complete. DIRECT doesn’t guarantee success or remove system network requirements. REJECT explicitly blocks requests and should be used only when that’s intended. Don’t assign a broad keyword match to REJECT and then mistake missing resources for a server failure.

The three Global Routing modes

The configuration mode is Config, which applies rules from the active config. Proxy applies proxy handling globally, while Direct connects directly across the board. Switch back to Config to check rules. If Proxy or Direct is active, changing Rule entries alone won’t show whether they work as intended. Use mode comparisons as a diagnostic step, not as a long-term substitute for correct rules.

This page covers traffic routing after requests enter the client’s processing path. System-level network handling and bypass settings in General can still affect what’s covered. Don’t assume “global” means all system traffic follows the same path. Test a specific, observable request; a connection indicator in the status bar doesn’t prove that every destination uses the expected policy.

Rules are checked top to bottom; the first match wins

[Rule]
DOMAIN,portal.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

The Rule list is generally checked from top to bottom. Once a rule matches, its policy applies; the client doesn’t continue looking for a “more specific” rule. The example places an exact domain exception before a suffix rule, a specific address range before a regional rule, and a fallback at the end. This order reflects the author’s intent; the engine doesn’t calculate a specificity ranking. If two rules cover the same destination, the earlier one takes effect first.

FINAL isn’t an ordinary conditional rule

FINAL,PROXY includes only a type and policy, and handles requests that didn’t match earlier rules. It doesn’t need a domain condition. If placed in the middle of the list, it prevents later rules from handling the remaining requests. When maintaining a configuration, check that there’s only the intended final fallback, especially after merging files. Whether the fallback uses PROXY or DIRECT depends on the configuration’s purpose and your network and access needs; neither is inherently correct.

Before reordering rules, work through the priority on paper: choose a specific domain and check each line from the top, stopping at the first match. Repeat with a destination that isn’t on your list and confirm that it reaches FINAL. If the result differs from the actual log, check the active file, routing mode, and available input information. Don’t assume the engine sorts rules by keyword length or domain hierarchy.

How Host differs from URL Rewrite

Host and URL Rewrite can both affect access, but they act on different things. Host maps a domain to an address; URL Rewrite applies an action to URLs that match an expression. Neither is the same as choosing a policy in Rule. If a request connects to an unexpected address or goes to another URL, check the DNS mapping, rewrite result, and routing rule separately instead of looking only in Rule.

Host: specify a DNS mapping

[Host]
fixed.example.com = 192.0.2.10
service.example.com = 198.51.100.20

[Rule]
DOMAIN,fixed.example.com,DIRECT
DOMAIN,service.example.com,PROXY
FINAL,PROXY

These two Host entries demonstrate mapping exact domains to specified addresses; the addresses are documentation examples. The separate Rule sends fixed.example.com through DIRECT, showing that “where it resolves” and “how it connects” are separate settings. A Host entry doesn’t guarantee a direct connection, and a DOMAIN rule using PROXY won’t automatically correct an invalid address mapping.

A fixed mapping reduces reliance on normal DNS responses, but it also removes the flexibility for a service to change its address dynamically. If a service uses dynamic deployments or regional access points, an address from one lookup may eventually stop working. Use a fixed mapping only when its purpose is confirmed and you can maintain it. If access works on some networks but not others, remove Host temporarily for comparison as an isolated variable rather than replacing all DNS settings.

Host doesn’t change certificate identity

Mapping a domain to an address doesn’t give the service at that address the right site configuration or a valid certificate. HTTPS still verifies the identity associated with the domain, and the server may choose a site based on the name in the request. If the mapping causes a certificate error, confirm that the destination address actually serves that domain. Don’t bypass identity checks to hide an incorrect address.

Likewise, Host isn’t a webpage redirect tool. A domain in the browser’s address bar generally won’t change to another name just because of an address mapping. To understand why the browser moved to a different page, check the server response or URL Rewrite. Don’t confuse an address change with a change to the URL shown in the browser. Keeping these layers separate helps avoid solving similar-looking problems with the wrong mechanism.

URL Rewrite: understand the expression and action

[URL Rewrite]
^http://example\.com/(.*)$ https://example.com/$1 302

The example redirects matching HTTP URLs to the corresponding HTTPS URL. On the left is a regular expression: ^ anchors the start, dots in the domain are escaped with backslashes, and (.*) captures the remaining content. The replacement target is in the middle; $1 refers to the first capture group. The final 302 indicates a temporary redirect. This isn’t syntax for routing the target domain through PROXY, nor does it configure HTTPS on a server.

When writing an expression, constrain the scheme and domain boundaries. An unescaped dot matches any character, and missing start or end boundaries can broaden the match. Test the root path, a path with query parameters, and a similar domain that shouldn’t match. Confirm that captured content isn’t truncated or duplicated. Don’t paste real URLs with private query parameters into shared notes; use example.com in examples.

Visibility and redirect loops

URL Rewrite needs to be able to identify the relevant URL. An encrypted connection doesn’t make the full path visible by default, so don’t assume the HTTP example automatically covers all HTTPS content. This section doesn’t require expanding decryption. If a rule never triggers, first check whether the input URL is visible, then check the expression. Broadening the regular expression to every domain adds risk without providing missing information.

A redirect loop can occur if one rule sends the destination back to the original URL. Browser history typically shows repeated redirects rather than a single timeout. To troubleshoot, temporarily disable the new Rewrite and confirm that the original request works again, then add rules back one at a time for comparison. Test Host, Rewrite, and Rule separately. Change only one mechanism at each step, and record the original URL, final URL, and match result.

Combining rules and maintaining configuration

A maintainable configuration isn’t defined by the number of rules, but by whether each condition has a clear purpose. A common structure puts exact exceptions first, followed by domain groups, then any necessary address and regional conditions, with one fallback at the end. This is a common approach, not a fixed standard. If your configuration has a different purpose, adjust the order—but make sure you can explain why any specific request gets its current result.

Start with the smallest testable snippet

[Rule]
# Put exact exceptions before domain groups
DOMAIN,portal.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY

# Handle only destination addresses that are already available
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve

# Apply the final fallback after regional matching
GEOIP,CN,DIRECT
FINAL,PROXY

This example demonstrates how to organize rules; it contains no server or authentication details. First, check whether portal uses DIRECT. Then check whether other domains under the same suffix use PROXY. Finally, confirm whether unrelated domains are classified by address or reach FINAL. Documentation addresses aren’t real test servers; replace the relevant conditions with test targets you already have and are authorized to access.

Apply the same minimal approach when adding REJECT. Start with one confirmed exact domain that won’t affect essential functions, then verify in real request records that it matches the intended target. Don’t reject an entire group of business domains just to reduce request volume. A domain that appears to serve only static assets may also handle authentication or page initialization; a mistaken rejection often causes partial failures rather than a complete loss of connectivity.

Resolve overlaps and fallback placement before merging

Simply appending one file to another can create duplicate sections, conflicting policies, and a FINAL rule in the middle of the list. Before merging, consolidate the rules into one clear Rule list, then check each rule’s position. Identical conditions with the same policy usually add maintenance overhead. If their policies differ, the later rule may never match, while making it look as though both behaviors are active.

Text-based deduplication alone won’t reveal every conflict. DOMAIN and DOMAIN-SUFFIX may cover the same destination despite having different text; IP-CIDR and GEOIP can overlap at the address level too. Work through representative destinations rule by rule and confirm that exceptions remain ahead of broader conditions. After merging, keep only the intended fallback and verify that each policy name resolves in the active configuration environment.

Remote updates and local changes

Updating an existing subscription mainly affects server entries, while a remote configuration update may affect text such as Rule and General. They aren’t the same thing. If behavior changes after an update, first identify what was updated. Changes to the server list may affect exit selection; changes to rule text may alter the matching path. Save copies of the files before and after updating—this is usually more reliable than relying on memory.

For ongoing use, keep verified local changes in a separate copy and note their source, purpose, and how to revert them. Before updating remote content, check whether the update will overwrite that file. Don’t assume local additions are always preserved. For the difference between import methods and subscription updates, see Subscribe, Add Server, QR code, and clipboard imports.

Use comments to record the reason and when to revert

A useful comment does more than restate the rule: it explains why an exception is needed, how to verify it, and when it can be removed. For example, “This API must use the same exit as the main site; test login and subsequent API calls” is more helpful than “API rule.” Don’t store subscription credentials, private full URLs, or server passwords in comments. Remove sensitive information from configuration text before sharing it for help.

Keep a brief record of each change: the condition, the previous result, the expected result, and what actually happened. If a new rule doesn’t improve the issue, revert it before testing another variable instead of leaving ineffective fixes in the list. The goal of rule maintenance is to make current behavior explainable and repeatable, not to accumulate exceptions that no one can trace.

Verify matches and troubleshoot connections

Rule problems and connection problems can both make a page fail to load, but they need different troubleshooting. For rules, first check whether the request used the expected policy. For the connection, check whether that policy’s network path is available. Record the current connection state, matched condition, and exit result separately. An enabled VPN switch only confirms that the configuration connection has started; it doesn’t prove that the server, DNS, or destination service is working.

Set up a repeatable test

Before testing, record the network type, Global Routing mode, active configuration name, selected server, and a specific test target. First use the existing configuration to verify basic connectivity, then check the target rule in Config. Start a new connection for each test when possible to avoid reusing an old session. Don’t compare several similar pages by feel; look for evidence that the actual request matched the intended policy.

Connectivity Test can help check whether an existing server is reachable, but the result applies only to the conditions tested. It doesn’t prove that requests to every domain or using every protocol will work. A server can pass the test while a target site still fails because of DNS, routing, server-side restrictions, or a different address family. Treat a successful server test as one checkpoint, not a substitute for verifying rules.

What to check when the expected rule doesn’t match

1. Confirm that Global Routing is set to Config and that Config has the file you just edited selected.
2. Check the domain or address used by the actual request; the browser’s address bar doesn’t show every resource request.
3. From the top of the list, check for an earlier broad match, duplicate conditions, or a FINAL rule placed too soon.
4. Check the English commas, section names, policy names, and how no-resolve affects the available input.

If the record shows only an address, first determine whether a domain is actually unavailable, then check IP-CIDR or GEOIP. If an unexpected DOMAIN-KEYWORD matched, consider narrowing its scope. If the rule wasn’t involved at all, also review the bypass settings in General. Don’t start by deleting the entire configuration; you’ll lose the original conditions needed to explain the problem.

The correct policy matched, but the request still fails

If the PROXY path fails, keep the rules unchanged and compare using another working exit you already have. If the request succeeds after switching, the issue is more likely with the original exit or its path to the destination. If the DIRECT path fails, first check system access on the same network. Record exactly what changed in each comparison so you don’t confuse network fluctuations with configuration changes.

Partial resource failures and reverting changes

If login, images, video, or an API fails, check the corresponding request instead of assuming it shares the main page’s domain and connection. Also check whether REJECT blocked a dependency or whether different domains were assigned to incompatible exit paths. If the issue started after a configuration change, restore the baseline to confirm the connection, then reapply changes one at a time. This is easier to troubleshoot than adding more patches.

When compiling a troubleshooting report, include only the relevant configuration snippet, redacted destination names, matched rule, and error details. Remove authentication parameters, private subscription URLs, and sensitive request contents. For protocol parameter differences, see VMess and VLESS field differences. For common connection symptoms, check the categories in Frequently Asked Questions. Don’t mistake an authentication failure for a rule-keyword problem.

After testing, restore your usual Global Routing mode, save the configuration you confirmed works, and remove temporary Host, Rewrite, or test rules. To repeat the full setup process, return to the Getting Started guide and check imports, exit selection, VPN configuration permissions, and connection testing in order. For system requirements, device compatibility, and app availability, refer to the App Store listing.