Shadowrocket
Rules & Config Guide

Global Routing and When Rules Apply

Rules matter only when a request enters the processing path they apply to. Before editing, confirm that Shadowrocket has a usable server selected, the connection switch is in the expected state, and Config has the file you intend to edit enabled. A file appearing in the list does not mean it is active; new text in an editor does not mean the current connection has been re-established with those changes. Check separately whether the file exists, is selected, and is being used for requests. This helps distinguish an activation issue from a syntax error.

Config, Proxy, and Direct: What’s the Difference?

In Global Routing, Config, Proxy, and Direct select the config-based, proxy, and direct connection paths. Config applies the policies defined by the active config and is the basis for most examples on this page. Proxy sends requests that would normally use the proxy path through that path, while Direct uses a direct connection. These modes are useful for comparing paths, but they should not be mistaken for testing custom Rule entries one by one. System bypass settings, local network exceptions, and existing connections can also affect what you observe, so start a new request after switching modes.

Servers, subscriptions, and rules are separate

Server details specify where to connect and which protocol and authentication parameters to use. A subscription is one way to maintain server details in bulk. Rules determine which policy a request follows. Updating a server subscription does not update Rule entries, and importing a config file does not mean that any servers it refers to are already available. This guide assumes you already have your own subscription or server details. A one-time purchase of the app is not a service plan: buying the app and having the connection details you need are separate matters. This site does not provide, sell, or recommend nodes or subscriptions.

Shadowrocket is a paid, closed-source app for Apple platforms, primarily used on iPhone and iPad, and is available exclusively through the App Store. For details on how to get it, see how to buy and install the genuine App Store version. Check the App Store listing for system requirements and purchase availability. The examples in this guide explain how the app handles config; they do not replace the store listing or guarantee that your existing servers will work. Establish a basic connection before adjusting routing to keep troubleshooting focused.

Set Up a Repeatable Test

For your first test, choose one specific domain and record the current Global Routing mode, selected server, config name, and network type. First try the destination with your existing working config to confirm that it responds, then change one rule. Do not update a subscription, switch networks, change DNS, and reorder rules all at once. When several variables change together, even a different match result will not tell you which setting caused it. Keep notes locally, and remove server addresses, authentication details, and full subscription links before sharing them.

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

The example above is a partial rule snippet: it sends requests for the exact domain example.com through PROXY and sends unmatched requests through DIRECT. It is not a universal routing setup and does not configure a proxy server for you. If the destination page also requests other domains, those requests may fall through to FINAL, so some content may load while other parts fail. This is not random rule behavior; a page can make several separate connections. To verify what is happening, check each actual request destination rather than drawing conclusions from the main domain in the address bar.

.conf Config File Structure and Editing

Config files organize content into sections marked by square-bracketed headings. General holds global settings; Rule contains match rules checked in order; Host maps domain names to addresses locally; and URL Rewrite handles matching URL rewrites or rejections. Section headings are not decorative labels: the parser uses them to determine how to interpret the following lines. The same text in the wrong section will not automatically behave as intended. Identify the current section before editing. In particular, do not put a hostname mapping in Rule or plain explanatory text in a settings section.

Read the Structure Before the Examples

[General]
bypass-system = true

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

[Host]
test.example.com = 192.0.2.10

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

Here, example.com, example.net, and test.example.com illustrate syntax; 192.0.2.10 is a documentation-only example address and should not be expected to work. The URL Rewrite example redirects a specified HTTP address to HTTPS; whether that is appropriate depends on the destination site. The full snippet demonstrates how sections can be arranged, not a recommended replacement for your entire config. Copy only the lines you need, understand which requests each line will affect, and keep other settings in your current file that you have already confirmed work.

Identify the Active File in Config

In Config, first check which file is selected, then open that file to inspect it. Depending on the screen, you may see options to view, edit, or perform other actions; use the controls shown in the app. Similar filenames do not prove that two files contain the same config. Files saved from a remote source, local copies, and older imports may all coexist. Give your working copy a recognizable name, note its purpose, and after editing return to the list to confirm the selected file has not changed before testing requests.

Replacing a whole config and adding a few lines carry different risks. A full replacement can change DNS, bypass settings, rules, and rewrite behavior at once; use it only when you understand the entire file. Adding a few lines is easier to troubleshoot when you need specific changes. Even when adding rules, find the existing section rather than repeatedly appending duplicate section headings. Do not rely on duplicate-section merging or overrides as a maintenance strategy. Keeping each section focused and its contents in a clear order reduces ambiguity between the editor and runtime behavior.

Check Characters and Section Boundaries When Saving

Use standard ASCII commas in Rule entries, equals signs for assignments, and matching square brackets. Input methods can replace commas, spaces, or quotes with lookalike characters; copying from rich text can also introduce invisible characters. If a line looks right but behaves unexpectedly, retype its section name, separators, and keywords in a plain-text editor, then save and test again. Domain rules should contain only the hostname, not a path, query string, or full URL as shown in a browser.

Arrange longer configs by purpose and keep comments brief. Use a separate line starting with a hash mark to explain a group of rules—for example, why an exact exception must come before a suffix rule. Avoid relying on complex end-of-line comments to explain important parameters, as they can get mixed into copied content. Comments should record the reason for a decision, not simply restate a keyword. Later, “test direct access to this destination” is more useful than “DIRECT rule” when deciding whether a line is still needed.

After editing, check that the file saves and remains selected, then start a new connection test. A successful save only confirms that the file was written; it does not prove that every rule will match. A syntactically valid rule may be hidden by an earlier match. Keep a copy of the previous version, add one rule at a time, and continue after each change is verified. For more on editing sections, read how General, Rule, Host, and URL Rewrite sections work, then compare it with the priority section on this page.

General, DNS, and System Bypass: What They Affect

Settings in General affect the overall processing environment; unlike Rule entries, they do not assign a policy to each domain individually. So if a request does not appear in the expected rule records, do not just keep adding broader matches to Rule. First check whether the request enters client processing, whether system bypass settings apply, whether the destination details are visible, and whether the domain resolves to an IP address. Once these prerequisites are clear, decide whether another rule is needed. This is usually easier to troubleshoot than replacing the entire config.

What bypass-system Does—and Doesn’t Do

[General]
bypass-system = true

bypass-system controls whether some system-related traffic is bypassed. It does not mean “connect directly to all local addresses,” and it is not a universal switch for making a website accessible. System-related requests may be handled before they can be observed by ordinary rules, so do not expect every request to appear as a Rule match when this setting is enabled. If your current config uses it, understand why it is there before changing it. Do not disable it just to make the records look complete or assume it controls the behavior of every app.

When troubleshooting bypass settings, first identify whether the destination is a public service, a local network device, or a system component. Public domains can often be checked with an exact DOMAIN rule, while access to local network devices can depend on address ranges, network conditions, and system behavior. Note the destination and whether you are on Wi-Fi or cellular, then make one limited change. If only one local device is affected, investigate that destination rather than using a system-wide bypass change to mask an address, port, or network isolation issue.

DNS Resolution and Connection Policy Are Different

Domain rules match destination names; IP rules match destination addresses, with DNS resolution often connecting the two. A successful DNS response does not mean the address is reachable. Selecting PROXY also does not guarantee that DNS resolution follows the exact same path as the proxy connection. Check DNS settings, any existing cache, and the destination actually shown in request records separately. Seeing a different resolved address and concluding that the domain rule failed confuses the DNS layer with the routing layer.

A domain can resolve to multiple IPv4 or IPv6 addresses, and the results may change with the network or over time. If a rule covers only one IPv4 address, a later connection using IPv6 may follow a different policy. First consider whether a domain rule better expresses what you need rather than adding every address you happen to see. Use IP-CIDR or IP-CIDR6 only when you need to control a stable subnet or a specific address. Match the rule type to the thing you actually need to control to avoid relying on an incidental DNS result.

no-resolve Is a Rule Option, Not a DNS Switch

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

no-resolve is generally used with IP rules to avoid triggering an extra DNS lookup solely to evaluate that rule. It does not disable DNS across the client or guarantee that a later connection will not need resolution. If a destination IP is already available for matching, the rule may still match. If only a domain is available and no applicable address is known, the rule may not be able to decide, and the request can continue to later rules. Treating this as “disable all resolution” or “automatically match every domain by IP” leads to the wrong expectations.

If a destination behaves differently only after you remove no-resolve, check whether the change came from the additional DNS lookup rather than assuming the option is good or bad. Record the addresses before and after resolution, the matched rule, and the final policy before deciding which behavior to keep. This matters especially when domain rules and GEOIP rules are both present: an earlier domain rule may already have ended matching, so the later resolution option was never involved. Before testing an option, confirm that execution actually reaches that rule.

For DNS issues, start with a known reachable destination as a control. Check whether the problem affects just one domain, occurs only on a particular network, or coincides with a change in IPv6 routing. Change one specific setting at a time and record the result. Do not replace your current General section with a full block copied from the web; DNS, bypass, and other global options can interact. To restore basic connectivity, see the FAQ connection troubleshooting guide and check resolution and connection as separate layers.

DOMAIN, Suffix, Keyword, and USER-AGENT Rules

Choose a domain rule based on the scope you need to control; do not default to the broadest match. DOMAIN is for an exact hostname, DOMAIN-SUFFIX covers a domain and its subdomains, and DOMAIN-KEYWORD searches for a specified string in the domain. None of these matches a full URL: paths, query parameters, page titles, and text shown in the browser are outside their scope. Identify the target hostname first, then choose the narrowest matching rule to reduce unintended matches and hard-to-explain changes.

Exact Match vs. Suffix Match

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

DOMAIN,api.example.com,DIRECT matches only that exact hostname. It does not automatically include www.example.com or other subdomains of api.example.com. DOMAIN-SUFFIX,example.com,PROXY covers example.com and its subdomains. In the example, api.example.com uses DIRECT because it matches the exact rule first; other hosts under example.com are handled by the suffix rule. If the suffix rule comes first, the exact exception never gets a chance to run. That is why rule order matters.

Suffix matching respects domain boundaries; it is not a search for an arbitrary string. To cover example.com, use the domain as the suffix without adding the protocol from a browser URL or a trailing slash. DOMAIN-SUFFIX,example.com does not match every name that happens to contain the characters “example.com.” If you really need a substring match, use DOMAIN-KEYWORD deliberately and check that the resulting scope is not too broad.

Check for unintended matches before using keyword rules

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

DOMAIN-KEYWORD,example,PROXY checks whether a domain contains the string example, so it has broader coverage than a suffix rule for example.com. It may also match domains with different suffixes or owners, so it is not a good substitute for a list of known exact domains just to save a few lines. If you need a site’s full functionality, start with actual request records, identify the necessary hosts, and confirm what each one does before deciding whether to consolidate them with a suffix rule. Overly broad rules often cause no syntax error; they silently change policies for unrelated requests.

USER-AGENT Visibility Limits

[Rule]
USER-AGENT,ExampleClient*,PROXY
FINAL,DIRECT

USER-AGENT matches the User-Agent value available to the client; ExampleClient in the example is only an illustrative value for a wildcard pattern. This rule does not select traffic by app name or automatically identify every app on the device. HTTP headers in encrypted requests are generally not available from ordinary connection information alone, so whether this rule can apply depends on the request type and what information is visible. A webpage request matching once does not mean every connection from that app will behave the same way. Do not expand decryption just to force a match.

When testing domain rules, check the destination after redirects and the domains the page depends on. A page may first contact its main host, redirect to a login host, then request images, APIs, and static assets; each connection is evaluated separately. If only login fails, check the actual hosts involved in the login flow rather than repeatedly changing the homepage rule. If request records show only an IP, first check whether domain information is available instead of assuming a DOMAIN rule failed.

Start with a small, verifiable set of exact rules, then consolidate them into suffix rules based on what you observe. After adding a rule, test the destination and an unrelated control to confirm it solves the expected request without widening its impact. Before removing an old rule, note where it matched so you do not accidentally remove an exception that depends on it. For domains that change frequently, base maintenance on current requests rather than guessing from similar names; similar-looking domains do not necessarily need the same policy.

IP-CIDR, IP-CIDR6, and GEOIP

IP rules match destination addresses. They do not identify who operates a website or guarantee what kind of service an address represents. IP-CIDR handles IPv4 ranges, IP-CIDR6 handles IPv6 ranges, and GEOIP classifies addresses using a location database. Use them for well-defined address ranges or as additional conditions after domain rules. If you need to route a particular domain, a domain rule is usually more direct. Treating one or two currently resolved IPs as a site’s permanent addresses will quickly leave gaps.

Understand CIDR Prefix Lengths

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

For IPv4, /32 represents a single address, while /16 covers a range determined by the first 16 bits. For IPv6, /128 represents a single address. A shorter prefix usually covers more addresses. The example addresses 192.0.2.10 and 2001:db8::10 are reserved for documentation and are not usable destinations. When entering a range, check what the address and prefix mean together instead of judging by whether the first part looks familiar. A mistakenly broad subnet can affect many unrelated connections without triggering a warning.

Before writing a rule for a local network, confirm the subnet actually in use. 192.168.0.0/16 is only one common private address range, not a definition of every local network; IPv6 local-use ranges serve different purposes too. If a device is unreachable, check whether Wi-Fi allows device-to-device communication, whether the service port is open, and which interface the service listens on, in addition to the client policy. DIRECT selects a direct connection path; it does not grant local network access or make a nonexistent service respond.

GEOIP Classifies Addresses, Not Domains

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

GEOIP,CN,DIRECT sends destination addresses classified as CN by the database through DIRECT. It does not match domain suffixes or page language. A domain may use servers in multiple regions, and the database may not be fully up to date, so an organization’s location does not tell you which GEOIP condition every connection will match. For a service that needs a consistent policy, put an explicit domain rule before GEOIP rather than relying on an indirect address classification.

How GEOIP interacts with resolution depends on the information available for the current request. If the destination is only a domain, address matching may require a usable resolution result; if an app connects directly to an IP, a match target may already be available. Adding no-resolve to an IP rule can change its behavior because that rule will no longer trigger an extra lookup for its own evaluation. Record the destination name, destination address, and matched rule; the final policy alone cannot tell you whether the GEOIP database is correct. If an earlier domain rule matched, GEOIP was never evaluated.

Test IPv4 and IPv6 Separately

A service may publish both IPv4 and IPv6 addresses, and the app or system may choose either depending on network conditions. IP-CIDR does not automatically cover the corresponding IPv6 destination, and one successful test does not prove the other address family will behave the same way. When troubleshooting a policy change after switching networks, check which address family the connection actually uses, then see whether a corresponding IP-CIDR6 entry exists. Do not treat disabling an address family as a universal fix; first determine whether the problem is rule coverage or the network path.

Also consider shared addresses and changing DNS results. Several domains may use the same IP, so a rule for that address can affect all of them; a domain may also change addresses frequently, leaving an old rule unmatched. For a single site, a domain condition usually describes the intended scope more clearly. Use address rules as the primary method only when you accept the impact on shared addresses or the destination is accessed by IP. Document the source and purpose of each range so entries do not remain indefinitely without a clear reason.

A useful check order is: confirm the actual destination address, calculate the rule’s coverage, check no-resolve and earlier rules, then observe the connection result. If the correct rule matches but access still fails, continue with reachability, port, and selected path checks instead of widening the subnet. IP rules classify traffic; they do not provide connectivity. To return to a stable state, undo the most recently added address rule and compare the result with the original domain rule. This is easier to diagnose than clearing the entire config at once.

PROXY, DIRECT, REJECT, and Match Priority

Rule entries are generally checked from top to bottom. Once a rule matches and yields a policy, later ordinary rules are not checked. A rule keyword’s apparent specificity does not give it automatic priority: a DOMAIN entry lower in the list will not jump ahead of an earlier match just because it is more exact than DOMAIN-SUFFIX. Put explicit exceptions first, broader ranges next, and FINAL last. Priority is determined first by the order in the file, not by domain length, keyword, or when a rule was added.

What the Three Policies Do

PROXY sends a matching request through the proxy path, which usually requires a usable selected server or a corresponding policy explicitly referenced in the config. DIRECT uses a direct connection and still depends on the local network and destination being reachable. REJECT blocks a matching request; it does not send it through a backup route or replace the page with other content. These are handling outcomes, not service-quality ratings. Changing a failed request to PROXY or DIRECT changes its path but cannot fix authentication, the destination service, or protocol parameters by itself.

See How Order Works with an Exception

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

The example first handles the login host and metrics host, then the rest of the example.com range, then checks GEOIP, with FINAL as the fallback. If DOMAIN-SUFFIX moves to the top, both exact hosts match it first, so DIRECT and REJECT never take effect. When reading a long config, trace a target request through every condition above it that could match; do not search only for the line you just added. Seeing a rule in the file proves only that the line exists, not that execution reaches it.

FINAL’s Position Defines the Fallback Scope

FINAL has no domain or address condition; its syntax is FINAL,policy. It handles requests that did not match earlier rules, so it usually belongs at the end of Rule. If FINAL appears midway through the section, later ordinary rules may never run; adding multiple FINAL entries will not make later fallbacks work as imagined. Choose FINAL,PROXY or FINAL,DIRECT based on your needs and available paths; neither is universally correct. The example illustrates structure and does not replace judgment about your actual use case.

Use REJECT carefully and keep its scope narrow. A domain that looks like it is only used for analytics may also handle configuration, login state, or other required requests. Rejecting it based on its name alone can cause partial page loads or intermittent app failures. Before adding a rejection rule, confirm what it matches and what it affects, and have a way to undo it. Check both that the target request is rejected and that normal features still work. If something breaks, remove the latest REJECT entry and test again rather than covering the original mistake with more exceptions.

Distinguish a Policy Name from Its Actual Route

This guide uses the basic policy keywords PROXY, DIRECT, and REJECT for clarity. If your config also uses custom policy names, confirm that each one is defined and check which server or selection method it ultimately points to. A name that sounds like a region or purpose does not prove where traffic actually goes. A deleted server, changes after a subscription update, or a different current selection can all make the same rule produce a different result. Check the policy reference first, then the server; do not infer the route from its display name.

When rearranging rules, organize them as “exact exceptions, suffix ranges, address rules, final fallback.” Test at least three targets: one that should match an exception, one that should match the broader range, and one that should reach FINAL. This can reveal both a masked exception and an early fallback. To compare two configs, you do not need to compare line counts; compare the first effective rule each file applies to the same target. More rules do not mean greater accuracy. Keep every entry tied to a clear purpose so the config is easier to maintain and roll back.

Host and URL Rewrite: What Each One Does

Host changes the address mapping used for domain resolution, Rule selects the request policy, and URL Rewrite processes matching URLs. These operate at different layers and are not interchangeable. Mapping a domain to an address does not make it use DIRECT; redirecting an HTTP URL to HTTPS does not make the destination use PROXY. Troubleshoot one layer at a time—destination name, resolved address, rule policy, and request handling—to avoid changing the wrong part of the config when another layer is responsible.

Host Maps Names to Addresses—Nothing More

[Host]
test.example.com = 192.0.2.10

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

The example maps test.example.com to a documentation address and separately uses a DOMAIN rule to select DIRECT. Each line has a distinct purpose; removing one while expecting identical behavior will not work. In practice, use an address for a real destination that you know about or manage, and confirm that its service accepts the domain. Host does not make any arbitrary domain work at any arbitrary address. Whether the server listens, how the site identifies the hostname, and whether its certificate matches are determined by the destination service.

Pay special attention to certificate and hostname matching with HTTPS. Even when resolution returns the expected address, the client still validates the request using its domain name; a mapping does not make a certificate match automatically. If a certificate error occurs, do not hide it by disabling verification. Check the destination address, whether the service supports that domain, and whether a network sign-in page is interfering. Content loading when you access an IP directly does not prove that an HTTPS request using the original domain will work.

For URL Rewrite, Start with What Can Be Observed

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

The example uses a regular expression to match URLs beginning with http://example.com/ and redirects them to HTTPS with a 302 response. The caret anchors the match at the beginning; the dot in the domain is escaped with a backslash so the regex does not treat it as any character. The destination site must support HTTPS, or the redirect will simply send the request to another unusable address. This example demonstrates syntax; it does not mean every site should be rewritten or imply that the contents of encrypted traffic are generally visible.

URL Rewrite input depends on the request information available to the client. A regular encrypted connection does not automatically expose the full path and headers to every rule. Do not apply an example that matches plain HTTP directly to any HTTPS request and then conclude that the config is broken. More advanced request handling requires understanding its additional conditions and security impact; this manual does not require it for basic routing. If you only want to change the connection path for a domain, a domain condition in Rule is usually the better fit.

Regex Scope and Redirect Loops

Regular expressions are more flexible than domain suffix matching and easier to make too broad. Missing start anchors, unescaped dots, or wildcards that cross domain boundaries can affect unrelated URLs. Start by restricting the protocol and hostname, then consider the path. For every expansion, compare one request that should match with one that should not. If you are unsure what an expression does, stick to an exact example rather than adding an unfamiliar long expression to your config. Do not rely only on the explanation that came with copied text to determine its actual scope.

A site may redirect again after your rule does. If a local rule redirects one URL to another and the site sends it back, the result is a loop that can cause repeated redirects or a browser error about too many redirects. Temporarily remove the rewrite and observe the site’s original behavior, then decide whether to narrow the rule or remove it. Do not add more redirects to cover up an existing loop. Trace each source and destination to identify which hop causes the problem.

Test Host and URL Rewrite separately. First restore normal resolution with rewriting disabled and confirm the basic connection; then enable one mapping, and finally test one rewrite. After removing a Host entry, start a new request and account for existing caches. After disabling a rewrite, avoid reusing the browser’s existing redirect result. Record the actual destination and first matched rule each time so you can identify which layer caused the change. Keep mappings and rewrites that are unnecessary for rule-based routing out of the config to reduce hidden dependencies and troubleshooting work.

Config Validation, Common Misdiagnoses, and Rollback

Validate a config in four layers: file, match, connection, and service. At the file layer, check the selected file and syntax. At the match layer, check whether requests match the intended rules. At the connection layer, check whether the selected path can establish communication. At the service layer, check that login, APIs, and page content work. Success at one layer does not guarantee success at the next. For example, a DOMAIN rule can correctly match PROXY while server authentication fails at the connection layer. If the main page loads but an API fails, check the other requests instead of treating the page opening as proof that everything works.

Use a Small Test Set to Verify Rules

Prepare one domain that should match an exact exception, one that should match a suffix range, and one control domain that should reach FINAL. Save the config, confirm Global Routing is set to Config, start new requests, then review the connection or request records available in the app. The fields shown depend on the current interface; record whatever is available about the destination, policy, server, and error. If the records do not expose every detail, acknowledge that limitation rather than treating a missing field as proof that the rule did not run.

Where possible, test with new connections. Existing long-lived connections, page caches, and background app sessions may keep using their previous state, making a recent rule change appear ineffective. Stop active requests in the relevant app, then establish new connections as needed while keeping other settings unchanged. Do not reorder all rules after one result stays the same; first confirm that a new request was made and check whether it was redirected. Repeatable test conditions are more useful than repeatedly switching settings.

Narrow the Cause Based on the Symptom

If all destinations fail, first check the connection switch, the system VPN configuration status, the current server, and basic network access. Do not start with a rule for one domain. Connectivity Test can help assess the tested connection, but one successful test does not prove that every service, protocol, or destination will work. For the first connection steps, see choosing the default server and using Connectivity Test. If only one site is affected, continue by checking its actual requests and rule matches.

If only one rule seems ineffective, first check for an earlier, broader DOMAIN-SUFFIX or DOMAIN-KEYWORD rule, an address rule, or a FINAL placed too soon. Then check the keyword, ASCII commas, destination name, and policy reference. If the rule matches correctly but the outcome is wrong, treat correct rule selection and successful connectivity as separate issues. Do not keep adding equivalent rules to fix a connection failure; multiple rules pointing to the same failing path only make the config more complicated without changing the cause.

Rollback Should Restore a Known State

Before editing, keep a copy of the current working file and note the selected server and Global Routing mode. If something goes wrong, undo the latest change first. If you changed too much, switch back to a config already confirmed to work and test the same destination again. If it still fails after rollback, the cause may not be the rules: network conditions may have changed, server details may no longer be valid, or the destination service may be having issues. Continue troubleshooting at the connection layer rather than assuming the backup file was altered.

Before updating a config from a remote source, check whether your local changes will be overwritten. Keep a separate record of your exact exceptions and why you added them, then verify them one by one after the update instead of assuming the new file retained them. Update subscriptions and configs separately, and verify the server list and rule results independently. For import options, see importing with Subscribe, Add Server, QR codes, and the clipboard to avoid mistaking a connection-details import issue for a Rule parsing problem.

To share a concise problem report, include the device’s current network type, Global Routing mode, public destination affected, expected policy, what you observed, and only the relevant rules. Remove passwords, full subscription links, authentication fields, and personal browsing records; you do not need to publish the entire config to explain a rule-order issue. For more questions, work through the FAQ; if you have not completed the basic setup, return to the tutorial. A reliable config has rules with clear purposes, verifiable results, and a known rollback path.