Shadowrocket
Rules and Configuration Guide

Configuration File Structure

Shadowrocket configuration files are usually saved as .conf files. Square brackets mark sections, and each section contains its own settings. A configuration isn’t a text version of every app toggle, nor is it the same as a server subscription. Start by identifying the section, then check which field formats it accepts. The same text can have no effect or cause a parsing error in the wrong section, so a familiar keyword alone doesn’t prove a configuration is valid.

What Each Section Does

[General] contains general behavior and parsing options, usually written as a field name, equals sign, and value. [Rule] contains ordered rules for routing traffic, typically written as a type, match value, and policy. [Host] maps specified hostnames to static addresses. [URL Rewrite] rewrites request URLs that meet its conditions. The section context matters more than the number of blank lines around a heading.

Don’t think of these four sections as a fixed processing pipeline. A request doesn’t necessarily pass through every General setting, then Host, then Rewrite. General changes client behavior, Host affects name resolution, Rule selects a traffic policy, and Rewrite handles eligible request URLs. Each feature has different conditions for taking effect. Moving sections around in the file doesn’t change network processing order; only the order of rules within the Rule list directly affects priority.

[General]
dns-server = system

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

[Host]
# Add an entry only when you need a fixed mapping

[URL Rewrite]
# Add a rewrite only after identifying the target request

Manage Subscriptions and Configurations Separately

A server subscription is mainly for retrieving and updating connection entries. A configuration describes how those connections are used to handle requests. After importing your own subscription, seeing servers in Home doesn’t mean a routing configuration is active. Likewise, importing rules containing PROXY won’t create a server you can connect to. If the rules parse but no connection can be established, check the selected server and the active configuration separately instead of importing the same file again.

Remote configurations need to be managed separately, too. Whether local edits are kept during an update depends on how you update and edit the file. Save a copy before refreshing important changes. Don’t assume a subscription update will fix your rules, or that a failed server subscription means your local rules are damaged. For subscription refresh instructions, see How to Update a Subscription. This page focuses on the configuration itself.

A configuration may contain server credentials, private addresses, request logging settings, or rewrite destinations. Before sharing a file, inspect every section—not just visible server names, but also URL parameters, comments, and static mappings. Troubleshooting usually requires only the relevant rule lines, current mode, and symptoms; there’s no need to send a full subscription URL. example.com is reserved here for documentation examples. Don’t replace it with someone else’s real service details and publish them.

Edit, Save, and Enable

In Config, find the configuration you want to edit and confirm whether it’s the file currently in use. Make a recoverable copy before changing it. After editing, save the file and check that the active configuration still points to the one you edited. Matching filenames don’t guarantee matching contents; a newly downloaded remote copy may coexist with your local edits. Comparing file contents is more reliable than checking names in the list, especially when testing multiple configurations.

When editing plain text, keep English commas, square brackets, and equals signs. Don’t replace them with localized punctuation. Put each rule on its own line and place comments on separate lines beginning with #. Avoid appending explanatory text after a policy. If an editor wraps a line visually without inserting a real line break, it’s usually still one rule. When copying, check that long URLs haven’t been split; all fields must remain intact to be read correctly.

Start verification with a small set of rules. Keep one clear domain condition and FINAL, confirm the result, then add IP, Host, or Rewrite entries as needed. If something goes wrong, restoring a backup is easier than layering on more patches. The examples below illustrate individual concepts; they aren’t meant to be combined all at once. Keep only entries that serve a clear purpose for your current setup.

General and DNS

General is a good place to start when investigating configuration behavior, but don’t copy a whole block of fields you don’t understand. Successfully importing a configuration only means the text could be read; it doesn’t prove every field is right for your environment. Check how each field maps to an in-app setting and its documentation before deciding whether to override the default. For DNS issues, distinguish among a failed name lookup, an unreachable returned address, and an incorrect connection policy.

Start with the Fewest Fields

dns-server = system means using the DNS resolution source provided by the system. It’s a useful baseline for comparison, but results won’t necessarily be identical across networks: the system’s DNS servers can change with Wi-Fi, cellular service, or upstream routing. Record the network you’re using during tests. If the same file behaves differently at different times, the resolution path may have changed rather than the configuration failing to save.

[General]
dns-server = system

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

This example isolates the relationship between domain rules and system DNS; it isn’t a general recommendation. If your existing configuration has other General fields, you don’t need to delete them just to match the example. Back up first, then change one field at a time and see whether the failure changes. For the actual effect of client-wide settings and configuration fields, refer to the current app display and request logs. Don’t infer how every setting overrides another from a single example.

Boolean values, address lists, and numeric parameters in a configuration must follow their respective field requirements. Don’t append explanatory text to a value or assume an identically named field in another app accepts the same values. Bypass-proxy, excluded-route, and DNS settings can sound similar but affect different layers. If traffic never reaches the client, changing Rule order usually won’t help.

Domain Resolution and Rule Matching

DOMAIN and DOMAIN-SUFFIX use known hostnames as match conditions. IP-CIDR and GEOIP require target address information. If the client resolves a domain to evaluate an IP rule, a DNS failure can prevent that condition from matching as expected. When an IP rule uses no-resolve, it means not to perform an extra lookup just for that IP condition. It doesn’t disable DNS for the entire request or force every connection to use a numeric address.

An app may connect directly to an IP or obtain an address through its own mechanism, in which case the client may not have the original domain name. Seeing a domain in the browser’s address bar doesn’t mean every underlying connection includes a usable domain; a page may request resources from several hosts. Inspect request logs one entry at a time. Distinguish the main site from static resources and API requests, check whether each rule sees a domain or an address, and choose a suitable condition.

A successful DNS lookup doesn’t guarantee a successful connection. The returned address may be unreachable on the current route, or the server selected by PROXY may be unable to reach the destination. A temporary change after switching DNS doesn’t prove the root cause is fixed; address caching, connection reuse, and responses with multiple addresses can all affect what you observe. Repeat tests on the same network and compare actual connection addresses, not just whether the page opens the first time.

IPv6, Caching, and Verification

Networks with IPv6 support may return addresses from more than one address family. IPv4 subnet rules won’t automatically cover IPv6 connections, and restricting the address family won’t fix incorrect routing or DNS. First check which address family the failed connection uses, then decide whether to add IP-CIDR6 or investigate upstream support. Don’t attribute every dual-stack issue to domain rules: domain matching and address reachability are separate concerns.

Caching can make a recently edited configuration appear to have no effect. DNS caches store resolution results, and browsers or apps may reuse existing connections. Saving a new rule doesn’t necessarily force an existing connection through the full matching process again. Before testing, end the relevant requests and, if needed, reconnect the client before making a new request. Repeatedly refreshing a page doesn’t guarantee a fresh lookup and connection; timestamps and destination addresses in the logs are more useful.

If several domains fail to resolve, restore a known-good General baseline and check the current network first. If only one domain is affected, check its spelling, any Host override, and its DNS result. If the same destination works with Direct but fails with Proxy, investigate the server route instead of repeatedly changing DNS. For a complete connection troubleshooting sequence, see Connected but No Internet: Troubleshooting Checklist.

Domain Rule Types

Domain conditions are useful for routing traffic by site or service name. DOMAIN, DOMAIN-SUFFIX, and DOMAIN-KEYWORD are not interchangeable: each has a broader match scope and a different risk of unintended matches. Before choosing one, decide whether you need a single hostname, a domain and its subdomains, or every hostname containing a text string. Use the narrowest condition that fits rather than starting with a broad keyword and adding lots of exceptions.

Exact Match with DOMAIN

DOMAIN,example.com,PROXY routes the hostname example.com through PROXY. It doesn’t automatically cover api.example.com just because it belongs to the same site. Exact rules are useful for handling a login endpoint, download host, or other confirmed request target on its own. Their boundaries are easy to explain and verify in the logs, but you may need to add rules if the site starts using new resource hostnames.

Don’t include a scheme, port, or path in a rule’s domain. Putting a full URL in DOMAIN mixes URL components into a hostname condition. The rule doesn’t depend on the path when you visit a page on example.com. Domain rules can’t distinguish two directories on the same host. First check whether the app supports a request-handling feature suited to that need; don’t put a path in DOMAIN expecting a partial match.

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

In this example, api.example.com matches the exact rule first and uses DIRECT. Other hosts under example.com then reach the suffix rule below. This is due to rule order—not because DOMAIN automatically outranks DOMAIN-SUFFIX. If you swap the lines, the earlier suffix rule will match that hostname first. Only requests that don’t match it can be checked against later conditions.

DOMAIN-SUFFIX Boundaries

DOMAIN-SUFFIX,example.com,PROXY matches example.com itself and its subdomains, such as www.example.com and api.example.com. It matches at a domain boundary; it isn’t a simple string-ending comparison. notexample.com isn’t a subdomain of example.com. Before adding a suffix rule, make sure you’re entering the domain you want to cover, not a full URL copied from a browser.

Don’t add an asterisk before a suffix to imitate a wildcard. The rule type already defines the match behavior, so enter example.com directly. Shorter suffixes generally cover more hosts. A public suffix or very broad organizational domain could affect many unrelated requests. Add a comment explaining the scope so you can later decide whether a broad rule is still needed.

A site’s resources may not all use its main domain. Images, payments, authentication, or downloads may use separate hostnames. If some features still fail after adding the main domain suffix, that doesn’t mean DOMAIN-SUFFIX is broken. Find the specific failed host in the request logs, confirm it belongs to the service you want to handle, and add a clearly bounded condition. Don’t guess resource hostnames from the brand shown on the page.

When to Use DOMAIN-KEYWORD

DOMAIN-KEYWORD,example,PROXY matches hostnames containing example, so it covers more than a suffix condition and may include hosts belonging to unrelated organizations. Use it only when the naming pattern is stable and you’re comfortable with its scope. Short, common words and brand abbreviations can cause unexpected matches. Be especially careful when using it with REJECT, since a false match can make an unrelated service unavailable.

When reviewing an existing configuration, list the hosts currently matched by keyword rules. Then decide whether a few exact or suffix rules would express the intent more clearly. The goal isn’t simply to add more lines, but to make vague behavior verifiable. For temporary troubleshooting, start with the full hostname you observed. After confirming the result, decide whether to broaden the scope; don’t mistake an incidental match for a complete solution.

All three types define conditions; none guarantees a successful connection. A match to PROXY still requires a working server, a match to DIRECT still depends on the current network, and REJECT actively denies the request. If the log shows a rule matched, investigate the policy and connection path rather than changing the domain syntax. If there’s no matching entry, check whether the request reached the client and whether an old connection was reused.

IP Rules and Identification Boundaries

Address rules handle specific destination IPs or subnets. Common types include IP-CIDR, IP-CIDR6, and GEOIP. They express network ranges; they don’t identify the organization a domain belongs to or fully identify an app’s behavior. A service may use multiple addresses, and one shared address may host multiple domains. Before writing a rule, decide whether you need to control a hostname, a network range, or a recognizable request type. Don’t mix these different dimensions.

IP-CIDR and IP-CIDR6

CIDR uses a prefix length after the slash to describe an address range. In IPv4, 192.168.0.0/16 covers the corresponding private address subnet, while 192.0.2.10/32 represents a single IPv4 address. The prefix length is neither a port nor an arbitrary range number. Use an address that belongs to the network range you intend to match. Don’t combine a host address with a prefix you don’t understand and accidentally cover a larger network.

[Rule]
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
IP-CIDR6,2001:db8::10/128,PROXY,no-resolve
FINAL,PROXY

Use IP-CIDR6 for IPv6; a single address can be written with /128. The 2001:db8::10 address in this example is reserved for documentation, not a real server. fc00::/7 is an IPv6 local address range, but whether you need a rule for it depends on your network. A DIRECT policy doesn’t guarantee system access to the destination: local routing, device firewalls, the service’s listening address, and the client’s interception scope all affect the result.

If you can’t reach a LAN printer or admin page, first confirm the actual destination address, then check whether the request reached the client. It’s normal for addresses handled directly by the system to be absent from Rule logs. Conversely, adding DIRECT for a private subnet won’t discover every device: broadcast or multicast discovery differs from a regular connection to a specific address. Test them separately.

GEOIP and no-resolve

GEOIP,CN,DIRECT matches CN according to the geographic classification of the destination IP. It uses an address database; it doesn’t check the page language, the user’s location, the domain suffix, or the website operator. The database may be out of date, and service addresses can change, so GEOIP can’t guarantee that a particular site will always use a specific policy. For domains that need a known exception, an exact rule placed earlier is usually easier to verify.

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

An IP rule with no-resolve won’t perform an extra lookup just to evaluate that condition when a domain doesn’t yet have address information. It may still match if the request already targets an IP or address information is available. This parameter doesn’t “skip all IP rules” or raise a rule’s priority. Add it only if you’re comfortable with whether that match requires an extra lookup and the dependencies involved.

When domain rules and GEOIP rules are both present, a matching domain condition earlier in the list usually determines the policy before a later geographic condition is considered. If a domain should always use PROXY, put its explicit exception before broad address classifications. Adding no-resolve mechanically to every rule to reduce lookups may defeat routing that depends on resolution results. Establish a correct, reproducible baseline before optimizing.

USER-AGENT Visibility

USER-AGENT matches recognizable request-header content; it isn’t a rule for app names. It’s generally useful when the client can read the relevant HTTP information. The example USER-AGENT,ExampleClient*,DIRECT uses a pattern to match a class of request headers. ExampleClient is a teaching value and matters only if the actual logs show matching content. Entering an app’s home-screen name won’t make the client route traffic by app automatically.

On a regular HTTPS connection, request headers are encrypted. Network connection information alone doesn’t mean the User-Agent is readable. Don’t enable extra content processing or install a certificate just to make a rule match. For routine routing, start with observable domain and address conditions. Consider finer-grained request matching only when you understand what is visible, the conditions for processing it, and the privacy implications. Test first with a controlled target.

If a USER-AGENT rule never matches, check in order whether the request header is visible, the pattern matches the actual text, an earlier rule has already matched, and the request is reusing an old connection. Don’t assume a miss means the protocol isn’t supported, or try to hide the problem with a broad keyword. A rule can match only information the client actually has at the time, regardless of how many conditions are in the configuration.

Policies and Operating Modes

The last main field in a rule is usually its policy. PROXY, DIRECT, and REJECT describe different outcomes and don’t mean the same thing: PROXY requires a working proxy route, DIRECT connects over the current network, and REJECT actively denies the request. Before interpreting these values, check the current Global Routing selection. Even a correct Rule may not handle requests according to the configuration mode; changing the file without checking the mode only makes troubleshooting harder.

PROXY, DIRECT, and REJECT

PROXY sends matched traffic through the proxy route. A common basic setup uses the server currently selected in Home, so verify that the server itself connects first. PROXY in a rule doesn’t include a server address, password, or protocol parameters. Adding it to every line won’t fix an incorrect port, authentication, or server status. When a connection fails, record “rule matched” and “proxy connection succeeded” as separate facts.

DIRECT connects to the destination without using that proxy route, but traffic is still subject to system networking. DNS, the default route, other VPN configurations, and upstream restrictions can all affect the connection. For LAN resources, confirm the device is on a network that can reach the subnet. After switching to cellular, a private address that was previously reachable usually won’t become accessible just by adding a rule.

REJECT denies matched requests. Use it only for clearly scoped targets you’ve confirmed can be blocked. It isn’t a troubleshooting policy, and a domain name alone doesn’t prove content is harmful. A broad rule may leave the main page visible while breaking login, verification, or downloads. After adding a block, test the full workflow rather than checking only whether the home page loads. Keeping a way to revert the change is better than repeatedly adding exceptions.

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

The Three Global Routing Modes

In Global Routing, Config uses the current configuration to route traffic; Proxy sends requests within its scope through the proxy route; and Direct uses a direct connection. These are operating modes, not three Rule entries, and they don’t map one-to-one to PROXY, DIRECT, and REJECT. In particular, Direct mode doesn’t automatically insert a rule at the top of the current file.

The modes in the table don’t bypass system permissions, take over excluded traffic, or override other network boundaries. If a request doesn’t reach the client, switching modes may not change its route. If the interface also offers Scene or other options, check the settings for that option to confirm what’s active. Don’t infer the current rules from its name alone. For troubleshooting, start with a clearly identified Config, Proxy, or Direct mode and compare the logs.

If a request fails in Config but succeeds in Proxy, that suggests checking routing or configuration; it doesn’t prove a domain rule is wrong. DNS, Host, reject rules, and the fallback policy can all cause a difference. If it also fails in Proxy, check the selected server and destination route first. Establish a new connection after each mode switch and test the same destination so the comparison is meaningful.

Custom Policy Names and Actual Targets

Some configurations use policy groups or specific server names as rule targets. These names must refer to an object defined in the current configuration; they aren’t arbitrary labels. Keeping a group name from someone else’s file without its definition may cause an import warning or unexpected behavior. For basic troubleshooting, use a copy and replace the target with a built-in policy you understand. Then restore custom policies gradually, based on what the app supports, rather than migrating a complex setup all at once.

When checking a configuration, don’t search only for PROXY. A rule may point to a similarly named policy group, whose final selection may differ from the item currently selected in Home. Check the rule target, group selection, and final server together. Seeing the word “proxy” doesn’t prove the route is the same. When sharing an issue, replace private server identifiers with neutral names, but preserve the relationships between objects so troubleshooting details aren’t lost.

When mode testing is complete, switch back to the mode you intend to use and confirm the correct configuration is still selected. Getting a page to load temporarily in Proxy doesn’t mean the Config issue is fixed. Forgetting to switch back can also make direct-connection exceptions ineffective. For the steps to select a server and turn on the connection for the first time, return to Getting Started. This page covers only the boundaries between modes and rules.

Matching Order and Fallbacks

The key to reading Rule is to check from top to bottom. The first valid match determines the policy; the client doesn’t score every condition and choose the most specific one. A rule type, condition length, or policy name doesn’t automatically give it higher priority. To find out why a request took a particular route, identify the first rule that matches it, then check which later entries no longer had a chance to decide. Don’t search only for the last mention of the destination domain.

Put Exceptions Before Broad Conditions

If example.com and its subdomains should use PROXY by default, but api.example.com should use DIRECT, put the exact exception before the suffix condition. This is an easy-to-maintain arrangement, not a syntax requirement. Conversely, if all subdomains should use the same policy, there’s no need to keep an exact entry that an earlier rule already overrides. Removing rules that no longer have any effect helps prevent maintainers from assuming they still control requests.

[Rule]
# Match the exact exception first
DOMAIN,api.example.com,DIRECT

# Then handle other requests for the same domain
DOMAIN-SUFFIX,example.com,PROXY

# Handle all remaining requests last
FINAL,DIRECT

Take special care with the position of keyword rules. If DOMAIN-KEYWORD,example,REJECT appears above the example rules, api.example.com will be rejected before the later DIRECT rule gets a chance to “correct” it. When results are unexpected, check all broad conditions above the target, not just the nearby lines. The more rules you have, the more important it is to comment on each group’s scope and exceptions; a rule type isn’t a substitute for documentation.

Address rules follow the same logic. Once an explicit domain condition matches, a later GEOIP rule won’t determine that request’s policy. If an earlier IP check needs address information, resolution also affects whether it can match. When ordering rules, consider both logical coverage and whether the required information is available. Decide what behavior you want, then assess lookup overhead. Don’t move an important exception to an ineffective position just to avoid one lookup.

FINAL Covers All Remaining Requests

FINAL,PROXY sends requests that didn’t match earlier rules through PROXY. FINAL doesn’t take a domain or address condition; the text after it is the policy. Put it at the end of the relevant Rule list. If it appears earlier, later entries are irrelevant for requests already handled by the fallback. If the file contains multiple FINAL rules, don’t treat them as a sequence of fallbacks; consolidate them into one clearly intended final rule.

Whether FINAL uses DIRECT or PROXY depends on the configuration’s purpose; neither choice is inherently correct. Many direct-connection exceptions followed by FINAL,PROXY express a different default scope than a few proxy-routed domains followed by FINAL,DIRECT. When comparing configurations, consider both the exceptions above and the final policy. Looking at FINAL alone ignores the conditions that determine how most requests are handled and can misrepresent the author’s intent.

A fallback doesn’t automatically fail over when a connection fails. If a request matches PROXY and the connection fails, the client doesn’t necessarily try a later DIRECT rule or another FINAL. Later rules aren’t a backup server list. For server selection and recovery, check the relevant selection mechanism instead of adding another policy for the same domain. Separating routing decisions from what happens after a connection failure is key to understanding rules.

Conflicts, Duplicates, and Merging Rules

Duplicate entries with the same condition and policy usually add only reading overhead. If the condition is the same but the policies differ, check which rule comes first and why both are present. Don’t sort the entire Rule list alphabetically; doing so can change how exceptions and broad conditions interact. Before reorganizing, group rules by purpose—explicit blocks, single-domain exceptions, domain sets, address ranges, and fallback—then remove only genuinely equivalent duplicates within each group.

When merging two configurations, don’t simply append the second Rule section and its FINAL to the first. First identify the intent of each configuration and check for overlapping domains, different policy names, and duplicate fallbacks. Then build one list whose behavior is easy to explain. Recheck new conditions whenever remote rules change, since they may broaden the match scope. “Worked before” doesn’t mean the updated rules still interact the same way.

To verify rule order, use a copy with just one conflicting group of conditions. Create a new request to the same destination each time and check the matched type and policy in the logs. If removing a broad rule above changes the result, the conflict likely comes from the match order. If nothing changes, check that you edited the correct file and are using Config mode. Reducing the rule set to gather evidence is more reliable than repeatedly moving rules to the top.

Host and URL Rewrite

Host and URL Rewrite can both affect access, but they operate at different levels. Host assigns an address to a hostname; URL Rewrite modifies eligible request URLs. Neither replaces selecting a proxy server, and neither is a place to enter subscription details. Troubleshoot them separately from Rule: a request may correctly match DIRECT but fail because Host points to an outdated address, or a rewrite may change the request target so a different domain appears in the logs.

Static Host Mappings

A common static mapping in the Host section looks like example.com = 192.0.2.10. The left side is a hostname and the right side is an address; don’t include a scheme or page path. 192.0.2.10 is reserved for documentation examples, not a real website address. In an actual configuration, enter an address you manage or have verified, and map only hosts that need a fixed address. Don’t guess that every resource host for a site uses the same address.

[Host]
# Documentation example address; format demonstration only
example.com = 192.0.2.10
api.example.com = 192.0.2.20

A static mapping changes the resolution result; it doesn’t automatically change the site identity used for TLS. For HTTPS, the destination server still needs to handle the hostname and provide a valid certificate for it. Pointing a domain to a responsive address doesn’t guarantee the site will work. If the address belongs to another service, you may see a certificate error, default page, or connection refusal. Don’t hide an incorrect mapping by ignoring certificate checks; restore the correct destination.

Host doesn’t replace port configuration either. Different ports on a server may run different services, while a static hostname mapping only relates a name to an address. If the app is connecting to the wrong port, correct it in the relevant connection settings or destination URL. Record the original hostname, resolved address, and actual port, then check each one. A successful domain lookup alone doesn’t show whether the final connection reaches the right service.

URL Rewrite Conditions and Results

URL Rewrite rules typically use a regular expression to match a URL, then specify a replacement destination and action. The example below redirects an HTTP URL for a documentation domain to HTTPS while preserving the captured path. It demonstrates the format only. Before copying it, make sure you understand the match scope and replacement result. Adding a rule doesn’t mean it will handle every connection, especially when the relevant request content isn’t visible.

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

In a regular expression, ^ anchors the match at the start, \. matches a literal period, and (.*) captures the remaining text. The replacement’s $1 refers to the first capture group. An unescaped period broadens the match, and an expression without a hostname boundary may match unintended targets. Don’t remove boundaries just to make a rule “work more easily.” Work through specific requests and determine the exact replacement each one would produce.

A redirect may cause the client to request the new address, so check for loops. For example, one rule that changes URL A to URL B and another that changes URL B back to URL A will create repeated requests rather than restore access. When query parameters are involved, check that the capture preserves required values so authentication or pagination doesn’t lose them. Test with a simple, controlled HTTP destination before applying a rule to a login or payment flow.

Scope and How to Revert

On regular HTTPS connections, paths and request headers are encrypted. Knowing the destination domain doesn’t mean the client can read the full URL. This guide doesn’t require adding certificates or content-decryption settings to use rewriting. If you only need to decide whether a host uses PROXY or DIRECT, Rule is more direct. Consider Rewrite only when you need to change a request URL the client can process; don’t stack it onto domain rules as a supposedly stronger routing method.

When troubleshooting, disable Host mappings and Rewrite entries separately. Don’t delete both sections at once and assume you’ve identified the cause. First restore the original resolution and check the destination address. Then test the request without rewriting. Finally, restore rewrite rules one at a time and note when the behavior first changes. This helps distinguish an outdated address, an overly broad expression, a loop, or server behavior, and avoids mistaking a normal redirect for a proxy connection failure.

Review long-standing mappings and rewrites periodically. A fixed IP may stop working after a service moves, and an old regular expression may stop matching or start affecting new URLs after a site changes its paths. Comments should explain the purpose and how to verify it, but shouldn’t include real credentials. If you can’t explain an entry’s purpose, disable it in a copy and observe the result instead of keeping it forever just because it came from an old configuration. Aim for behavior that’s understandable and reversible.

Verification and Configuration Maintenance

The goal of configuration testing isn’t to keep adding rules. It’s to make the cause of every change observable. Before you start, record the current network, Global Routing mode, selected server, and configuration file. Then choose one stable, well-defined test target. If several of these conditions change at once, it’s hard to tell which change caused the result. Keep a known-good baseline copy, test new rules in a separate copy, and move them into your everyday setup only after verification.

Build a Minimal, Understandable Configuration

A minimal configuration needs only the conditions you’re testing and one clear FINAL; it doesn’t need every section. When testing a domain exception, leave out Host and Rewrite. When testing resolution, avoid mixing in lots of address rules. This isn’t a recommendation to use minimal rules forever; it reduces the number of possible causes behind the same symptom. If you can explain the purpose of each line in one sentence, it’s easier to decide whether to keep, move, or remove it.

[General]
dns-server = system

[Rule]
# Verify that the specified host uses the proxy route
DOMAIN,example.com,PROXY
FINAL,DIRECT

An example configuration shows behavior only under its stated conditions; it won’t suit every use case. Before testing, make sure you have a working server and are in Config mode. If you don’t need to access the documentation domain, replace it with a target you’re troubleshooting and are authorized to access. Enter only the hostname. After a successful test, restore other rules gradually, adding one group at a time and repeating the test. That makes it easier to identify which change first caused a problem.

For LAN issues, testing a service port at a known address is more useful than checking only the device discovery list. For web issues, check the main page, login flow, and static resources separately. A page loading successfully doesn’t prove the whole site uses the same policy. In the logs, focus on the request that actually failed and note its hostname, address, and time. Don’t treat every simultaneous background connection as part of the problem.

Identify the Failure Stage from the Evidence

First, check whether the request reached the client. If there’s no log entry, check the connection toggle, system permissions, interception scope, and whether an old connection is being reused—not the rules. For first-time authorization issues, see About the VPN Configuration Prompt. Once you can see the request, move to the second stage: check whether its domain or address information is complete and whether the rule it matched is in the expected position in the current file.

At the third stage, check the route selected by the policy. If a PROXY match fails, check the selected server, protocol parameters, and destination reachability. If DIRECT fails, check the current network and destination service. If REJECT matches, first confirm whether the block was intentional. Connectivity Test can help check server connectivity, but its test target may differ from the service you’re accessing. Its result doesn’t prove that every website is reachable. Record the tool result separately from the actual request.

At the fourth stage, rule out caching and state differences. After a change, save the file and confirm it’s still selected. End old requests, reconnect if needed, and revisit the same destination. Keep the network unchanged during comparisons; don’t switch from Wi-Fi to cellular and change servers at the same time. If only one network has the issue, investigate its DNS and routing differences first. If every network is affected, check the shared configuration or the destination service.

Backups, Updates, and Troubleshooting Notes

Maintenance notes should state what you changed, which rules were involved, and how you verified the result—not just say “network fixed.” For example, “Moved the DOMAIN exception for the specified host above the suffix condition; after reconnecting, the request matched DIRECT” is easier to reproduce than “Moving the rule worked.” Before sharing notes, remove private subscription parameters and authentication details. Keep only the structure and redacted targets needed to explain the issue.

Before updating a remote configuration, save local changes. After the update, compare General, Rule, Host, and Rewrite for substantive differences, not just file length. For server subscription updates, separately check whether entries are still present and whether the current selection changed. These are two different update processes. If you maintain your own configuration, define how automatic updates and manual exceptions will be managed so the next refresh doesn’t overwrite a recent fix.

To recover, switch back to a known-good configuration copy and confirm the mode and server. Don’t assume that undoing the last line restores the entire setup. After recovery, test the same destination again before deciding whether to continue. If the issue remains unclear, use the categories in Troubleshooting and include the minimum steps needed to reproduce it. For installation and download access issues, see the installation guidance on the Download page. Rule edits on this page don’t replace system installation or permission steps.