Shadowrocket
Rules and Configuration Guide

A configuration file describes how connections are handled; it is not the server account itself. Keeping these roles distinct helps avoid confusing “servers appeared after import” with “a routing configuration is selected.” Server details specify where to connect, which protocol to use, and how to authenticate. The configuration specifies which requests connect directly, which use a proxy, and which are rejected. Both are needed, but importing one does not mean the other is ready. If you use an existing subscription, first check the server details in Home, then confirm which configuration is active in Config.

Sections, Fields, and Rule Lines

Shadowrocket configuration text uses section names in square brackets to organize settings. [General] contains general parameters, typically written as a field name, an equals sign, and a value. [Rule] contains ordered routing rules; [Host] defines address mappings for specific hostnames; and [URL Rewrite] handles matching URLs. Section names are functional, not decorative: placing content in the wrong section changes how it is parsed. Don't use General's equals-sign syntax in Rule, or append explanatory text in Chinese to rule parameters.

[General]
bypass-system = true

[Rule]
DOMAIN,router.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
FINAL,PROXY

[Host]
router.example.com = 192.168.1.1

This snippet illustrates how the sections relate; it is not a finished configuration for every network. The first rule connects a specified host directly, the second covers an example domain and its subdomains, the third applies to a private address range, and the last is the fallback. The Host mapping associates an example hostname with an address; it does not mean a service is available at that address. When saving, keep the necessary fields from your existing configuration if you understand their purpose. If a remote source maintains the configuration, consider whether the next update will overwrite local changes.

Save a Copy and Confirm the Active Configuration

Before editing, identify the currently selected configuration in Config, note its name and where it can be restored from, and save a separate copy. Opening a file for editing does not prove that it is being used to handle connections. After saving, return to the configuration list to confirm it is selected, then verify with a new connection. If the editor reports a syntax issue, fix it before enabling the configuration. Don't keep adding content while parsing errors remain, or it will be harder to link later behavior to a specific change.

Keep configuration backups separate from server backups. Restoring a rules configuration may not restore server authentication fields; importing a subscription again may not restore manually added rules. Before migrating, check servers, configurations, and any necessary settings separately. Configurations may contain private domains, server identifiers, or authentication details. Remove those before sharing troubleshooting material; keep only the minimum rules and sanitized connection logs needed to reproduce the issue.

How to Read Configuration Examples on This Page

In the examples, example.com illustrates syntax; it is not a working subscription address and does not imply that the domain needs a particular policy. Replace example addresses and rules with ones that match your environment. Blank lines in code blocks separate groups. You can review a complete section as a whole, but place individual snippets in the appropriate configuration section. For an unfamiliar option, first confirm that the app recognizes it, then check what it affects. Similar field names do not necessarily mean similar behavior, so don't guess from the wording and add them in bulk.

Remote rule files and local configurations also come with maintenance responsibilities. When adding an exception, note why it is needed, what you tested, and the expected policy. After each update, check that the exception is still present. A small set of understandable rules is usually easier to maintain than a long list of unknown origin. The following sections proceed from setting operating conditions to defining match scope, choosing a policy, and checking results. Troubleshoot in the same order.

Check Global Routing before deciding whether rules in Rule are correct. A saved configuration that isn't currently running in Config mode is a common reason rules appear not to work. Config, Proxy, and Direct in the interface refer to three operating modes: configuration-based routing, proxy routing, and direct routing. They determine the overall handling path, not the priority of individual rules. To test routing, explicitly select Config and check the current mode before each test.

General Is Not Another Rule List

Fields in [General] control general behavior; they do not replace per-domain rules in Rule. For example, bypass-system and skip-proxy affect system bypasses and handling for specific destinations, at a different level from ordinary Rule matches. If a destination is handled by an earlier bypass path, simply adding a PROXY line to Rule may not produce the expected result. When troubleshooting, check both the rules and whether general settings are keeping the connection from following the expected path.

[General]
bypass-system = true
skip-proxy = 127.0.0.1, localhost, *.local
dns-server = system

This example preserves system bypass behavior, lists local and localhost domain forms, and uses the DNS settings provided by the system. It illustrates fields and is not intended to replace your existing configuration. In particular, skip-proxy takes a list as a general setting; that doesn't mean Rule accepts the same wildcard syntax. When reading an existing file, identify the section first, then interpret comma-separated values according to the field's meaning. Don't mix the two syntaxes.

The Connection Switch, On Demand, and Rules Each Handle a Different Layer

The connection switch in Home starts or stops connection handling; Global Routing sets the operating mode; and Rule in the active configuration selects a policy when Config mode is active. Check these conditions separately. On Demand determines whether a connection is established when its conditions are met; it does not choose PROXY or DIRECT for each domain. If the state changes after switching networks, first confirm that the connection is still active, then check the operating mode, and only then inspect rule order.

The first time you connect, the system may ask for permission to add a VPN configuration. This permission allows the app to use the relevant system networking capability; it does not prove that a server is reachable or that the rules are correct. If you haven't completed the initial connection flow, follow the Getting Started guide. Check the App Store listing for system requirements; don't infer compatibility with your current device from someone else's old screenshot.

Use Mode Switching for a Limited Comparison Test

For the same test destination, briefly compare new connection results in Direct and Proxy modes to distinguish direct-path issues from proxy-path issues, then return to Config. Keep the destination, network, and server unchanged during the comparison to minimize variables. If a page loads in Proxy but fails in Config, that only means the routing path warrants checking; it doesn't prove that all DIRECT rules are wrong. A page may contact several domains, so check the corresponding logs individually.

Likewise, a page loading in Direct does not mean the service should always connect directly. Network location, DNS results, and the destination service's access requirements can all change. A sound configuration reflects a clear need rather than turning one test result into a universal rule. If you're unsure about a General setting, restore a known-good copy first and check settings one at a time. Don't toggle several switches at random; doing so can obscure where the handling path changes.

Domain rules answer the question, “Which hostname should determine the policy?” Common types include DOMAIN, DOMAIN-SUFFIX, and DOMAIN-KEYWORD. They differ in match scope, not in name length or supposed priority. All three are evaluated according to their actual position in Rule. Before writing a rule, extract the hostname from the URL. Don't include the scheme, port, path, or query parameters in a domain argument.

DOMAIN: Match One Specific Host

DOMAIN,api.example.com,PROXY targets a specific hostname and is useful when you want to change the policy for a single endpoint or create a narrowly scoped exception. It does not automatically cover the entire example.com domain or all its subdomains. An app may use separate hosts for sign-in, images, and downloads. If the main page loads after adding one DOMAIN rule, that doesn't prove all related connections use the same policy. Use actual connection logs to identify additional targets instead of guessing based on the app's name.

DOMAIN-SUFFIX: Match a Domain and Its Subdomains

DOMAIN-SUFFIX,example.com,PROXY matches the domain and its subdomains, such as www.example.com and api.example.com. The suffix is matched at a domain-label boundary; it is not simply any string ending in those characters. Enter example.com directly. Don't add https://, a slash, or a path to cover subdomains. To exclude a specific host, put its exact-match rule before this broader rule.

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

This order means “connect the status host directly and proxy the rest of the example domain.” If you swap the first two lines, the suffix rule matches the status host first, leaving the exact exception no chance to run. The exception works because it appears first, not because DOMAIN automatically outranks DOMAIN-SUFFIX. Keep exceptions next to the broader rule they modify so their relationship is easy to review.

DOMAIN-KEYWORD: Broad Matches Require Careful Testing

DOMAIN-KEYWORD,example,PROXY matches a keyword in a domain and may cover multiple unrelated domains. It doesn't identify brands, site ownership, or page content, and it doesn't understand the meaning of an English word. Short keywords can match unintended hosts, especially when words run together in hostnames. Unless keyword matching is genuinely needed, prefer DOMAIN or DOMAIN-SUFFIX so you can verify the intent from the domain itself.

Why a Rule Based on a Web Address May Still Miss

The address bar shows the page's entry point, but page resources may come from other hosts. Redirects, sign-in checks, media, and API requests can each create separate connections. Check the connection log for the actual destination that failed, and distinguish a failed initial request from a failed follow-up resource. Don't try to match a path with DOMAIN just because it appears in the page URL: domain rules apply to hostnames, while URL paths are a different kind of condition.

The client also needs usable domain information for the relevant connection before a domain rule can match. Results may differ from what the address bar suggests if an app connects directly to an IP, handles resolution itself, or reuses an existing connection. Add address rules and a FINAL fallback after domain rules to cover connections that don't match a domain condition. Use the destination shown in the logs; “no domain match shown” does not automatically mean the rules failed to parse.

When organizing a long rule list, start with the narrowest exact-match exceptions, then add domain-wide coverage, and consider keyword rules only when there's a clear reason. Whenever you add a broad rule, test both a destination that should match and one that shouldn't. Testing only a successful case can miss false positives. Testing both helps catch keywords that are too short, incorrect suffixes, and exceptions in the wrong order.

Address rules select a policy based on the connection's destination IP; that is not the same as classifying where a website belongs. A domain may resolve to multiple addresses, and results can vary by network or over time. Services may also use distributed infrastructure. Treat IP-CIDR and GEOIP as address-level conditions, not fixed website categories. If the same domain connects directly sometimes and through a proxy at other times, compare the destination addresses in each connection before deciding whether an address rule affected the result.

IP-CIDR: Specify an IPv4 Network Range

IP-CIDR,192.168.0.0/16,DIRECT defines an address range; the prefix length after the slash determines its size. The longer the prefix, the smaller the range. To match one IPv4 address, use /32. The network address must align with the mask boundary. Don't put a regular URL, port, or arbitrary start and end addresses in this argument. For local network rules, use the address range actually in use on your network; don't assume one private range covers every local service.

[Rule]
IP-CIDR,192.168.1.10/32,DIRECT,no-resolve
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
IP-CIDR6,fc00::/7,DIRECT,no-resolve
FINAL,PROXY

The first line shows a single-address form; the second covers a larger range, so the first doesn't change the final policy in this example. It simply makes the scope relationship easier to see. If the policies differed, order would directly affect the result. For IPv6 addresses, use IP-CIDR6 with IPv6 prefix notation. Don't assume a connection uses IPv4 just because the browser displays a domain. If troubleshooting logs show an IPv6 destination, check the corresponding IPv6 rules and whether the network can reach it.

no-resolve: Control Resolution Triggered for Matching

The no-resolve option at the end of an address rule prevents a DNS lookup from being triggered solely to match that rule. It does not disable DNS for the app or block all resolution requests. If the destination is already an IP address, or connection handling already has an address available, this option does not mean the address rule will always be skipped. When domains should be handled first and address rules should apply only to known addresses, this option can avoid unnecessary lookups; confirm the result in actual connection logs.

GEOIP: Classify by Address Database

GEOIP,CN,DIRECT matches according to the destination address's classification in a database, not the domain suffix, page language, or user's location. The database may lag behind updates or differ in its attribution. It cannot prove who operates a service or where its data is stored. For a domain that needs a consistent policy, an explicit domain rule is usually easier to explain than an address classification. Use GEOIP as an additional condition only when you understand its limits.

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

This example handles explicit domains first, adds an address-based classification next, and leaves unmatched connections to FINAL. Once a domain rule matches, GEOIP isn't checked to choose a different policy. Conversely, an overly broad address rule placed earlier may prevent the later domain rule from taking effect. Different rule types don't vote against each other; they share one ordered sequence, and the first matching condition determines the outcome.

USER-AGENT: Requires Available Request Information

USER-AGENT,Example*,DIRECT demonstrates matching a User-Agent pattern. It is not the same as routing by app name and does not guarantee that every app on the device can be identified. The request must include the relevant information for a match to be possible. For encrypted HTTPS traffic, don't assume that turning on the connection switch makes HTTP request headers readable. If the information isn't visible, use domain or address conditions you can verify instead of continually broadening the pattern.

For troubleshooting, start with an explicit DOMAIN rule as a baseline before considering additional conditions such as USER-AGENT. Don't expand certificate trust or change a large number of request-handling settings just to test one rule. The target app may change request headers, use a different networking library, or reuse connections, which can change pattern matches. A rule's reliability depends on the input actually available to it, not on whether its name seems more closely related to the app.

A rule combines a match condition with a handling policy. The condition answers “Does this connection match?”; the policy answers “What happens if it does?” PROXY, DIRECT, and REJECT are different outcomes, not connection-quality levels. Changing every destination to the same policy may temporarily sidestep an issue but discards the routing intent of the original configuration. First define what each type of destination needs, then choose the narrowest suitable condition and policy.

Top to Bottom: Stop at the First Match

In the Rule sequence, the first rule that appears and matches determines the policy. Don't assume a more specific DOMAIN rule always overrides an earlier DOMAIN-SUFFIX rule, or that address rules naturally rank below domain rules. Exceptions only take priority when their position gives them priority. When reviewing a complex configuration, check from the first relevant rule downward; don't stop at the line that looks most intuitive after searching for the domain.

[Rule]
DOMAIN,private.example.com,DIRECT
DOMAIN,blocked.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, two specified hosts are handled individually first; the rest of the example domain uses PROXY. Connections that don't match a domain condition continue to the address rules, and only connections that matched none of the above reach FINAL. If FINAL is moved to the top, later rules no longer get a meaningful chance to match. FINAL takes no domain or address argument and is written as FINAL,PROXY; don't mistake it for a standard three-part rule.

A PROXY Match Doesn't Guarantee a Connection

A successful rule match only confirms that the selected policy met the condition. The server may still be unreachable, authentication may fail, the destination may refuse the connection, or resolution may fail. PROXY generally uses the currently selected proxy path. If your configuration uses named policies or policy groups, confirm that the referenced name exists and points to the intended selection. A typo, a deleted group, or a changed selection within a group may look like “the rule is correct, but nothing loads,” even though the problem isn't the match condition.

DIRECT does not guarantee that the current network can bypass access restrictions; it sends the connection directly to the destination. If the local network can't reach that destination, a DIRECT failure is a path issue. REJECT explicitly denies a connection; it doesn't fix page layout, remove cached content, or distinguish different uses of the same host. Rejecting an entire domain may affect sign-in and other resources hosted there. For more on these limits, see How REJECT Rules Work and Their Matching Limits.

Choosing a FINAL Policy

FINAL determines what happens to connections that match no earlier rule; it is not an “automatic judgment” switch. Choosing PROXY sends unclassified connections through the proxy path; choosing DIRECT connects them directly. Decide based on your configuration goals, the scope covered by existing rules, and the failures you can accept. Changing FINAL alone may affect many connections you haven't noticed before. Test both normal and problematic cases; don't stop after checking a single webpage.

Keep one clear FINAL rule at the end of the sequence. Multiple FINAL rules do not create a backup route; an earlier fallback ends evaluation first. Rule order is not a server failover mechanism either. If a PROXY rule matches and the connection fails, Shadowrocket does not automatically continue down the list to try a later DIRECT rule. Matching and establishing a connection are separate stages; later rules are not fallback steps after a connection fails.

As a rule list grows, remove exact duplicates, check for rules shadowed by broader rules above them, and keep a change log for important exceptions. Don't alphabetize the entire Rule section; doing so changes priority. Readability should support execution order: keep exact exceptions, scope rules, and supplementary rules in each group together, and make the final fallback easy to find. This makes it easier to check whether the configuration still matches your needs.

DNS resolves hostnames to addresses, routing rules choose a policy based on the available match conditions, and Host can map a specific hostname to an address. These concepts are related but not interchangeable. When a page won't load, determine whether no address was returned, the address was unsuitable, or the address was usable but the connection path failed. Changing every DNS setting may temporarily change what you see without explaining where the actual fault lies.

DNS Settings in General

dns-server = system uses the resolution settings provided by the system. The result depends on the current network; it doesn't mean every lookup returns the same answer. If your existing configuration uses another defined resolution setup, preserve its full behavior. First check that the field is recognized, the address is reachable, and the setting works with the rest of the configuration. Don't paste in a list of DNS addresses from the internet, especially with unfamiliar extra parameters, and then use that alone to judge whether your rules work.

[General]
dns-server = system

[Host]
router.example.com = 192.168.1.1

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

This example maps a specified host to a private address and explicitly assigns it DIRECT. It shows Host and Rule together to express two separate intentions: the resolution result and the handling policy. Mapping a hostname to a local address does not automatically mean it will connect directly; a DIRECT rule does not create the right address either. The device must be able to reach that private address, and the destination service must actually be running on the relevant port.

Host Does Not Change the Identity of the Destination Service

Host can change the address used for a connection, but it cannot turn another server into a legitimate service for the original domain. HTTPS also checks certificates and hostnames. Mapping to the wrong address may allow a network connection but still cause a certificate error or service mismatch. If that happens, remove the mapping and verify the address; disabling identity checks is not a routine fix. Private services also need correctly configured domains and certificates.

Remember that addresses can change when maintaining Host entries. After a mobile device switches networks, a private address that was reachable before may no longer be reachable or may point to another device. Fixed mappings suit clearly defined, stable, verifiable destinations; they are not suitable for permanently pinning one resolution result for a public service. A fixed IP for a domain using distributed addresses can bypass normal address selection and cause some regions or networks to fail.

How Resolution and Rule Matching Interact

Domain rules can match directly against a domain; address rules need usable IP information. Some address checks may involve resolution. As explained above, no-resolve controls whether a lookup is triggered for matching. If an explicit DOMAIN rule already matches, a later GEOIP rule won't override the result. When reviewing connection logs, consider the destination hostname, resolved address, matched rule, and final policy together; don't judge by the address's geographic classification alone.

If the log shows only an IP, don't immediately conclude that Host or DNS is broken. The app may connect directly to an IP, or the domain may not be shown at the current observation stage. Conversely, seeing a domain doesn't prove that every lookup followed the same path. Troubleshoot a reproducible request using the same destination, network, and a new connection, then identify which step provides the match information.

Caches and Existing Connections Affect Testing

After changing DNS settings or Host, existing connections may not switch to a new destination right away, and the app itself may retain resolved addresses. Save the configuration, re-establish the connection if needed, and have the target app make a new request. Don't use media that's already playing or a long-lived messaging connection to judge a new rule; it may have started before the change. Even after reloading a page, check the logs to confirm that a new destination connection was actually created.

If several unrelated domains fail to resolve, check the current network and resolution path first instead of adding Host entries for each domain. If only one domain is affected, check its spelling, existing mappings, and destination service status. Host is for managing specific addresses, not a general-purpose list for fixing every DNS issue. Keeping mappings few, explicit, and easy to undo usually helps mobile devices switch networks more reliably.

URL Rewrite and Rule have different jobs. Rule chooses a connection policy such as PROXY, DIRECT, or REJECT. URL Rewrite matches and modifies request URLs when they can be processed. To change the connection path for a domain, use Rule rather than URL Rewrite. Use URL Rewrite for conditions based on a full URL only after confirming that the request is visible and can be handled accordingly.

Understand What the Regular Expression Matches

The match pattern in URL Rewrite typically uses regular expressions. Pay attention to start anchors, escaped characters, and match scope. A dot in a domain has a special meaning in a regular expression; to match a literal dot, write \.. A leading ^ anchors the match at the start of the URL. Without the necessary boundaries, the match may be broader than intended. Don't put a regular expression directly in DOMAIN; they use different matching syntax.

[URL Rewrite]
^http://example\.com/old$ http://example.com/new 302

This example demonstrates redirect syntax only: it matches an exact path on a specified host, redirects the request to another path, and uses a 302 response. The trailing $ anchors the match at the end of the string, so a URL with query parameters won't automatically match in the same way. The destination is also a syntax example, not a service to test. Narrow, understandable conditions are easier to verify than broad matches and help ensure the redirect affects only the intended requests.

Query Parameters, Path Boundaries, and Redirect Loops

A URL's path, query string, and hostname are separate components. If query parameters should be allowed, define the match scope and how parameters are preserved; don't simply remove all boundaries and expect behavior to stay the same. Parameters may contain sign-in state, signatures, or one-time identifiers, and dropping them can break a request. For authenticated requests, preserve them where possible and first test the expression on a destination that contains no private information.

Also confirm that the rewritten destination won't match the same rule again. If the source scope includes the destination scope, the client or destination service may keep redirecting until the page reloads repeatedly or reports too many redirects. Multiple rewrite rules may also point back to each other. When troubleshooting, trace the sequence from the original URL to the rewrite target and then to any response from the server. Check each hop rather than only whether the first expression matches.

HTTPS Does Not Automatically Expose the Full Request

HTTPS encrypts paths and request headers, so don't assume ordinary routing makes the full URL available for inspection and rewriting. Domain-based routing being available does not mean path rewriting will work. For HTTPS request handling, separately understand the relevant in-app features, certificate trust scope, and how the target app validates certificates. Some apps use stricter certificate checks, so don't assume every request can be handled the same way.

REJECT Is Not Content Filtering

REJECT in Rule applies to matching connections; it doesn't analyze every element on a page. If a page's content and required APIs share a domain, rejecting that host affects both. URL Rewrite can express more specific URL conditions, but it is still limited by request visibility, protocol behavior, and the destination's response. Don't treat a rewrite or reject rule as a universal content-filtering solution, or assume that a page failing to load means the rule achieved its purpose.

When testing a rewrite, record the structure of the original URL, the expected destination, and the redirects that actually occur. Don't publicly share the full URL if it contains private parameters. Check that the destination still uses the required protocol and that no path or parameter was lost, then confirm that the page's functionality works. As with routing tests, verify a request that should remain unaffected to catch overly broad patterns that could disrupt sign-in, payments, or other necessary flows on the same site.

For easier maintenance, track temporary test entries separately from rules you need long term, and remove expressions that no longer have a clear purpose. After remote configuration updates, check whether related rules have changed their match scope. For more on REJECT policies and domain scope, see REJECT: How It Works, Its Scope, and Its Limits. Understand the boundaries of connection-level rules before deciding whether request-level handling is really necessary.

Effective troubleshooting answers four questions: What was the destination? Which rule matched? Which policy was used? At what stage did the connection fail? “It won't open” isn't enough to tell whether the problem is a rule, resolution, or connection path. Before testing, choose a destination you can revisit, record the current network, active configuration, and selected server, and avoid changing several conditions automatically during the test. Remove private address parameters and authentication details from any material you share.

Build a Minimal, Reproducible Rule Set

First make a recoverable copy of the configuration. Then add one narrowly scoped DOMAIN rule for the destination, placing it before any rule that might cover it. Save the configuration, confirm it is selected, and start a new connection in Config mode. Check the available destination, rule, and policy information in the request or connection logs; the interface may vary, so rely on what the current app displays. If the expected policy matched, stop changing match conditions and investigate resolution and reachability instead.

[Rule]
DOMAIN,test.example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
FINAL,DIRECT

This snippet deliberately separates one test host from other connections so you can observe rule selection; it is not a general-purpose configuration recommendation. Replace the example host with a real test destination you control. After testing, merge the effective changes into your original configuration and restore its intended fallback behavior. Don't overlook other necessary rules, general parameters, or local service exceptions just because this temporary snippet is shorter.

Troubleshoot by Symptom; Don't Blame Every Failure on Rules

Connectivity Test can help assess relevant connection conditions, but its result is not a substitute for the target app's actual requests. A successful test doesn't guarantee that the destination domain resolved correctly or that every protocol, port, and resource is available. A failed test also needs to be interpreted in the context of how it was performed. Use diagnostic tools to narrow the possibilities, then confirm behavior with a new connection to the actual destination.

Handle Subscription Updates and Rule Updates Separately

If an existing subscription update fails, first check that the address is complete, the current network is working, and the account is still valid; don't immediately rewrite Rule. An empty server list and an incorrect routing match are different kinds of problems. A single share link and a subscription address also use different update mechanisms; don't import one repeatedly as though it were the other. For entry points, see Four Ways to Import a Subscription. For format differences, see Share Links and Subscription Addresses Explained.

If behavior changes after a remote configuration update, compare the changed sections first, then check whether your exceptions are still present. Don't update the subscription, replace the configuration, and change the server all at once, then try to infer the cause from one result. For an empty subscription or parsing failure, see Subscription Update Failed or Server List Is Empty: Troubleshooting Checklist. This page covers configuration and matching logic, not recommendations for service providers.

Restore, Retest, and Maintain

If a change causes broader problems, first restore a known-good configuration copy and check whether Global Routing, server selection, and general settings were also restored. Re-establish the connection and retest the same destinations to confirm the baseline still works. Don't keep piling conflicting exceptions onto a broken configuration. Every temporary rule should have a clear purpose; otherwise, future troubleshooting will depend increasingly on guesswork.

For long-term maintenance, keep a short change log: which configuration section changed, why, which destinations passed testing, and how to roll back. Periodically check for outdated domains, duplicate rules, overly broad keywords, and Host mappings you no longer use. For purchase restoration, compatibility, and App Store search questions, see Restore a Previous Purchase and How to Check App Store Search Results. To follow the setup workflow again, return to the Getting Started guide.