Shadowrocket Rules and Configuration Reference

1. Configuration Structure and Editing Safely

Before changing fields, confirm which configuration is active. Shadowrocket can store multiple configuration files in the Config list, but a file being present there does not mean it is being used for connections. Open Config, check the selected file, note its name and source, then inspect that file. If the rules you see do not match your expectations, first make sure you have the right file selected rather than adding more similar rules. For files from remote sources, distinguish local edits from content applied by a later update.

Section names determine how fields are interpreted

Configuration text is divided into sections marked by names in square brackets. [General] contains options that affect overall behavior; [Rule] contains conditions evaluated in order; [Host] maps specified hostnames to addresses; and [URL Rewrite] contains URL rewrite entries. The same line can mean different things in different sections. A domain rule pasted under General does not become a rule just because its text looks valid. To check the structure, read from each section name to the next one.

[General]
bypass-system = true

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

[Host]
example.com = 192.0.2.10

[URL Rewrite]
^http://example\.com/ https://example.com/ 302

The text above shows how four sections fit together; it is not a recommendation to enable the entire example. The Host address is for documentation, and URL Rewrite demonstrates only a specific HTTP address redirect. Line breaks separate entries, commas separate rule fields, and equals signs connect some setting names and values. Before testing a connection, check for full-width punctuation, invisible characters introduced by copying, and incorrect section names so text errors are not mistaken for network failures.

Local copies and remote updates

Save a copy you can restore before editing. If you use a remote configuration, understand what an update replaces. Adding personal rules directly to a source file may mean a later refresh overwrites those changes. A safer approach is to keep the source file as a reference, experiment in a clearly identified local copy, and record the purpose of each change. Avoid replacing General, reordering Rule, and adding Host entries all at once, then trying to judge every change from a single visit.

Understand Subscribe and configuration files as separate things. An existing subscription is generally used to maintain server entries, while a configuration file describes how connections are handled. They can be related in your workflow, but updating one does not prove the other has changed. If the server list refreshes but the rules do not, check the active file in Config instead of repeatedly refreshing Subscribe. Likewise, changing domain policies will not add missing server addresses, ports, or authentication details.

Make small changes with verifiable results

Change one clearly defined thing at a time, such as setting one test domain to DIRECT or narrowing an overly broad REJECT condition. Before editing, note which rule you expect to match, which policy should apply, and how you will check the new connection. Save and confirm the configuration, then establish the relevant connection again and compare the result with your expectation. Existing connections may continue to use their original path, so refreshing an already-open page alone does not prove the new rule is handling every request.

Remove personal connection details, subscription URLs, and credentials before sharing a configuration. Rule examples can retain test domains, and troubleshooting notes can include relevant field names, but a full configuration often contains far more information than the issue requires. When asking for help, share only the relevant sections, the rules' relative order, and redacted connection logs. This makes the issue easier to reproduce and keeps unrelated entries from obscuring the discussion, especially when investigating a domain routed incorrectly.

2. General: Global Options and DNS Considerations

General affects overall configuration behavior; it does not select a policy for each domain. When reviewing this section, check the field name, the value's type, and whether it is relevant to the issue. For example, a DNS lookup failure calls for checking the DNS path; a domain unexpectedly using DIRECT usually calls for checking Rule and the current Global Routing mode. Blaming every issue on General adds variables and can hide a straightforward rule-order problem.

Enter fields and values using the correct type

General settings commonly use a field name, an equals sign, and a value. Boolean options use true or false; address-related options must follow the format supported by that field. Do not enter explanatory text in Chinese as a value, and do not assume an option in someone else's configuration is right for your network. For an unfamiliar field, check its description and supported values in the app's configuration editor. Keeping the existing value is usually easier to reason about than guessing from the field name.

[General]
bypass-system = true
dns-server = system

bypass-system controls bypass behavior for system-related traffic. It does not mean “send all connections directly,” and it is not a substitute for Direct in Global Routing. When changing it, consider which system traffic paths are affected; do not assume every request will behave the same way. If you are troubleshooting ordinary web access and the issue is unrelated to system services, leave the current setting in place to avoid widening the scope of changes for a single domain.

DNS resolution and rule evaluation are separate steps

dns-server = system uses the system DNS path. For a custom resolver address, check its reachability on your current network and consult the configuration guidance. Rules need request information they can evaluate: some conditions use a domain, while others use the destination IP. DNS resolves domain names to addresses; Rule selects a handling policy. They can affect one another, but neither replaces the other. Adding a PROXY rule will not make an unreachable DNS endpoint available.

When using DNS over HTTPS, distinguish the transport used for DNS queries from the policy applied to the eventual website connection. Sending DNS queries over HTTPS does not mean all subsequent website traffic uses the same policy; whether a website uses PROXY still depends on the current mode and matching rule. If the resolver endpoint itself uses a hostname, consider how that hostname is resolved initially. Avoid entering many addresses from different sources and assuming each works just because one visit succeeded.

Start with a setup you can compare

Before changing DNS, keep a restorable copy of the original configuration, choose a test domain that reliably reproduces the issue, and note the network type. On the same network, with the same server and rules, change only the resolver setting and observe whether the resolution result or connection log changes. If you also switch networks, servers, and DNS, you will not know which change made the difference. Network changes can also affect cached results, so test with a new request rather than an existing tab.

A latency result with a page that will not load only shows that one kind of test request received a response. It does not prove that domain resolution, the destination connection, and every page resource are working. A page may request several hostnames; a failure to resolve just one can affect what appears. Identify the failing domain, then check whether it resolved, which policy it used, and where the connection stopped. For more on this symptom, see DNS lookup troubleshooting steps.

If fields shown in the app differ from these examples, follow the in-app guidance rather than adding an unknown option. General is not something to “complete” by copying in a large number of settings; a concise, explainable configuration is easier to maintain. For every field you keep, be able to answer three questions: what behavior does it change, why is the change needed, and how can you undo it? For a fuller discussion of resolver choices, see System DNS, custom DNS, and DNS over HTTPS. This page focuses on the prerequisites for rule evaluation.

3. Domain Rules and USER-AGENT Conditions

Domain rules specify which policy to use for a hostname or group of related hostnames. A basic rule consists of a type, a match value, and a policy, separated by commas. The match value is generally a hostname, not a full web address, so it should not include a scheme, port, or path. If you want a particular page on a site to use a different policy, first check whether a domain rule has enough information to distinguish it; a domain rule alone cannot tell apart two pages on the same host.

DOMAIN and DOMAIN-SUFFIX scope

DOMAIN matches an exact hostname and is useful for handling one specific destination. DOMAIN-SUFFIX matches a domain and its subdomains, making it useful for handling requests within the same domain namespace together. It is not an arbitrary string-ending match; domain boundaries are taken into account. Do not assume it matches any hostname that happens to end with the same characters. Before choosing a type, list the hostnames you want to cover to check that the rule's scope is not too broad.

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

In this example, api.example.com matches DOMAIN first and uses DIRECT. www.example.com does not match the first line, so it matches DOMAIN-SUFFIX and uses PROXY. If you swap the first two lines, the suffix rule also catches the exact hostname before it reaches the next rule. That does not mean exact matching failed; evaluation already stopped at the earlier line. To preserve an exception, put the narrower condition before the broader one instead of expecting the rule type to establish priority automatically.

Where DOMAIN-KEYWORD matches

DOMAIN-KEYWORD checks whether a domain contains a specified keyword; it is not limited to one organization or domain namespace. Shorter keywords are more likely to match unintentionally. Use it when a string-based condition is genuinely needed, not as a substitute for a list of known exact domains. Be especially careful when using REJECT: a false match can block legitimate requests and cause missing images, failed logins, or pages that keep loading.

[Rule]
DOMAIN,downloads.example.com,PROXY
DOMAIN-KEYWORD,ads,REJECT
FINAL,PROXY

This example adds an exception for a known hostname before applying keyword blocking. The characters in downloads.example.com also contain ads, so the exception's position changes the result. In a real investigation, check the hostname actually being evaluated and the rule text rather than relying on a subjective judgment about whether it is an ad domain. If the match scope is broader than expected, use DOMAIN or DOMAIN-SUFFIX where appropriate instead of repeatedly adding exceptions to compensate for an overly broad condition.

Limits of USER-AGENT matching

USER-AGENT matches the User-Agent field available in a request; its condition value can use supported wildcard syntax. It does not identify an app and cannot reliably represent a process. A request may not have this field, and different apps may send similar values. For encrypted traffic where the field is unavailable, do not expect the rule to read it. For stable, long-term routing, consider an explicit domain or destination address first, then decide whether this condition is appropriate.

[Rule]
USER-AGENT,ExampleClient*,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,PROXY

ExampleClient is only a sample field prefix; it does not refer to a real app. To test a USER-AGENT rule, first confirm that the request actually includes the field and that the app can access it. Do not add traffic decryption settings just to match one rule. Evaluate visibility into encrypted traffic separately from ordinary domain-based routing. If you cannot confirm the field's contents, a domain rule you can observe provides a clearer test and an easier fallback.

4. IP-CIDR, IP-CIDR6, and GEOIP

IP rules match destination addresses, not website names. A domain can resolve to multiple addresses, and one address can serve multiple domains, so address conditions and domain conditions are not equivalent. If you need to set a stable policy for a particular website, first consider whether a domain rule is more appropriate. Use IP conditions when you need to handle a specific local network range, destination address, or address-geolocation category. Choose based on the boundary you need to express, not on which syntax is shorter.

Use prefix length to specify an address range

IP-CIDR matches IPv4 address ranges. The number after the slash is the network prefix length, not a port or the number of usable addresses. For example, 192.168.0.0/16 is a private address range, while 192.0.2.10/32 specifies one IPv4 address. Use a clearly defined network address and prefix; do not treat the address currently assigned to your device as the entire network range. A wrong range can match far more destinations than intended.

[Rule]
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR,192.0.2.10/32,PROXY,no-resolve
IP-CIDR6,2001:db8::/32,DIRECT,no-resolve
FINAL,PROXY

IP-CIDR6 matches IPv6 address ranges. The 2001:db8::/32 example is reserved for documentation and does not represent a real network. If a destination supports both IPv4 and IPv6, configuring only an IPv4 condition does not show that IPv6 connections will be handled the same way. Check the destination address type in connection logs. Different results for the same website may come from different address selection, not a random change in rule order.

no-resolve does not disable DNS

no-resolve is an option that can be added to some address rules to avoid triggering a DNS lookup specifically for that rule's evaluation. It does not stop resolution across the whole configuration or mean the destination never has an address. If a request already uses an IP, or an address is already available when the rule is evaluated, it can still be checked against the address condition. For local network address rules, this option can help avoid an extra lookup just to check the range. Whether to add it depends on the match target.

If no usable IP is available, a rule with no-resolve cannot use the domain name to determine which network range the destination belongs to. Conversely, an address condition without this option may involve resolution, bringing the DNS path into the evaluation. Putting many address rules before domain rules can also make resolution behavior harder to explain. For a clear control flow, handle known destinations with explicit domain conditions first, then use address conditions for remaining connections.

GEOIP matches address geolocation

GEOIP,CN,DIRECT uses an IP geolocation database to send destinations marked CN to DIRECT. It does not match based on website language, domain suffix, company registration, or the user's location. A Chinese-language website may connect to an address in another region, and the same domain may resolve to addresses with different geolocation results. To understand a GEOIP match, check the actual destination IP rather than inferring a mismatch from the website name.

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

These rules handle the example.com domain namespace first, then use GEOIP for the remaining requests. If GEOIP is placed first, an address may match it before the domain rule is evaluated. Geolocation databases have update cycles and classification limits, so geolocation is not a precise way to categorize business traffic. For a small set of domains that must use a fixed policy, a clear earlier condition gives you more control than relying on all their addresses to keep the same geolocation classification.

When troubleshooting a local network destination, distinguish “the rule selected DIRECT” from “the device can reach the destination.” DIRECT selects a direct connection; it does not add a local route, correct a destination port, or change access permissions. If the rule matches but access still fails, check the current Wi-Fi network, destination device status, and whether its address has changed. Confirm the address the request actually targets before reviewing the network range rule, so an outdated address or a service that is not listening is not mistaken for an IP-CIDR syntax error.

5. PROXY, DIRECT, REJECT, and Global Routing

The last major field in a rule is usually its handling policy. The condition answers “which requests?” and the policy answers “what happens when one matches?” PROXY, DIRECT, and REJECT describe different outcomes, not speed tiers or connection quality ratings. When reviewing a configuration, list the policies first and check whether each outcome fits its purpose, then verify that the conditions route requests to the right one.

Policy names specify how matched requests are handled

PROXY sends a request through the proxy path and still depends on valid server details and the relevant selection. A test domain in a rule will not create a server or repair an expired entry in a subscription. DIRECT connects to the destination directly, relying on the local network, resolution results, and destination service. REJECT blocks a matching request and is appropriate for destinations that should be blocked. Using it with an unclear scope can cause scattered page failures that are difficult to diagnose.

If the configuration supports and uses custom policy names, confirm each name is defined in the current configuration and referenced exactly as written. Do not paste a policy group name from someone else's file at the end of a rule and expect it to match your existing servers. Check spacing, capitalization, and any name changes too. When troubleshooting, start with basic policies you can explain and compare; introduce more complex policy organization only after the basics are clear.

Global Routing determines how the configuration is applied

The Config, Proxy, and Direct options in Global Routing correspond to configuration-based, proxy, and direct connection modes. To route traffic rule by rule, confirm that Config is selected. Proxy and Direct can help compare overall paths, but they are not a way to verify that each rule works. When the mode has changed, the result does not prove that a particular Rule line was applied. When reporting an issue, include both the selected mode and configuration file; without either, the reproduction details may be incomplete.

Narrow down issues by comparing modes

Suppose a destination is reachable in Proxy mode but fails in Config. Do not immediately conclude that the entire configuration is unusable. Return to Config and check which rule matches the destination: it may be blocked by REJECT, sent through an unreachable DIRECT path, or assigned a different custom policy. If it fails in both modes, check the server, DNS, and destination service next. Comparing modes provides clues, not a definitive diagnosis of a particular field.

After changing Global Routing, check a new connection. An existing session may continue transferring data, and an app may reuse an existing connection. Rapidly switching modes and refreshing the same page may not produce a clean test. Keep other conditions unchanged, send a new, identifiable request, and use the connection log to confirm its path. Page content can also be cached: seeing an old page does not prove the latest network request succeeded.

Keep the app purchase and connection service separate. Shadowrocket is a paid client for Apple platforms; a one-time purchase of the app does not include a connection service. You still need your own existing subscription or server details. For app availability, the official app icon, and developer verification, see the App Store purchase guide. Check the App Store listing for device compatibility and system requirements. Configuration fields manage how existing connections are handled; they do not provide additional connection resources.

6. Match Order, Exceptions, and FINAL

The key Rule principle is that conditions are evaluated from top to bottom. When one matches, its policy is applied and evaluation stops; the client does not keep searching for a condition that seems more intuitive. Rule types do not have automatic priority rules such as “an exact domain always outranks a network range.” Priority primarily comes from a rule's position in the file. To find out why a rule did not apply, start with the entries above it rather than repeatedly checking only its syntax.

Handle exceptions before broader matches

A practical way to organize conditions is to put specific exceptions first, broader domain or address ranges after them, and a fallback rule last. This is a maintainable approach, not a requirement that every file use the same category order. The result is determined by the first condition that matches each destination. For example, if a local network service needs special handling, check that a broad domain or address condition does not match it first; do not assume it will take priority simply because it is on a local network.

[Rule]
DOMAIN,api.example.com,DIRECT
DOMAIN,ads.example.com,REJECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

In this example, api.example.com matches the first rule and is not evaluated against the suffix rule. ads.example.com is blocked by the second rule, while other example.com subdomains use PROXY. The remaining address ranges and GEOIP are considered only afterward. Try tracing three specific destinations down the list, marking the first condition that matches each one. This makes misplaced exceptions, overlapping conditions, and an early fallback easy to spot.

FINAL is an unconditional fallback

FINAL handles connections that did not match any earlier condition. Common forms are FINAL,PROXY and FINAL,DIRECT. It has no domain or address match value, so it uses a different number of fields from a typical domain rule. Put it as the last active rule in the Rule section. If you add DOMAIN entries after it, they will not be evaluated, however specific they are. This can make a rule appear to be present but never take effect.

Decide on the default path before choosing a FINAL policy. FINAL,PROXY sends uncategorized connections through the proxy path; FINAL,DIRECT sends them directly. Neither choice can be evaluated in isolation from the preceding rules: the same conditions with a different fallback cover traffic differently. Changing the fallback can have a wide impact, so check where several important destinations actually match before changing the path for all uncategorized traffic to fix one site.

Review duplicate rules and remote content

Duplicate entries do not necessarily cause a syntax error, but they make a configuration harder to read. If two identical conditions use different policies, the later entry is usually shadowed by the earlier one. Similar conditions with different scopes need to be checked against individual destinations. Do not sort entries alphabetically without checking first; that may break an intentional exception order. Note the purpose of each group, remove entries you know are redundant, and retest important domains after each cleanup.

When combining snippets from different sources, common problems include duplicate section headers, duplicate FINAL rules, and inserting a whole section after an existing fallback. First identify the section each snippet belongs to, remove section headers that should not be repeated, and place the rules where they are meant to go. For snippets that reference custom policies, confirm the dependencies exist first. Being able to paste a snippet into a file does not mean it fits the current configuration's structure, policies, or default path.

For a long rule list, change notes should explain “why it goes here,” not just “what was added.” For example, an exact domain may precede a suffix rule to preserve a DIRECT exception; a keyword rule may have been removed because it matched legitimate resources. This context is more useful than a change count when troubleshooting later. If a match is unexpected, isolate the relevant rules and test them before merging the result back into the full file. Do not keep adding conflicting rules and hoping one will work.

7. What Host and URL Rewrite Do—and Do Not Do

Host, URL Rewrite, and Rule handle address mapping, request URL rewriting, and policy selection respectively; do not treat them as interchangeable. A configuration containing all three sections does not mean every troubleshooting task requires changes to all three. To route a domain through PROXY, start with Rule. To assign an address to a specific hostname, consider Host. Check URL Rewrite only when a matching URL needs to be changed. Keeping these roles separate reduces fixes that seem to work but are hard to explain.

Host maps a hostname to an address

A basic Host entry consists of a hostname, an equals sign, and a destination address; it does not take a full web URL. It changes the address associated with that hostname, not whether to use PROXY or DIRECT. Even if Host supplies an address for a domain, the connection is still handled according to the current mode and applicable rules. Do not append a policy field to a Host line and expect it to route traffic; put address mappings and policy conditions in their respective sections.

[Host]
service.example.com = 192.0.2.10

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

The example address is for documentation only and cannot be used to connect. Before setting a real mapping, confirm that the address comes from a reliable source for the destination service and that you know when to remove it. Websites may use dynamic addresses, multiple service endpoints, or different addresses for different content. An address that worked once may stop working after a service change. If you use Host temporarily for diagnosis, record the original setting and restore it when testing is complete rather than letting a test condition become a permanent dependency.

Host cannot turn an arbitrary server into the destination website. An HTTPS connection still involves the hostname, certificate, and server-side handling; connecting to an address does not guarantee that the certificate or content will match. If a mapping change causes a certificate error, do not lower verification requirements to keep accessing the site. Check that the domain and address really belong to the same service. For destinations with multiple addresses, a fixed mapping may also change availability and address selection.

URL Rewrite changes URLs that meet specified conditions

A URL Rewrite entry usually contains a match expression, a replacement target, and a handling method. The example redirects an HTTP URL for one specific hostname to HTTPS, using 302 for a temporary redirect. Dots in the regular expression must be escaped; otherwise, they match any character. The leading anchor restricts the match to the start of the URL. This example shows only the basic structure. Before enabling a rewrite, test its scope and actual response on a controlled destination; do not extend it to every domain by default.

[URL Rewrite]
^http://example\.com/ https://example.com/ 302

A rewrite rule cannot guarantee that the destination provides HTTPS or that login, paths, or request methods retain their original behavior after a redirect. If you need to preserve the path, first understand how capture groups and replacement references work, then test multiple URLs rather than only the homepage. Also make sure the rewritten destination will not match another rule that sends it back in the opposite direction, creating a redirect loop. If a browser reports too many redirects, first check for overlapping conditions and targets.

Assess visibility separately from additional settings

For encrypted requests, whether URL-level handling is possible depends on what request information the app can access and whether the required conditions are met. Domain-based routing working does not mean every URL path can be read. Do not enable unfamiliar traffic decryption settings just to use an example rewrite. Certificate and encryption handling involve additional trust considerations and should be configured separately only when needed and understood. This page does not make them a prerequisite for ordinary rule-based routing.

If Host, URL Rewrite, and Rule are all in use, disable or change only one type at a time when troubleshooting. First restore the original address mapping and create a new request, then check the destination IP. Next verify whether the URL was rewritten as expected, and finally check which policy matched. This separates “wrong address,” “wrong redirect destination,” and “wrong connection path.” Do not try to fix all three with a new DOMAIN-SUFFIX rule; correct policy selection cannot compensate for a bad mapping or redirect loop.

8. Configuration Validation, Troubleshooting, and Rollback

The goal of configuration testing is not to make a page open once, but to get a repeatable result, understand why it happened, and be able to undo the change. Before you start, note the network, Global Routing mode, configuration file, and server in use, then choose a destination that reliably reproduces the issue. Confirm the configuration is saved and active before creating a new connection. Otherwise, the result may come from an old file, session, or cached page and tell you nothing about the rule you just changed.

Break the issue down along the connection path

A visit can be checked at several points: domain resolution, condition evaluation, policy selection, destination connection, and content response. First identify where it fails. With no resolution result, check DNS. If the wrong rule matches, check the order. If a PROXY connection fails, check existing server details and reachability. If the destination responds abnormally, check the website service. This is a practical way to eliminate one variable at a time, not a claim about the exact internal sequence used in every network implementation.

1. Confirm the selected Config file and Global Routing mode; rule out a file or mode mismatch.
2. Check the actual request hostname, destination IP, and address type—not just the address bar.
3. Check the matching rule and policy, then verify them manually in file order.
4. Keep other conditions unchanged, change one field, and establish a new connection.
5. Retest important services; once restored, record why the setting changed and keep a rollback copy.

A webpage often makes separate requests for the main page, images, APIs, and authentication. If the homepage loads but login fails, a related domain may be blocked by REJECT or sent through a different path. The hostname in the address bar does not reveal how every request was handled. Find the request that actually failed, then check its conditions. If a keyword rule matches multiple resources, narrow it for comparison before routing the entire site and all its subdomains through the same policy; this often makes the cause easier to find.

Choose the next check based on what you observe

Connectivity Test can help compare server responses, but what it measures and how it works are not identical to a real request. A normal result does not prove that every destination, protocol, and resource succeeds; a test that gets no response does not by itself show that all connections have failed. Treat test results as clues and compare them with actual connection logs. To check existing server fields, review the source you imported and verify them individually; do not change rules to hide an address or authentication error.

Reproduce the issue with minimal rules, then merge changes back

For a long configuration, copy it into a dedicated test file and keep only the General settings needed for the issue, one clear destination condition, and FINAL. Verify the basic path first, then add the original rules back in groups until the problem returns. Keep their relative order and note the scope of each addition. This identifies the specific entry that interferes, instead of guessing among hundreds of lines. When testing is complete, merge the verified changes into the active file and make sure you have not accidentally left the test file selected.

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

This snippet illustrates how to test a specific destination separately from other connections; it does not include everything required to establish a connection. A reproduction report should include the expected and actual policies and the relevant rule position, while hiding subscription URLs, credentials, and personal identifiers. If the issue returns after a configuration update, compare the relevant sections before and after to see whether the update overwrote the change or whether the server, DNS, or destination address changed. Do not assume every update-related issue has the same cause.

After rolling back, confirm that the original destinations you care about are reachable before ending the investigation. Keep a short record of the symptom, the first matching condition, the final change, and how to restore the previous setup. For general questions, see Troubleshooting; for the first connection workflow, see the setup guide; for purchase, restore, and App Store checks, see the App Store purchase verification guide. A well-maintained rule set is one you can verify with the same steps next time, rather than one you have to modify by guesswork.