Shadowrocket Configuration Fields
and Rules Reference

Configuration Structure: Understand What Each Section Does

Shadowrocket configuration files typically use .conf format. Names in square brackets identify sections; lines within each section define settings, mappings, or rules. A configuration is not a single list of parameters: the same text can mean something entirely different—or fail to parse—when placed in another section. When reviewing an unfamiliar file, start by locating section boundaries, then inspect individual fields. This gives you a clearer picture of the configuration than searching for a domain name alone.

What the Four Common Sections Do

[General] contains global behavior settings, such as DNS options. [Rule] defines traffic-matching conditions and their policies. [Host] maps specified domains to addresses. [URL Rewrite] processes URLs that match expressions. These sections operate at different stages and are not interchangeable. To route a domain directly, start with a rule; do not change DNS mappings indiscriminately to alter traffic routing.

Learn the Syntax from a Minimal Example

These snippets demonstrate three forms: sections, assignments, and rules. An equals sign assigns a setting; commas separate rule fields. They are not interchangeable. In a rule, PROXY is a policy, not a server address. The example does not include your server details and is provided for reference only. Before using it, make sure you have an existing, usable server configured in the app and have selected the connection you intend to use.

[General]
dns-server = system

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

When reading a file line by line, check commas and equals signs first, then keywords, the number of parameters, and policy names. Full-width punctuation from an input method can look similar to standard punctuation but may not work as a separator. Keep section names unchanged. Invisible characters at the beginning or end of a line, or rich-text formatting copied along with the text, can also break an otherwise valid rule. Use a plain-text editor and keep the file clearly organized with blank lines.

Configuration Files vs. Rule Snippets

Most code blocks on this page show only the relevant section. Do not concatenate every example into one file: they may describe separate scenarios. In particular, multiple FINAL rules do not form a stack of fallback policies. When adding a snippet to an existing file, merge it into the corresponding section, check for similar rules already there, and choose its position deliberately. Avoid duplicate sections and conflicting policies that make the file harder to understand.

A server subscription and a configuration file contain different kinds of data. A subscription typically provides or updates server entries; a configuration defines connection behavior. Having one does not mean the other is ready. Get subscriptions from your service provider, and make sure the data format matches the import option you use. If you are unsure what kind of link you have, see the subscription import guide. Repeatedly switching configurations will not fix a link-format mismatch.

The goal of this chapter is to understand what each section does—not to fill in every section. Leave out features you do not need. A short, clearly explained configuration is easier to verify. For unfamiliar fields, check the in-app documentation and actual behavior; a setting appearing in another configuration does not mean it is suitable for your device or network.

General: Global Settings and Global Routing

[General] contains configuration-level global settings, while Global Routing is where you choose a runtime routing mode. They are related but operate at different levels: even after writing rules in a file, check that the current mode uses them. If rules appear to have no effect, check the mode and active configuration before changing fields. Otherwise, you may keep adding rules based on the wrong assumptions.

The Config, Proxy, and Direct Modes

The configuration mode is Config, which handles connections according to the active configuration. Proxy routes connections normally handled by the app through the proxy path. Direct uses the direct path. These are overall routing choices; they do not mean every system connection follows the same path. System-level behavior, existing connections, and traffic outside the app's handling scope cannot be determined by the mode name alone.

If the same destination is reachable in Proxy but fails in Config, check rule matches, the DIRECT path, and DNS differences. That alone does not prove a particular rule is wrong. Keep the server, destination, and network conditions the same for both tests. After comparing results, restore the original mode so a temporary test setting does not become your everyday setup and make later behavior harder to reconcile with the configuration.

DNS Settings Are Not Traffic Policies

DNS resolves domain names to addresses; rules determine how connections are handled. A successful lookup does not guarantee that the connection will work, and selecting PROXY does not tell you how every DNS request is handled. DNS behavior can also depend on app settings, caching, network conditions, and request type. Check “which address was resolved?” and “which policy handled the connection?” as separate questions.

[General]
dns-server = system

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

dns-server = system uses the system DNS settings as the source for this option; it does not guarantee that the current network will return suitable results. Treat it as a starting point for understanding the syntax, not as a universal recommendation. If you change DNS behavior, record the original value, change one setting at a time, and test both the target domain and other commonly used domains. A fix for one destination could affect other requests.

Defaults and Explicit Settings

Removing a general setting from the configuration usually hands control back to default handling; it is not necessarily equivalent to setting the field to a particular Boolean value. Default behavior may also depend on app settings, so do not assume that a missing line means a feature is disabled. When migrating a configuration, keep fields with a clear purpose. Test unclear options in a copy rather than applying a whole set of so-called optimization settings at once.

Settings involving IPv6, DNS, and network ranges can affect what connection information rules can see. For example, a destination may prefer an IPv6 address while the configuration contains only IPv4 ranges. A generic toggle will not necessarily explain the whole issue. Check the actual connection address first, then decide whether to add an address rule, adjust DNS behavior, or keep the default. Changing address-family behavior may affect other services, so retest them as well.

Manage On Demand Separately from Configuration Rules

On Demand controls when a connection is established; [Rule] controls how traffic is routed once it is being handled. Domain rules are not On Demand triggers, and an automatic connection does not prove that a particular rule matched. Check the On Demand conditions in the app, then verify configuration rules separately. Record the results of each process independently to keep troubleshooting clear.

The goal of general settings is predictable behavior, not a more complex file. Before examining rules, confirm that the current mode is Config, the expected configuration is active, and the selected server is available. If you have not established a basic connection yet, return to the quick-start guide to check system permissions and connection steps. The remaining chapters assume that a basic connection can already be verified.

Domain Rules: Exact Matches, Suffixes, and Keywords

Domain rules specify which policies apply to which hosts. They are often easier to maintain than tracking changing server addresses, provided the domain information is available when the connection is handled. A page URL, the host an app actually connects to, its sign-in service, and its resource domains may all differ. Copying only the main domain from a browser's address bar will not necessarily cover every request made during a visit.

DOMAIN: Match an Exact Hostname

DOMAIN matches a complete hostname. The first rule below applies only to api.example.com; it does not automatically include other hosts at the same level. Do not include a scheme, path, or port in the domain field: https:// and /login are other parts of a URL, and adding them to a DOMAIN field will not route traffic by page path. Use this rule when you need a clearly defined match.

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

When maintaining exact-match rules, add a brief comment for each exception explaining why it differs from other hosts. Comments should describe the use case or test result, never account details, tokens, or complete sensitive links. If the number of exact rules grows, group them by service before considering a suffix rule. Widening the match just to reduce the number of lines can cause unexpected matches.

DOMAIN-SUFFIX: Match a Root Domain and Its Subdomains

DOMAIN-SUFFIX,example.com,PROXY applies to example.com and its subdomains, such as www.example.com and api.example.com. It matches at domain-suffix boundaries, not arbitrary string occurrences, so do not assume it will cover a differently spelled domain that merely looks similar. Use the root domain without a leading asterisk or a path.

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

This order handles exceptions first, followed by the broader range. A request to local.example.com matches the exact rule above; other matching subdomains can then reach the suffix rule. If the suffix rule comes first, later exact rules do not automatically take precedence just because they are more specific. Rules are not browser style selectors: the app does not scan the whole list and choose the most specific match.

DOMAIN-KEYWORD: Assess the Match Range First

DOMAIN-KEYWORD checks whether a domain contains a specified keyword, so its scope is broader than that of an exact domain rule. The keyword may appear in unrelated domains, so use this rule only when there is a genuine naming pattern and you understand its scope. A brand name, short abbreviation, or common English word is not automatically a reliable boundary for a service; it may route unrelated connections through the same policy.

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

The snippet above demonstrates DOMAIN-KEYWORD syntax; it is not a recommended everyday routing setup. This rule matches a string, not site ownership, service type, or page content. If connection logs show a stable full hostname, consider DOMAIN or DOMAIN-SUFFIX instead. Their meaning is easier to read and can be verified with a limited set of tests.

Why One Visit May Need Multiple Rules

Sign-in, images, APIs, and media may use different domains. If the main page works but sign-in fails, check the actual host of the failed connection instead of immediately broadening the match to a vague keyword. Add clearly identified domains one at a time and retry to confirm that each new rule changes the intended connection. For redirects, also check the destination after the redirect: a match for the original host does not prove the final destination uses the same policy.

If the logs show only an address and no usable domain, adding more DOMAIN rules may not help. Check whether the request uses an address directly, whether domain information is available, and whether an address rule matched first. Domain rules match known hosts; they do not discover services. For related questions, cross-check the routing troubleshooting guidance in FAQ.

IP and Request Conditions: GEOIP, IP-CIDR, USER-AGENT

Use address rules when a destination is represented by an address or you need to describe a network range. They differ from domain rules in what they match: domains describe hostnames; address rules describe connection destinations. A domain may resolve to multiple addresses, and one address may serve multiple domains. Address rules are best suited to defined network ranges, not as a blanket replacement for domain rules without supporting evidence.

IP-CIDR: Address and Prefix Length

IP-CIDR describes an IPv4 network using an address and a prefix length. The number after the slash is the network prefix length, not a port or connection count; a larger number covers a smaller range. Use /32 for a single IPv4 address. Check the actual network range before writing a rule: mistaking one device address for a larger subnet could route other connections through the same policy.

[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

These snippets show a DIRECT policy for common private address ranges, but whether you need all of them depends on the device's network. A rule selects a policy for traffic within the app's handling scope; it cannot make a router allow access or replace local network permissions and destination-device settings. If the destination is on another network, setting it to DIRECT will not create a path to that network.

What no-resolve Does—and Its Trade-Offs

no-resolve is an option for address rules that avoids triggering a DNS lookup just to try the rule. It does not mean “disable DNS,” nor does it mean that a later connection will not need resolution. Address targets can still be checked against a network range; for a request that has only a domain and no available address, do not expect this rule to resolve it and then match. This option is often used with local network address rules to avoid unnecessary lookups.

If you want to route based on the address returned for a domain, understand how no-resolve may change the matching conditions before adding it. When troubleshooting, compare requests with and without address information rather than repeatedly toggling the option. Do not copy this option mechanically into DOMAIN or FINAL rules; rule types have different field requirements.

GEOIP: Depends on Address-Location Data

GEOIP uses address-location data to determine a region; CN in the example is a region code. It does not infer a region from a site's language, company location, or domain suffix. With distributed services, the location associated with a resolved address may differ from expectations, and the data may be out of date. For stable exceptions, put explicit domain rules first instead of using a regional rule to identify a service.

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

This example preserves an explicit policy for api.example.com, then tries a regional match for other connections. Without the exception, the domain could use DIRECT if it resolves to an address that meets the regional condition. To check whether the configuration behaves as intended, inspect the actual matched rule and destination address—not just the site name. Also verify the address data and settings currently available in the app.

IP-CIDR6 and USER-AGENT: Know Their Limits

IP-CIDR6 matches IPv6 network ranges. The address below is from a documentation-only range and demonstrates prefix syntax; it is not a real service address. IPv4 rules do not automatically cover IPv6 destinations. If a connection uses IPv6, address that specific need; an IPv4 rule failing to match does not mean the entire rule list is broken.

[Rule]
IP-CIDR6,2001:db8::/32,PROXY
USER-AGENT,ExampleClient*,PROXY
FINAL,DIRECT

USER-AGENT depends on User-Agent information visible in a request and can use wildcards to match strings. ExampleClient in the snippet is illustrative, not a real app. This rule does not match an installed app by name or act like process-based matching. If the request does not include the relevant information, it is not visible, or the client changes its identifier, the rule cannot provide the expected coverage.

Do not assume ordinary routing can read HTTP request headers inside encrypted connections. Do not broaden decryption settings just to make a USER-AGENT rule work. The basic routing examples on this page do not require this kind of processing. Prefer domain or address conditions that you can observe and verify; treat USER-AGENT as a specialized option with specific prerequisites, not a general way to identify services.

Policies and Precedence: The First Matching Rule Decides

The left side of a rule defines its condition; the right side specifies the policy to use when it matches. PROXY, DIRECT, and REJECT are the most common policy keywords for proxying, direct connections, and rejecting traffic. A match does not guarantee that the destination is reachable: it only means the handling choice has been made. The server may be unavailable, the destination may refuse the connection, or network conditions may cause a failure. Verify policy selection and path availability separately.

Both PROXY and DIRECT Need a Working Path

PROXY uses the processing path associated with the current proxy selection; it cannot provide a working connection if server details are missing. If the selected server is unavailable, a correctly written rule will still fail. DIRECT depends on whether the device's current network can reach the destination; it is not a higher-level fix than proxying. Test both paths with the same destination. Rule text alone cannot tell you which will be faster or more reliable.

REJECT explicitly rejects matching requests. It expresses a policy; it is not a fallback when a connection fails. Before rejecting a broad domain range, check whether it includes sign-in, verification, or resource APIs. Otherwise, the main page may load while some features keep failing. Check rejection logs first rather than changing server settings.

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

Put Specific Rules Before Broader Rules

Rules are generally evaluated from top to bottom, and the first match determines the policy. The app does not check every condition and then pick “the most specific one.” The order above handles two exceptions first, then applies the suffix rule to the rest of example.com. If the suffix rule is moved to the top, it will catch those exceptions first. Read the configuration as a sequence of decisions, not as a list to search for the presence of a particular rule.

Precedence comes from a rule's position, not its keyword. DOMAIN does not automatically outrank DOMAIN-SUFFIX, and domain rules do not automatically outrank address rules. For readability, you can organize rules as explicit exceptions, service ranges, network ranges, and a final policy. This is a convention for maintainers, not automatic sorting by the app. After importing, check the actual list to ensure the intended order was preserved.

FINAL Is a Catch-All, Not Automatic Failover

FINAL does not require a domain or address condition. It is usually placed at the end of the rule list to specify what happens when no earlier rule matches. It does not mean “try this after the previous connection fails.” If a rule matches PROXY and the proxy connection fails, the next DIRECT rule will not automatically take over. Condition matching and path failures are separate issues; confusing them leads to incorrect fallback designs.

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

This snippet routes only the explicitly specified range through PROXY and sends everything else DIRECT. Change the last line to FINAL,PROXY to send unmatched traffic through the proxy path instead. Both designs express a clear intent; neither is right for every situation. Decide which services need explicit exceptions, then retest destinations without dedicated rules after changing the final policy. Testing only the domains listed in the file is not enough.

Check for Conflicts by Tracing Rules in Order

To trace a destination manually, write down its actual domain and address, then check each rule from the top: “Does the available information meet this condition?” Stop at the first match and note its policy and position. If your result differs from the connection log, check the active configuration, DNS result, existing connections, and whether both checks used the same destination information. This helps distinguish a broad rule blocking a later match from a misplaced exception or missing catch-all.

Do not use duplicate rules to express precedence or rely on multiple FINAL rules to guess what happens. Before removing duplicates, check whether they use different policies or options. After merging, keep one clearly ordered set of rules. A well-maintained file lets you explain why common destinations match a particular line; it is not a matter of having more rules. If the policy is correct but the connection still fails, move on to connection diagnostics instead of stacking more rules with the same condition.

Host and URL Rewrite: Address Mapping and URL Handling

[Host] and [URL Rewrite] often appear alongside rule sections, but they are not alternate spellings of traffic-routing rules. Host changes a domain's address mapping; URL Rewrite processes URLs that match expressions; Rule determines the connection policy. Decide whether you need to change the address a name maps to, the request URL, or the connection path before choosing a section. This avoids changing several layers and then being unable to explain the result.

Host Mappings Need a Valid Destination Address

The Host example below maps a complete hostname to a documentation-only address. It demonstrates syntax and cannot be used to reach a real service. Use a fixed mapping only if you know the destination address, have confirmed that the service accepts the hostname, and can keep the address up to date. Shared hosting, load balancing, and service migrations can all make a fixed address stop working.

[Host]
api.example.com = 192.0.2.10

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

A Host entry does not specify DIRECT or PROXY. In this example, the connection policy is determined by the Rule section; a successful mapping does not prove that the policy is correct. Even if the domain resolves to the specified address, the destination must still serve the right service, and its certificate must match the hostname you are using. If you encounter a certificate or host error, restore the mapping and verify the destination rather than weakening validation to hide an address-selection problem.

If a domain worked before a fixed mapping but fails afterward, remove or restore that Host entry and retry under the same conditions. The service address may have changed, or the network may return different reachable addresses. Record results before and after the mapping to determine whether it caused the problem. For domains you cannot maintain over time, normal DNS resolution is often more consistent than manually pinning an address.

The Three Parts of a URL Rewrite

A URL Rewrite rule usually contains a matching expression, a replacement target, and an action. The example redirects an HTTP URL for a specified sample domain to HTTPS: the expression matches from the beginning of the URL, parentheses capture the path, $1 inserts the captured text in the replacement, and 302 specifies a redirect. This is a standalone syntax example, not a recommendation to add the same rule for every site.

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

Escape dots in the expression to match literal dots in a domain; an unescaped dot usually has a broader meaning in regular expressions. The leading ^ anchors the match to the start of the URL and reduces accidental matches against other URLs containing similar text. Test both requests that should match and requests that should not, rather than confirming just one successful case.

A Redirect Does Not Change the Proxy Policy

A redirect causes the client to make a new request, and the new destination is handled according to the applicable rules. It does not set the original connection to PROXY or fix an incorrect server password or protocol setting. If the replacement changes the hostname, check the rules for both the original and destination hosts. Redirect loops often occur when rules point back to each other or conflict with server-side redirects. Disable the relevant Rewrite rule first to narrow down the cause.

Whether a URL can be processed also depends on the protocol, request visibility, and relevant feature settings. A plain HTTP example does not show that arbitrary HTTPS paths can be read. The paths and request headers of encrypted connections are not inherently visible to ordinary routing, and this page does not require additional decryption features. If you only need to route by host, use domain rules and keep the handling scope aligned with your needs.

Document When Each Mapping Should Be Removed

A useful maintenance note explains not only why an entry was added, but also when to remove it. For example, restore normal resolution after testing a service address; review a migration redirect once the entry point has been unified. Temporary entries without a removal condition can become a lasting source of problems. Before editing, search for the domain in other sections so that restoring one entry does not leave another change affecting requests.

When a connection behaves unexpectedly, list the original URL, mapped address, rewritten URL, and final matched policy in order. If any of the four differs from your assumption, investigate that layer first. This helps distinguish an outdated address, an overly broad expression, a destination redirect, and an incorrect policy instead of attributing every issue to broken rules. Build complex behavior on top of a verified minimal configuration.

Importing and Maintaining Configurations: Track Sources, Selections, and Rollback

Configuration management is not about how many files you keep. It is about knowing what is active, what an update may overwrite, and how to restore a verified state. Get existing subscriptions from your service provider. Before importing, identify whether the link provides a server list, a complete configuration, or other data. Different import options may expect different formats; a link opening in a browser does not mean it is in a format the selected import option can parse.

Identify the Data Type Before Importing

Updating a server subscription may change server names, the number of entries, and their parameters. Updating a rule configuration may change policies and their order. Track these separately. If you only want to add existing servers, do not replace an already verified configuration just to make an import work. If you are importing a complete configuration, first check whether it contains additional settings such as General, Host, or Rewrite, and understand how they may change existing network behavior.

When managing files in Config, confirm after importing that the expected configuration is selected. A file appearing in the list does not mean it is active, and editing a copy does not switch the app to that copy. Use descriptive filenames to distinguish everyday and test configurations, and note which one is selected. Follow the import options shown in the app. If this is your first time, see the setup guide.

Keep Each Change Small Enough to Verify

For example, if you want a local service to connect directly, start by adding one exact-domain rule instead of replacing DNS, adding network ranges, changing FINAL, and adding Rewrite all at once. Every additional variable creates another branch to explain. Keep a copy, edit only the relevant section, retry the same destination, and check that other commonly used destinations still work. Expand the rule's scope only after the initial change succeeds.

# Add a DIRECT exception for local.example.com only
[Rule]
DOMAIN,local.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,PROXY

Comments should state what changed and how you verified it—not just say “optimized,” “fixed,” or “faster.” Do not put real subscription tokens in filenames, comments, or test notes. Subscription links may contain access credentials; remove full query strings and sensitive server details before sharing them for troubleshooting. The syntax needed to explain a rule does not require exposing real credentials.

Treat Remote Updates and Local Edits Separately

A remote configuration update may replace local changes, depending on how you manage the file. Before updating, record custom entries and their positions; afterward, compare rule order, the final policy, and additional sections. Do not assume that the contents are unchanged just because the filename is the same, and do not immediately import multiple copies when a rule disappears. First confirm which file was updated and which one is active, then restore any necessary custom entries.

Check for changes to server entry names as well. If another part of the configuration refers to a name, a mismatch after an update can break that reference. Even if this page mainly uses built-in policies, verify that the selected server is still the intended one. After importing or updating, separately test server connectivity, Config mode, and rule matches so that a server update issue is not mistaken for a syntax error.

Restoring a Configuration Does Not Restore Purchases or Account State

Configuration files control network behavior; they do not restore App Store purchases. Shadowrocket is a paid Apple-platform app, and the App Store is the only place to get it. For purchase and restore information, see Restore Purchases. Check the App Store page for system requirements. A one-time client purchase is not a service plan; buying the app does not add servers to a configuration, which still requires your existing service details.

Before switching devices, save the configurations and server information you need to keep, and know where sensitive data is stored. System backups, in-app imports, and App Store purchase restoration serve different purposes and are not interchangeable. Being able to open the app after reinstalling does not prove that your rules, subscriptions, or selected settings were restored. Check each item in order to avoid confusion when importing old files.

If a subscription update fails or the list is empty, check the link format, validity, and provider-side status first. Rewriting the Rule section will not fix a parsing issue. See how to troubleshoot failed subscription updates or an empty server list. After maintenance, keep the latest verified copy and remove unused test files to reduce the chance of selecting an outdated configuration.

Testing and Troubleshooting: Trace the Actual Match

Verify rules with a clear chain of evidence: which configuration is active, which Global Routing mode is in use, the request's actual destination, the matching rule, the resulting policy, and where the connection failed. “The network is down” is not specific enough to identify the issue. Narrow the test to one destination and one request, then check each processing layer. This is usually more effective than repeatedly replacing the entire configuration.

Step 1: Keep Test Conditions Consistent

Record the current network, selected server, and configuration name, then choose a destination you can access repeatedly. Keep conditions stable during testing; do not change the network, server, and rules at the same time. The app may reuse an existing connection, and an open connection may not be rematched immediately after a configuration change. If needed, end the relevant request and start it again before checking the new connection log. Do not treat an old connection's result as evidence of how a new rule works.

Use the snippet below for a minimal comparison, testing it in a copy and replacing the example domain with a destination you know. Its purpose is to reduce the number of rules and make matches easier to explain, not to provide a universal setup for all everyday traffic. If the minimal setup works, restore the original configuration group by group. If the issue returns after restoring a group, focus on its scope, order, and additional settings.

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

Step 2: Understand What Each Test Tells You

Connectivity Test can help you assess server reachability under the chosen test method, but it does not replace testing actual destinations. A successful test does not mean every protocol, port, and remote service is available; a failed test must be interpreted in light of the test method and real request. Check both destination access and connection logs. One test result cannot prove that the entire rule set is correct.

Step 3: Troubleshoot the Relevant Layer

For a resolution failure, first check the domain spelling, DNS settings, and Host mappings. For a connection timeout, check the actual destination address, policy path, and destination service. For an explicit rejection, check whether it comes from a REJECT rule or the destination itself; those are different layers. An app-level error is not necessarily a network error. The destination's sign-in state, request permissions, and API requirements may also cause a failure. Do not change network settings without evidence.

If only some page resources fail, check the host and policy for each failed request instead of routing all traffic the same way. If the same domain behaves differently on different networks, record the resolution result and address family, then check whether address-location rules apply. If the issue started after an update, compare the old and new configurations and selected server. Find what changed before adding a rule as a workaround.

Step 4: Treat Rollback as a Test

Restore a verified configuration and repeat the same request. If the problem disappears, focus on the configuration changes made since that version; if it remains, check the network, server, and destination. A rollback is a controlled test, not simply a declaration that the configuration is bad. Change one thing at a time and record expected and actual results so that further edits are evidence-based rather than stacked on the basis of a one-off success.

When reporting an issue, include the mode shown in the app, destination type, relevant rule snippet, expected policy, and actual match. Remove complete subscription links, passwords, tokens, and personal addresses. Remove unrelated domains from connection logs as well. Include enough context around the first matching rule: order problems are often caused by an earlier broad rule, not by the matching line itself.

To review first-time import, permissions, and connection steps, return to the setup guide. For quick answers, visit the FAQ. For purchase and authenticity information, use the App Store authenticity check. The reference sequence on this page is always the same: understand the configuration structure, check conditions and rule order, then verify with actual connections. More rules are not a substitute for clear, explainable behavior.