Shadowrocket
Rules and Configuration Guide

Configuration file structure and editing

Shadowrocket configuration files contain rules and related runtime settings. Text-based files commonly use the .conf extension. A configuration file is not the server subscription itself, nor is it the server currently selected in Home. Understanding how these three pieces differ is the first step in reviewing rules: server details describe where to connect, a subscription collects and updates existing server entries, and a configuration file describes how requests should be handled. Check each separately to avoid mistaking a connection issue for a rule problem.

Section headers determine how the lines below them are interpreted

Names in square brackets mark configuration sections, such as [General] and [Rule]. Lines belong to a section until the next section header. General commonly contains key-value settings; Rule uses comma-separated match expressions; Host specifies hostname mappings; and URL Rewrite applies rewrites to request URLs. Even if two entries both involve domains, do not put a Host mapping or rewrite expression in Rule. The parser first interprets a line according to its section, then reads its parameters.

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

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

[Host]
example.com = 192.0.2.10

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

The snippet above illustrates section boundaries only; do not copy it as a complete configuration. The Host address is a documentation example, not an address for a live service, and the rewrite line demonstrates syntax only. For an actual change, copy only the small section needed for the issue into a copy of your own configuration. If you are testing domain routing, do not also add Host and URL Rewrite entries: changing several variables at once makes it hard to tell which change affected the result.

Check which configuration is active before editing

Open Config and confirm which configuration is in use before reviewing or editing it. A file appearing in the list does not mean it is the active configuration; copies with the same name may also be saved in different locations. Note the configuration name, its source, and the contents of a key rule before editing. After saving, return to Config and check the selection state so you do not mistake editing a copy for switching configurations. Menu locations may vary; refer to what is shown on your device.

Save a recoverable copy before making changes, and give it a descriptive name, such as “Daily Rules Copy.” Do not rely on memory or a few copied lines: the original file may also contain policy groups, rule references, or other DNS settings. If the configuration comes from an updateable source, find out whether an update will overwrite local edits. A remote update and a local save are not the same action. Recheck important changes after updates rather than assuming they will remain in place.

Text formatting and how to use snippets

Use standard ASCII commas, square brackets, and equals signs in rules. Chinese notes on their own comment lines can use Chinese punctuation, but a Chinese comma in a rule field may combine parameters that should be separate. After copying a snippet, check the start and end of each line for typographic quotation marks, list numbering, or invisible spaces. A long rule may wrap in the editor without containing an actual line break; each rule should still occupy one line.

Code blocks in this manual may show a standalone section or just a few rules to merge into an existing configuration. Add them to the appropriate existing section instead of repeatedly appending duplicate section headers, and keep fallback rules together. Do not delete other content just because it is not shown in an example here. Understand what the existing settings do before deciding whether to keep them; this helps avoid breaking a working setup while “cleaning up” the file.

If you are unsure what Home, Config, and Settings do, start with the interface terminology guide. The goal of editing a configuration is not to make the file as short as possible, but to make every section understandable and every change reversible. Before investigating matching behavior, you should be able to identify the active configuration, the exact line being changed, and how you will verify the result.

General and Global Routing

General contains common runtime settings, while Global Routing selects the overall routing mode. Both affect connections, but at different levels. If a rule does not seem to work, check Global Routing first, then the configuration text. If Config is not the active mode, editing Rule repeatedly may not produce the expected result. Conversely, if temporarily changing modes resolves the issue, that only narrows down the problem; it does not prove the server or entire configuration is correct.

How to use the three modes for review and testing

The table says “most requests” because system bypasses, local network conditions, and other client settings can still affect individual traffic. Global Routing does not override every system behavior and is not the same as the connection toggle. Proxy mode still requires an available server you already have; Direct mode does not guarantee that the current network can reach a given destination. For a useful comparison, keep the destination, network, and test time as consistent as possible so external changes are not mistaken for mode differences.

In Config mode, the Config selection shown in the interface and the [Rule] section both contribute to routing. PROXY at the end of a rule is the policy for that specific rule. The names are related, but they are not interchangeable. Writing Config at the end of a rule does not mean “use the configuration,” and selecting Proxy in the interface does not prove that a particular PROXY rule matched. Check the overall mode and the handling of each connection separately.

Two common General settings

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

bypass-system = true enables system-related bypass behavior. It is a boundary setting for connection handling, not a substitute for a domain policy. If you are using the existing default, start by checking Rule for the cause of ordinary traffic routing. Consider bypass settings as a test variable only when system traffic or a specific network service may be affected. Changing it casually can affect several types of requests and make a previously isolated issue harder to reproduce.

dns-server = system means the system-provided DNS settings are used. Here, system is a value, not a placeholder to replace with an arbitrary explanation. Results may vary across Wi-Fi, cellular, and other system network settings, so different DNS results after changing networks do not necessarily mean the rules changed. If the existing configuration specifies another DNS server, record its value before testing system DNS.

Do not copy a large set of unfamiliar General parameters just to make a configuration look complete. Settings may depend on one another, and snippets from different sources may assume different conditions. Keep the working baseline, change one parameter at a time to address a specific symptom, and note why you changed it. If a related option is available on your device, check both the in-app setting and the active configuration; the presence or absence of a key in the file alone does not determine actual behavior.

The connection toggle, On Demand, and rules do different things

On Demand controls when a connection is triggered under qualifying conditions; it does not replace domain rules. If the connection is not established, checking whether a domain matches Rule will not resolve an authorization or startup issue. If the connection is established but a destination takes the wrong route, repeatedly changing On Demand usually will not fix rule order. First check VPN configuration authorization, connection status, and the current network, then investigate how a particular request is handled. This separates when a connection is active from how its traffic is routed.

The system prompt shown on the first connection belongs to a different configuration layer from the rules file. See the VPN configuration permission prompt guide. If the issue involves frequent background activation or changes in battery use, see On Demand and battery use; do not try to fix every background behavior by removing Rule entries. Different layers require different evidence.

After checking General, establish a clear baseline: current network, active configuration, Global Routing mode, selected existing server, and whether On Demand is enabled. Keep this baseline unchanged while testing rules so that the relationship between an added rule and the result can be explained.

DOMAIN family rules

Domain rules select a policy based on the hostname associated with a connection, not a page title, app name, or the full text in the address bar. Before writing a rule, decide whether you need to match one exact hostname, an entire domain tree, or hostnames that contain a particular string. These needs correspond to DOMAIN, DOMAIN-SUFFIX, and DOMAIN-KEYWORD. A condition that is too broad can capture unrelated requests; one that is too narrow may match only the entry page and miss other domains used to load resources.

DOMAIN: match one exact hostname

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

The first rule applies only to api.example.com; it does not automatically include example.com or v2.api.example.com. The second shows how two hosts under the same root domain can use different policies. Exact rules are useful for verified exceptions, such as when most requests use the same route but one host needs separate handling. Do not include a scheme, path, query string, or port in the field; none is part of the hostname matched by DOMAIN.

If the request shown in the log is not the host you expected, check redirects and how the page loads its resources. After you enter an address, the page may also request login, image, or API domains. Adding DOMAIN for the entry host does not mean those requests will match. Check the host of the failed request first, then decide whether to add a rule. Do not broaden the match based on the name shown on the page; each added domain should have a clear connection to the issue.

DOMAIN-SUFFIX: match a domain and its subdomains

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

DOMAIN-SUFFIX,example.com,PROXY matches example.com and its subdomains. It checks the domain boundary rather than searching for an arbitrary string, so its scope differs from DOMAIN-KEYWORD. In this example, the exact exception comes first, followed by the suffix rule: local.example.com uses DIRECT, while the other matching hosts use PROXY. If the suffix rule comes first, the exact exception usually cannot take effect because the earlier rule has already matched.

Do not add *. to a suffix rule or write it as a regular expression. Adding example.com/path does not mean “handle only this path,” because a domain and a path are different match targets. Write separate rules for unrelated root domains instead of using an overly short suffix. Rules that reflect the actual domain boundary are easier to explain when reviewing logs and less likely to affect unrelated services.

DOMAIN-KEYWORD: match a broader string in the hostname

[Rule]
DOMAIN-KEYWORD,example,PROXY

DOMAIN-KEYWORD matches when the hostname contains the specified string. The example could match example.com as well as other domains containing example, so it is not shorthand for DOMAIN-SUFFIX. The shorter the keyword, the harder it is to predict what it will match. For a clearly defined set of domains controlled by one organization, consider exact hostnames or suffixes first. Use a keyword rule only when you really need to match a shared string across different domains.

Domain matching also depends on the client having hostname information associated with the connection. If an app connects directly to an IP address, or the connection record shows only a destination address, do not assume a domain rule has enough information to match. Check what the connection record actually shows before considering address rules, rather than adding several variations of the same domain rule. A resolved address and its original hostname are not always a one-to-one match.

To test a domain rule, choose a specific test hostname, close the old page, make a new request, and check the policy used. Browser cache, reused app connections, and background requests can all preserve old results. A rule is verified only when a new matching connection uses the expected policy. A page loading successfully is one result, but does not by itself prove that the rule covers the right hosts.

IP, GEOIP, and request conditions

Address rules use the destination IP or its geographic classification as a condition. They can handle defined IP ranges, connections that use an address directly, and further classification not covered by domain rules. They are not alternate spellings of domain rules. A domain may resolve to several addresses, and one address may host several domains; routing by address alone can affect other services on the same IP. It is usually easier to control the scope by expressing clear requirements as domain rules first, then adding address rules where appropriate.

IP-CIDR: understand the prefix, not the string

[Rule]
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
FINAL,PROXY

In CIDR notation, the number after the slash is the network prefix length, not a port or the number of addresses. A longer prefix generally covers a smaller range. The example lists common private IPv4 ranges, but your local network may not use all of them. Check your device's network details before writing a rule, especially on an organizational network or with a personal VPN, where the destination may not be on your current Wi-Fi subnet.

For a single IPv4 address, /32 represents a single-address range. Do not shorten a long prefix to bypass one destination; doing so changes how many other addresses are handled. If the issue is local device discovery, distinguish discovery traffic from subsequent connections to the device. Adding a private subnet rule alone does not guarantee that every local discovery mechanism will work as expected.

IP-CIDR6 and the limits of no-resolve

[Rule]
IP-CIDR6,fd00::/8,DIRECT,no-resolve
IP-CIDR6,2001:db8::10/128,DIRECT,no-resolve

IP-CIDR6 is for IPv6 addresses and cannot be replaced by an IPv4 rule. The second line uses a documentation example address to demonstrate a single-address prefix. When a device has both address families, different connections to the same destination may use different ones. An IPv4-only rule, without checking IPv6, can create the impression that a rule works only some of the time. Use actual connection records to investigate rather than relying only on the addresses shown in DNS results.

no-resolve prevents an extra DNS lookup from being triggered just to match this address rule. It does not disable system DNS or guarantee that an app will not resolve a hostname. If the connection already targets an IP, the address can still be compared directly. If only a hostname is available and there is no address information, the rule may not match as expected. When testing, be clear whether you want to match a known address or allow resolution before matching.

GEOIP: classify by the address database, not language

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

GEOIP matches based on how the destination address is classified in a geographic database; CN is the region code used by this rule. It cannot infer a match from a page's language, a domain suffix, or an organization name. CDN address routing can change, and database classifications may not match expectations. For a host that needs a consistent policy, put a specific domain rule before GEOIP rather than relying on a particular lookup to land in the expected region.

A GEOIP rule with no-resolve has the same limits around available address information. If it does not match, first check whether the destination IP and hostname are visible, then investigate its database classification. Blindly swapping GEOIP and FINAL will not help: FINAL belongs at the fallback position, and placing it before GEOIP prevents the latter from matching normally.

USER-AGENT: depends on visible HTTP information

[Rule]
USER-AGENT,ExampleClient*,DIRECT

The USER-AGENT condition comes from the HTTP request header, not the app name displayed on the device. The example uses a fictional header prefix to illustrate wildcard matching; it does not identify any real app. The client may not be able to read this information on encrypted connections, so do not treat it as an app-level routing rule that works for every request. Headers can also change with app updates or request types, so verify their stability separately.

Choose a rule type based on the evidence available: use a domain rule when you know the hostname, CIDR for a defined address range, and GEOIP when you need address classification. Consider USER-AGENT only when you have confirmed that request data is visible and the condition is stable. Choosing a rule based on observable information helps avoid repeatedly trying different conditions without being able to explain the result.

Policies, matching order, and FINAL

A rule usually consists of a type, a match value, and a policy; FINAL does not need a standard match value. The type determines what is checked, and the policy determines what happens after a match. PROXY, DIRECT, and REJECT are the three basic policies used on this page. They are separate from the modes shown in Global Routing. Read the condition first, then the result, and finally check whether the rule can be reached. Searching the file for a policy keyword alone is not enough.

What PROXY, DIRECT, and REJECT mean

PROXY does not create server details or guarantee a successful connection. Even when a rule matches, the connection may fail if the server is unreachable, protocol settings do not match, or the remote server cannot reach the destination. DIRECT likewise does not mean success is guaranteed; it selects a direct connection. REJECT explicitly blocks a connection and should not be used as a generic fallback when the cause is unclear. Rejecting an authentication or API request by mistake may make an entire app appear broken.

An existing configuration may also use named policy groups. If a rule ends with something other than these three keywords, check the original configuration for that group's definition and current selection. Do not casually replace a group name with PROXY and assume the existing selection logic remains unchanged. A group name copied from another configuration will not work by itself; the referenced group must be defined. Spelling, spacing, and name mismatches can all break a reference.

First match wins; rules are not automatically sorted by specificity

[Rule]
DOMAIN,local.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

Ordinary rules are checked in order. An earlier match determines whether later rules get a chance to apply. The example puts the exact exception before the suffix rule, then handles the private subnet and address classification, and ends with a fallback. It is not a fixed template for every environment; it shows one readable order. If a broad suffix rule is first, a more specific DOMAIN rule below it does not get automatic priority just because it is more specific.

Address and domain rules can also interact through their order. A broad address condition placed too early may prevent later domain exceptions from taking effect. Conversely, if an earlier rule matches a domain, its resolved address no longer determines the result for that pass through the ordinary rules. Troubleshoot by scanning from the top and finding the first matching rule; do not check only the rule you just added.

Duplicate rules can hide the real issue. If two identical conditions point to different policies, the later one usually will not take over as expected. Before removing duplicates, check whether they come from separate managed sections or an updateable source, then decide which layer to correct. In a large configuration, you can temporarily move one exact test rule up to isolate the issue, but restore the original organization after testing so you do not leave an unexplained priority patch.

FINAL is a fallback, not necessarily PROXY

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

This snippet sends requests matching example.com through PROXY and sends everything else through DIRECT. Changing the last line to FINAL,PROXY changes the route for all ordinary requests not matched above it. Either version may suit a different requirement; first decide what the default route should be, then add exceptions. Do not change your overall routing assumptions just because an example uses PROXY as its fallback.

Keep FINAL at the end of ordinary rules, with one clearly managed fallback. If you append DOMAIN or GEOIP rules after it, they may never take effect because traffic has already matched. Check the end of the file carefully: when combining snippets, it is easy to leave a FINAL in the middle and add new rules below it.

If the rule matches your intent but the destination is still unreachable, stop adding similar rules and investigate the connection path. See the connection failure troubleshooting checklist. The rules layer explains why a route was selected; the connection layer explains why that route succeeds or fails. Keeping them separate makes it easier to reach a reproducible conclusion.

Host mappings and DNS

Host maps hostnames to addresses; Rule selects the policy for a connection. They cannot replace one another. Mapping a domain to an address does not tell it to use DIRECT, and assigning PROXY to a domain does not fix its resolved address. When troubleshooting, record the requested hostname, actual destination address, and policy separately, then identify which layer differs from expectations. Whether a page loads often cannot distinguish these three changes on its own.

Host syntax and when to use it

[Host]
example.com = 192.0.2.10
api.example.com = 192.0.2.20

The left side is the hostname to map; the right side is the specified address. The address here is a documentation example, not a server you can access. Host entries do not use Rule's three-field comma-separated format, and do not end with PROXY or DIRECT. After adding an entry, check whether a fixed address is really needed and whether the service operator provided it. Do not permanently bind a dynamic service to an address just because one lookup returned it.

A fixed mapping bypasses some of the dynamic choices made during normal resolution. Addresses for services using CDNs, load balancing, or failover may vary by region, network, and time. An old mapping may work briefly, then lead to timeouts, certificate errors, or partially loaded resources. In that situation, include the related Host entry in your checks and compare with normal resolution first, rather than immediately adding more domain routing rules.

Host should not be understood as changing every part of a request's identity. With HTTPS, certificate validation is still tied to the requested hostname; specifying an IP does not mean an arbitrary site certificate will be accepted. If you see a certificate error, check the destination domain, mapped address, and device time. Do not lower trust requirements to hide a mapping issue. If the evidence is unclear, removing the mapping is an easier way to restore the baseline than widening the scope of changes.

How DNS and rules relate

DNS translates names into addresses. Domain rules can match a hostname when that information is available; address rules need suitable address information. They are closely related, but connections do not always expose the same information in the same order. App and system caches, as well as the resolution method used by a proxy route, may affect what you see. Record “the system lookup returned this address” separately from “this connection used this address.”

[General]
dns-server = system

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

This snippet illustrates the decision layers: the first rule handles a specific domain, the second matches an example address range only when address information is available, and the last is a fallback. It is not a general DNS fix. If api.example.com matches the first rule, resolving to an example range does not mean the second rule should apply. Conversely, a request made directly to an address, without an associated hostname, may follow a different matching path.

How to investigate DNS issues by symptom

If all domains fail but a known-address connection behaves differently, first check the current network's DNS resolution, DNS settings in General, and whether a Host entry overrides resolution. If only one domain is affected, check its spelling, expired mappings, service status, and any REJECT rules. Do not assume a blank page means DNS failed: the page itself may have loaded while a later API or authentication request failed.

When switching between Wi-Fi and cellular, note the network change. System DNS, IPv6 availability, and local network access can all differ. If behavior changes with the same configuration, check these inputs instead of keeping two contradictory sets of rules to “adapt.” The purpose of a comparison test is to identify the source of the difference. The final configuration should explain it, not merely record which network happened to work.

After changing Host or DNS, establish a new test connection; an existing connection may still use the previous address. If needed, close and reopen the target app, then check the new request records. Refreshing a page does not necessarily refresh all network state. Avoid changing several settings at once and recording only “a restart fixed it.” Keep a record of the order of changes so you can tell whether the result came from a new lookup, the end of an old connection, or another action.

A useful DNS investigation ends with facts you can verify: the affected hostname, network at the time, whether a mapping existed, the address actually used, and the final policy. If these details are incomplete, changing more General parameters only adds uncertainty. You can also check common connection and resolution issues against the FAQ.

URL Rewrite and matching scope

URL Rewrite changes or redirects visible request URLs; it is not the same as Rule's route selection. Rule answers “which policy handles the connection?” URL Rewrite answers “what happens to a request URL that matches?” If you only need example.com to use PROXY, write a domain rule instead of adding a rewrite expression. Use the rewrite section only when you really need to change a request URL and understand the expected behavior.

Parts of a redirect expression

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

This line contains a match expression, replacement URL, and handling method. The example uses 302 for a temporary redirect: when a visible request URL matches the expression on the left, the response redirects to the URL on the right. It deliberately uses HTTP and an exact, complete path to keep HTTPS visibility and complex path captures out of this basic syntax example. The example domain is for illustration and does not represent a service to test.

In the expression, ^ anchors the match to the start, $ anchors it to the end, and \. matches a literal dot. Without escaping, a dot in a regular expression usually has a broader meaning. Without the ending anchor, URLs with extra paths or query strings may also match. Explain each symbol as you edit; an expression that looks like a URL is not necessarily equivalent to ordinary URL text.

The replacement URL must also be complete and specific. Changing HTTP to HTTPS does not mean the destination serves the same content at that address. Changing the hostname or path may also affect login state, cross-origin requests, and API behavior. A rewrite changes only the specified request handling; it cannot create a page on the destination service. An app that does not accept redirects may fail even when the expression appears to work in a browser.

Limit the scope before adding complexity

For an initial test, start with one host and one path instead of a pattern that covers every domain. After confirming that an exact match works as expected, consider whether subpaths or query parameters need to be included. For each expansion, list the new kinds of requests it will match. If the replacement must preserve query parameters, specify how they are passed into the replacement URL; do not assume they will be retained automatically.

Capture groups, escaping, and configuration text are separate concerns in regular expressions. Editing directly in a configuration file may require different escaping from embedding the same text in another format. Do not copy double escaping shown on an information page and assume the configuration needs the same number of backslashes. The code here shows the configuration text itself; inspect each character in the editor after copying instead of adding another layer of quotes or escapes.

When a rewrite section contains multiple expressions, avoid overlapping conditions and arrange them from specific to general. Do not copy Rule's FINAL into URL Rewrite; they use different syntax. If your existing configuration has complex rewrite combinations, make a copy with the related set temporarily disabled for comparison, then enable and test the target expression on its own. Do not append several rules from unknown sources at once and check only whether a page loads.

HTTPS, certificates, and request visibility

HTTPS protects request contents. Knowing a domain does not mean the client can read the full path or perform arbitrary rewrites. Whether a request can be handled also depends on the actual feature settings and connection conditions. This example does not require HTTPS decryption or certificate installation as a prerequisite for understanding rules. If domain routing meets the need, prefer Rule because its scope is clearer.

Assess certificate and trust changes separately, and do not accept a configuration of unknown origin just to make a rewrite snippet “work.” A certificate error, an app rejecting a connection, and a rewrite not matching are different symptoms. Record the actual system or app error first, then determine whether the request reached a layer where it could be handled. Otherwise, you may mistake a visibility limitation for a regex error and keep widening the match.

Recognize loops and cache-related false positives

If the replacement URL also matches the original expression, it may cause repeated redirects. A browser may show multiple redirects, an error page, or a page that never loads. To troubleshoot, write down the starting URL, replacement URL, and whether the replacement still matches. After verification, keep the condition specific enough to avoid relying on the browser happening to stop before a loop continues.

Apps may cache redirect results, so old behavior might persist briefly after you disable an expression. Make a new request and record how the URL changes; if needed, end the target app's old session. If the issue remains after restoring the original configuration, check the cache and destination response before concluding that the configuration failed to save. A rewrite investigation is complete only when you can explain every step from the original URL to the final one.

Configuration validation and troubleshooting order

The goal of configuration troubleshooting is to find the smallest cause that explains the symptom, not to keep switching every setting. Before starting, record the current network, Global Routing mode, configuration name, existing server, and target request. Then write down one specific expectation, such as “new connections to api.example.com should use PROXY.” The more specific the goal, the easier it is to verify. “Everything works again” is useful as a final check, but not as the first test for one rule.

Start from the connection baseline; do not change rules yet

First confirm that Shadowrocket has VPN configuration authorization and can establish a connection. If the connection will not start, check the system prompt and connection status first. If it connects but the existing server is unreachable, check the server details and network. Investigate Rule only after the basic connection can be tested. Connectivity Test can provide clues, but one successful test does not verify every domain, protocol request, or rule.

Next, confirm that Config is selected in Global Routing, and that the active configuration is the file you just edited. Saving a copy while continuing to use the original is a common source of confusion. Compare a distinctive rule in the file, save, and reconnect if needed. If the app reports a parse error, fix the file syntax first; do not infer matching behavior from an invalid configuration.

Check conditions, order, and policy one layer at a time

1. Check whether the hostname or destination address associated with the actual request matches the rule fields.
2. Scan downward from the start of Rule and look for an earlier matching condition.
3. Make sure FINAL does not cut off later ordinary rules.
4. Check the matched policy or named policy group and the route it actually uses.
5. Test again with a new connection and compare the result with your notes from before the change.

If the request hostname differs from the rule, start with the match target. If the hostname matches but the result uses another policy, check rule order or configuration selection. If the policy is correct but the connection fails, investigate the route and destination. This branching avoids a common cycle: add a domain rule when a connection fails, change DNS when that fails, then broaden a keyword. Each test should answer one question, not try to prove every setting at once.

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

This minimal snippet illustrates the troubleshooting method only; do not use it to replace your entire configuration. Test in a saved copy, temporarily using one exact condition to rule out interference from broader rules. If it produces the expected policy, restore the original rule sections gradually. If not, check whether request details are visible, the configuration is active, and the current mode is correct. This gives you a more reliable answer than adding more rules with similar conditions.

Group symptoms into checks you can repeat

For intermittent issues, record the time, network, and destination for every failure instead of keeping only a successful result. A page may reuse an old connection, or a service may change its resolved address; repeated requests do not necessarily use the same inputs. Base your observations on a new connection associated with the test, not on background sync or traffic from another app.

If you need to review Data or related diagnostic records, collect only the information needed for the target request. Full records may contain domains, paths, query data, and personal identifiers; remove sensitive details before sharing. When describing the issue to someone else, provide a redacted rule snippet, current mode, and reproducible steps rather than the entire configuration or subscription URL. A clear way to reproduce your reasoning is more useful than a large amount of unrelated data.

Restore, tidy up, and continue your review

Once you identify the cause, keep only the changes needed to resolve the issue and remove temporary broad rules, Host mappings, or rewrite expressions used for diagnosis. Check other destinations you use regularly, especially requests previously covered by exceptions. Save a new recoverable copy and note the purpose of the change. If the configuration can be updated, review key content after the next update to confirm your local changes were not replaced.

For routine imports and your first connection, continue with the Quick Start Guide. For purchase, app ID, and developer verification, see the genuine App Store purchase guide. For common questions, see the FAQ. This reference explains how configuration expresses intent; verify actual results one by one using new connections and observable records on your device.