Shadowrocket Rules and Config Guide

01 Config Structure and Scope of Changes

In Shadowrocket, server details, subscription entries and config files serve different purposes. Server details specify the connection endpoint and protocol parameters. A subscription imports and updates a set of connection details you already have. A config file organizes general settings, matching conditions and policies. Seeing a server on Home does not mean the active Config contains rules suited to a particular request. Likewise, a complete set of rules cannot fill in a missing server address, password or protocol parameter. Before troubleshooting, check each of these three layers separately rather than assuming every issue is caused by a rule.

Identify the section before interpreting each line

Configs are commonly divided into sections marked by bracketed names. [General] contains general behavior settings, [Rule] contains rules checked in order, [Host] contains static domain mappings, and [URL Rewrite] contains URL matching and rewriting entries. The section determines how subsequent lines are interpreted; a line placed in the wrong section may not work as expected. When reading a config, first locate the most recent section header, then inspect its key-value pairs or rule fields. A line containing a domain is not necessarily a routing rule.

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

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

[Host]
localhost = 127.0.0.1

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

This snippet illustrates how the sections relate; it is not a recommended config for everyone. It shows general settings using system DNS, a rule routing an example domain through PROXY, GEOIP checks for some addresses and FINAL as the fallback. Host and URL Rewrite handle separate tasks. DNS, IPv6 and the final policy must be considered in light of your network and existing connection service. Keep required existing fields when editing; do not delete settings you do not understand just to match the example.

Check which config is active in Config

In Config, distinguish between a file that is available and one that is active. A successful import only means the content appears in the file list; it does not confirm that the current connection uses it. Check the selected file, then inspect its contents. Before experimenting, use the app's available copy or export feature to save a backup and give it a name that makes its purpose clear. After saving, check which file is active again. Otherwise, you might edit a test copy while the connection still uses an older config and conclude that your changes were not saved.

The file's source also affects whether your edits persist. If a config updates from a remote URL, find out whether a later update will overwrite local edits. Updating servers in a subscription and updating a config file are separate operations: a server-list update may not change Rule, and fetching a remote config again may not update a subscription. For custom rules you want to keep, record the added entries, their positions and why you added them. When the remote content changes, compare and merge the differences instead of assuming the contents are unchanged because the filename is the same.

Keep each change to one layer

Establish a baseline in this order: connection details are correct, the intended config is selected, and the rules are ordered correctly. For your first adjustment, change just one domain rule and leave General, Host and rewrite sections untouched. Then generate a new request to test it. If you replace the server, change DNS, alter the final policy and enable rewriting all at once, you will not know which change helped—or have a clear way to roll back if it fails. Write down a specific goal, such as “route the example domain and its subdomains through PROXY,” rather than “optimize all rules.”

When restoring a file, work through the same layers. Restore the original config, check the active mode and selected server, and, if needed, disconnect and reconnect before sending a new request. Existing connections, cached pages and background retries may still reflect the earlier config, so they are not reliable proof that it has been restored. If you have not completed the initial import, return to the main setup guide and verify the basic connection before continuing. This avoids repeatedly changing unrelated rules when the connection endpoint itself is unavailable.

02 General, DNS and Address Resolution

[General] controls general behavior; it is not a collection of “speed settings.” DNS, IPv6 and system bypass settings affect the information available before and during rule evaluation, and can also change network compatibility. When reviewing an existing config, check each key against the app's relevant documentation instead of treating another user's values as a universal standard. In particular, switching between Wi-Fi and Cellular can change the network's resolvers, address families and reachable routes. Different results with the same config do not necessarily mean the rules are wrong.

DNS resolves names; it does not determine the final policy

Accessing a domain usually requires resolving it to an address. DNS determines which address corresponds to a domain; Rule determines the policy applied to a matching request. The two are related, but neither replaces the other. A successful DNS lookup does not ensure that the PROXY connection will work. An IP rule may behave unexpectedly because the actual resolved address differs from what you expected. When troubleshooting, note the domain, whether it resolves, which address it returns and which rule the request matches. Do not assume that every “site won't open” problem is a DNS issue.

[General]
dns-server = system
ipv6 = false

dns-server = system means this setting uses the system DNS resolver; it does not specify a fixed public DNS address. This is a useful baseline for understanding existing network behavior, but it is not guaranteed to suit every network. If your network uses internal domains, switching resolvers arbitrarily may prevent those names from resolving correctly. If system resolution is already failing, check the network first. Keep the original value before changing DNS, then verify the result with a fresh lookup and connection rather than refreshing a page that may be cached by the browser.

Choose IPv6 settings based on reachability

ipv6 = false disables the relevant IPv6 behavior in this example; it is not a general performance recommendation. IPv6-capable networks and services may have different connection requirements from IPv4. A change after disabling IPv6 only indicates that the address family or route warrants further investigation; it does not prove that one address family is always faster. If you need IPv6, check that the target has an IPv6 address, that the server and protocol handle it as expected, and that Rule includes any relevant IP-CIDR6 entries.

When troubleshooting address rules, use the address actually used by the current request. If you checked only an IPv4 range but the request used IPv6, your conclusion is unsupported. Do not turn an address from a single test into a permanent Host mapping either: a domain may return different addresses depending on the network, region or service routing. Fixing one address can interfere with normal availability changes. Start with domain rules for route selection; consider a static mapping only when there is a clear need, and account for its maintenance and scope.

Understand the limits of system bypass and rule logs

bypass-system = true concerns bypass behavior for system traffic; consult the app's current documentation for its precise scope. It does not mean every request will pass through the same Rule set, nor does it guarantee consistent behavior across apps. If an expected log entry is missing, check not only the rule but also whether the request reused an existing connection, came from a system component or matched another bypass setting. Confirm that the request entered the active connection-handling path before investigating Rule order.

For a repeatable test, keep system DNS as your baseline, choose one domain, and record the resolution and access results. Change one DNS-related setting, reconnect and generate a new request. Then compare the address, matched rule and stage where any error occurs. If changing DNS fixes one network, investigate the resolver provided by that network instead of applying the new setting everywhere. The goal is behavior you can explain; one successful page load is only one piece of evidence, not proof that every request behaves as expected.

If the same config works on home Wi-Fi but fails on Cellular, record the test conditions separately. Check whether an On Demand condition changed the connection state, then review Global Routing, the selected server and the resolved address. See the On Demand guide for related triggers. Separating network changes from DNS changes is usually more useful than cycling through multiple DNS settings.

03 DOMAIN Rules and Domain Boundaries

Domain rules specify which policy to use for a name or group of names. They usually track services more closely and are easier to maintain than pinning a single resolved IP. Common types include DOMAIN, DOMAIN-SUFFIX and DOMAIN-KEYWORD. Their difference is scope, not priority. Shadowrocket checks rules in list order, so a precise rule placed after a broader match may never run. Describe the intended scope first, then choose a rule type; do not copy a rule and guess which requests it covers.

DOMAIN: match an exact hostname

DOMAIN,api.example.com,PROXY matches the specified full domain name. Use it to treat an API subdomain differently from other subdomains on the same site. The value is a hostname, not a URL: do not include https://, a path, query parameters or a port. DOMAIN cannot target a page path because different paths on the same host share the same domain condition. Pasting the entire browser address into the domain field is a common cause of match failures.

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

This example handles two exact hostnames separately and leaves other subdomains to later rules. When testing, make sure the request actually uses the hostname in the rule. A page may first contact its main domain, redirect to a login domain, then load content from a separate static asset domain. The main page loading does not prove that all resources use the same policy. Find the specific hostname associated with the failure in the request records, then decide whether to add an exact rule or broaden the match. Do not route every hostname for a site the same way just because some assets failed to load.

DOMAIN-SUFFIX: match a domain and its subdomains

DOMAIN-SUFFIX,example.com,PROXY covers the example domain and its subdomains, making it useful for applying one policy across a domain tree. It matches on domain boundaries, not arbitrary substring occurrences; notexample.com is not part of that domain tree just because its ending looks similar. Usually, enter the root domain directly—no leading asterisk or path is needed. To send just one API host direct, put its exact DOMAIN exception before the suffix rule.

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

This order makes the intent clear: the API exception comes first, and the rest of the example domain uses PROXY. If the lines are reversed, the API request matches the suffix rule first and never reaches the exact exception. DOMAIN has no built-in priority over DOMAIN-SUFFIX; position determines the result. When maintaining many domains, group exact exceptions before broader rules and document why each exception exists, so it is not accidentally removed during later cleanup.

DOMAIN-KEYWORD: use string matching with care

DOMAIN-KEYWORD,example,PROXY matches a keyword in the domain and usually has a broader scope than a suffix rule. It is useful when a stable keyword truly defines the intended targets, but it can also match unrelated names. Short, common strings carry a higher risk of false matches. One successful test does not prove the rule covers exactly one service's domains. For predictable scope, prefer explicit DOMAIN or DOMAIN-SUFFIX entries.

Domain matching also depends on whether the client can obtain the name. A connection identified only by an IP address may not match DOMAIN. Changes to rules may not immediately affect existing long-lived connections either. Test with a new connection and check the actual target and matched entry in the records. If needed, close the relevant app after one test and send a fresh request. If a domain consistently ignores an exception, first check for a broader rule above it, then whether the domain name is available, and only then investigate resolution and caching.

04 GEOIP, IP-CIDR and Other Rules

IP rules match destination addresses directly. They are useful for known ranges, internal services and address-ownership categories, but cannot automatically represent every part of a website's infrastructure. A site may use multiple addresses, and an address may be shared by multiple services. Expanding a single resolved address into a whole network range can pull unrelated destinations into the rule. Before writing an address condition, decide whether you need one fixed address, a controlled network range or a set classified by an address database; these are different requirements.

IP-CIDR and IP-CIDR6 scope

IP-CIDR is for IPv4 ranges; IP-CIDR6 is for IPv6 ranges. The number after the slash is the network prefix length, not a port. IPv4 /32 and IPv6 /128 each refer to a single address. A shorter prefix usually covers a larger range. For an internal network, use the actual subnet; do not widen the range just because the address prefixes look similar. The documentation-only address in this example illustrates the format and is not a real connection target.

[Rule]
IP-CIDR,192.0.2.10/32,DIRECT,no-resolve
IP-CIDR,198.51.100.0/24,PROXY,no-resolve
IP-CIDR6,2001:db8::/32,DIRECT,no-resolve
FINAL,PROXY

no-resolve avoids an additional DNS lookup just to test that IP condition. It is not a “disable all DNS” switch and does not guarantee that the request will never require resolution. If a request has only domain information and no destination address available for matching, do not assume an IP rule with this option will match; evaluation continues with other applicable rules. Whether to use it depends on the goal: avoiding an extra lookup and using a resolved address for classification are different trade-offs.

GEOIP checks address ownership

GEOIP,CN,DIRECT uses available address-ownership data to check whether a destination belongs to the specified region code. It checks IP attribution, not the domain suffix, website language or visitor's location, and may not reflect the service's full deployment. The result can change when the same domain resolves to different addresses on different networks. Database classifications may also differ from actual service operations. For a domain that must always use a particular policy, add an explicit domain rule before GEOIP rather than relying on a region classification to handle a service-specific exception.

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

This order pins the API policy first, applies GEOIP to other eligible targets, then falls back to the final rule. Even if the API resolves to an address classified as CN in this test, the earlier DOMAIN rule matches first and uses PROXY. If GEOIP were first, the API could match that condition instead. To troubleshoot, check both the actual address and rule order; a domain and region label alone do not prove the client classified it incorrectly.

USER-AGENT: when it applies and its limits

USER-AGENT depends on request-header information being available; it is not a reliable way to identify every app. Apps may change their headers, and different requests from one app may use different values. Headers in encrypted connections may not be directly available. Do not assume a request carries a matchable USER-AGENT just because it comes from a particular app. For stable routing, first see whether explicit domain and address conditions will work instead of inferring rule conditions from an app's displayed name.

[Rule]
USER-AGENT,ExampleClient*,PROXY
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT

ExampleClient* in this example only illustrates the format of a match value. Use information that is actually observable and a matching method supported by the app. Do not enable traffic decryption settings you do not understand just to make this rule match; USER-AGENT is not a general requirement for routing. If the records do not expose the request header, observable domain or IP conditions are easier to verify and maintain across networks. Readable configs depend on clear conditions, not on using as many rule types as possible.

When regression-testing address rules, choose at least one target that should match and one that should not, and confirm that both use new connections. Test internal subnets on different Wi-Fi networks too, since the same address range may identify entirely different devices on another network. If the issue is slow overall connectivity rather than one rule, see the step-by-step guide to troubleshooting slow speeds to check server reachability, local networking and rule matching separately.

05 PROXY, DIRECT, REJECT and Global Routing

The last field of a rule is usually its policy. PROXY, DIRECT and REJECT mean proxy the connection, connect directly or reject the request; they are not the three modes in Global Routing. A policy determines what happens after a rule matches, while the mode determines the overall routing behavior currently in use. Confusing them can lead to assumptions such as “I set DIRECT, so it must bypass the proxy” or “changing the rule had no effect.” Before testing, check Global Routing, then the active Config, then the specific matching rule.

Config: check the active configuration

The Config mode is the main mode for testing Rule behavior. In this mode, requests entering the relevant processing path use the config conditions to choose a policy. It does not guarantee that every request will behave as expected; that depends on the active config and related settings. The result may still differ if the wrong file is selected, a broad rule appears earlier, or Host changes the resolved address. When documenting a rule change or asking for help, specify that the mode is Config rather than merely saying the connection is on.

Proxy and Direct: use them for comparison

Proxy mode is mainly for checking the proxy route; Direct mode is mainly for observing direct connections. They are useful comparison conditions, but are not absolute switches that override every system bypass, resolution or protocol behavior. For a fair test, keep the server, network and destination the same and change only the mode. If Proxy works but Config does not, check the rules, final policy and related settings first. If Proxy also fails, verify the connection details and server reachability before rewriting Rule.

PROXY does not provide a connection service

PROXY routes a matching request through the relevant proxy path. It does not create server details or fix an expired subscription. On Home, confirm that the selected server comes from connection details you already have, and check its address, port, authentication and protocol parameters. Some protocols also require a transport method, TLS name or other fields; matching names alone do not prove the parameters are complete. The app's one-time purchase is separate from a connection service, and a correct rule does not guarantee the server is available.

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

DIRECT connects to the destination over the current network; it does not guarantee the destination is reachable. Internal names may depend on DNS from a specific Wi-Fi network, and some servers may accept connections only from certain source addresses. If DIRECT fails, check the local network and resolution instead of immediately switching to PROXY. Rule correctness and destination reachability are separate questions: the expected DIRECT rule may have matched correctly even if the target refuses the connection because the network does not meet its requirements.

Keep REJECT rules narrowly scoped

REJECT blocks matching requests and is suited to targets you know you do not need to access. Do not start by applying it to a broad keyword or large address range; that may also block an API, login redirect or required resource. If a page is partly blank, keeps reloading or cannot sign in, check whether relevant requests matched a reject rule. Before deleting rules, narrow the scope temporarily in a copy and repeat the same test. Keep the smallest change that confirms the condition caused the problem.

FINAL also needs a policy. For example, FINAL,PROXY sends requests not matched by earlier rules through the proxy path, while FINAL,DIRECT connects the rest directly. These are different configuration goals; neither is right for every user. Before choosing a final policy, list the requests that need exceptions, confirm that the service you use is reachable, and consider how you will maintain the rules. See the FAQ for common issues, but include the active mode and actual matched policy in troubleshooting notes rather than just writing “connection failed.”

06 Rule Order, Exceptions and FINAL

The key principle is that rules are checked from top to bottom, and the first applicable match determines the policy. The client does not collect every condition and automatically choose the “most specific” one; in an ordinary ordered rule list, a later exact match does not override an earlier broad match. A config depends not only on which rules it contains but also on their positions. If a rule seems ineffective, read down from the top. The request may be caught by an earlier entry that a search for the rule itself would not reveal.

Put explicit exceptions before broader conditions

One maintainable layout is to list specific service exceptions first, then domain trees or controlled IP ranges, then general classifications, and FINAL last. This is not the only valid structure; it simply makes it easier to understand why a target differs from most others. For example, if an API must use PROXY while the rest of its domain tree should use DIRECT, place the API's DOMAIN rule before DOMAIN-SUFFIX. When adding a keyword rule later, check that it does not cross an existing exception boundary.

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

A new request to api.example.com matches the first line, so the later suffix rule does not determine its result. A request to static.example.com does not match the first line, so the second line can decide the policy. For a target that matches no domain rules, consider the address rules and GEOIP next. This reading order also works for a manual audit: mark each rule as “match” or “no match” for the target. The first match shows whether the config reflects your intent.

FINAL is a fallback, not a rule fix

FINAL usually belongs at the end of Rule to handle requests not covered by earlier conditions. If placed near the top, it prevents later ordinary rules from running and can mislead readers into thinking later exceptions still apply. Multiple FINAL entries usually indicate that configs were merged without cleanup. In a copy, keep one fallback at the end that suits your goal, then review the preceding entries. Appending a second FINAL cannot “override” the first, and FINAL is not a marker for statistics or testing.

When merging two configs, do not simply append the contents of both complete Rule sections. First identify exact exceptions, check for conditions with conflicting policies, decide the order of broader entries, then consolidate them into one clear fallback. Duplicate conditions may be valid syntax but can mislead maintainers about which line actually takes effect. Cleanup is more than removing identical text: a suffix rule may cover many full-domain rules that are not identical.

Test your understanding with a conflict case

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

In this example, the API request matches the first line, so the second line never determines the result. Fix the order rather than changing the proxy server or adding another copy of the same DOMAIN rule at the end. Conversely, if the first line's DIRECT policy is intended to cover every subdomain, remove later exceptions that have no effect so the file reflects your actual intent. Fewer rules are not always better, but every rule you keep should have a clear scope and a testable purpose.

After changing rules, allow for delays caused by connection reuse. An existing connection may keep using its original route, and refreshing a page may not create the new connection you expect. Save the config, confirm it is active, reconnect if needed, then run a new test. For comparison, keep the network, server and target the same so an address change caused by switching networks is not mistaken for a rule-order change. For domains with dynamic addresses, record the actual resolution result for each test.

Finally, check for unintended effects on neighboring services as well as confirming that the target exception works. For example, after changing an exact domain rule to a keyword, test at least one unrelated name containing the same string. After moving GEOIP up, check that APIs requiring a fixed PROXY policy still match their exceptions first. Rule maintenance is about preserving boundaries between conditions, not continually appending entries at the end. Keep a rollback copy and rerun a fixed test set after each cleanup.

07 What Host and URL Rewrite Do

Host and URL Rewrite often appear in the same config, but they solve different problems from Rule. Host uses static mappings to affect name resolution. URL Rewrite changes or redirects URLs that match its conditions. Rule selects a handling policy. A domain matching PROXY does not mean its resolution or rewriting is correct, and adding Host does not make a request connect directly. When troubleshooting, disable or roll back one section at a time so you can observe separately what destination the request uses and which route it takes.

Host: the relationship between names and addresses

[Host]
localhost = 127.0.0.1
test.example.com = 192.0.2.10

The first line is a common example of a local name mapping. The second uses a documentation-only address to illustrate syntax; it is not a working service. In practice, use a static mapping only when you know the target address and have a specific test in mind. Normal website resolution may return multiple addresses and support failover; Host pins local resolution to the specified result. If the service address changes, a mapping that once worked may cause the failure. Document the purpose of each custom mapping and consider removing it when a temporary test is finished.

A static mapping usually leaves the request's domain name unchanged and does not replace TLS name verification. If you point an HTTPS domain at another server, that server must still handle the original domain correctly and provide a matching certificate. Reachable IP does not guarantee a successful connection. For a certificate name mismatch, restore normal resolution or check the server configuration. Do not blame the DOMAIN-SUFFIX policy or disable verification to conceal an incorrect mapping.

URL Rewrite matches URL conditions

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

This example redirects a matching HTTP URL to an example HTTPS URL. In the regular expression, ^ marks the start of the string, \. matches a literal dot in the domain, and the trailing slash narrows the match boundary. Without the escape, a dot may match any character. Without a suitable boundary after the domain, the expression may also match URLs you did not intend to change. The destination is fixed; do not assume it automatically preserves every path and query parameter.

302 indicates a redirect response. A redirect makes the client request a new URL; it does not silently replace all connection behavior within the original request. The new request still needs to resolve, be routed and connect successfully. If the destination is unreachable, a successful rewrite will not make the page load. Test whether the original URL matches the expression, whether the response points to the expected destination, and whether the follow-up request is handled correctly. A changed browser address alone does not prove that subsequent resource requests work.

Check what you can observe before enabling rewriting

HTTP and HTTPS expose different information. Do not assume that a rule in the config can read the full URL of every encrypted request. For information that requires additional access, first review the app's current documentation and consider the certificate and trust settings involved. Ordinary rule-based routing on this page does not require traffic decryption, and enabling it is not the default fix for access problems. If you only need to route a domain through PROXY, use Rule instead of adding another processing layer to match paths.

A maintainable rewrite rule should document its original scope, destination and expected response. When copying a complex regular expression with capture groups, first confirm how the replacement string refers to captured text. Test a simple path and a path with query parameters separately; expressions that look similar are not necessarily equivalent. Keep temporary diagnostic rules separate from long-term rules and remove them when finished, so leftover behavior does not affect other paths later. Complexity does not guarantee accuracy; the simplest expression that meets the need is usually easiest to review.

For combined troubleshooting, first keep normal DNS and a minimal Rule set, and confirm that the destination is reachable. Then add Host or URL Rewrite. If the failure appears only after adding Host, check the address and certificate. If it appears only after adding a rewrite, check the match boundary, destination and for loops. If it persists after removing both, investigate the server and network layers. This avoids adding rules to compensate for an incorrect mapping or redirect, and makes it clear what each retained section is for.

08 Config Validation, Troubleshooting and Recovery

After editing, validate against one clearly defined goal rather than treating “the page opens” as the only result. Specify the domain, network, server, expected rule and intended policy: PROXY, DIRECT or REJECT. Then confirm the active Config and Global Routing mode, and send a new request. Even if it fails, this helps distinguish whether the rule worked and whether the problem occurred during resolution, connection, authentication or the destination's response, instead of prompting blind changes to the rule list.

Keep repeatable test records

For each test, record the target, network, selected server, config file and matched result. Prepare at least three targets: one that should use PROXY, one that should use DIRECT and one ordinary target that should reach FINAL. If you use reject rules, add a target expected to match REJECT. Use services you are already authorized to access; you do not need to find a new connection service just to test. When comparing two runs, keep all conditions except the changed setting as consistent as possible.

Test Connectivity Test separately from real requests

Connectivity Test can help assess reachability under its specific test conditions, but a successful test does not guarantee that every website, request or routing rule will work. Business requests may use different domains, address families, connection methods or authentication flows. A failed test does not automatically mean every service is unavailable either; check the test target and error. Use the test tool to narrow the problem, then confirm the rule and route with a new real-world request. Do not treat one result as a complete picture of network status.

If all PROXY requests fail, keep the config minimal and check the active server and the status of your existing service. If only one domain fails, check its matched rule, resolution and destination response. If the main page loads but resources are missing, check each resource domain and any REJECT entries. If the problem occurs only after changing networks, record changes to DNS, On Demand and address family. This is more effective than changing every General setting at once and avoids breaking working rules because of one failing endpoint.

Keep logs limited to what is needed

Use the app's records to check the target, matched rule and failure stage, but do not paste subscription URLs, passwords or authentication fields into public discussions. Before saving troubleshooting materials, check screenshots and text for sensitive information. Share the smallest rule snippet needed to reproduce the issue. Server names may contain user-defined labels, so review those too. Sharing a complete config does not automatically make troubleshooting more effective; clear request conditions and evidence of the first match are usually more useful than a large, unfiltered log.

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

The minimal snippet above shows rule order without exposing connection credentials. When documenting an issue, replace real service domains with examples but preserve the structural relationship, such as “the exact exception comes before the suffix rule.” If the issue depends on actual address ownership, say that the details have been anonymized so readers do not mistake example addresses for real test results. Reproduction materials should explain the logic without subscription or server authentication details. Never use a private URL as an issue title or filename.

Roll back and check for another remote update

If behavior is unexpected, restore the pre-edit copy, confirm it is selected, restore the original Global Routing mode and server selection, reconnect, then repeat the same tests. If the issue immediately disappears, reapply changes one at a time to find the smallest difference responsible. If it persists, check whether the network or service status has also changed. A later remote config update may overwrite local edits, so after rollback, verify the file contents rather than relying on a familiar name in the list.

For routine maintenance, keep a stable config, a test copy and a brief change log. Run a fixed test set after adding rules; after a subscription update, confirm the selected server is still the one you expect. When moving to a new device, check that the config was imported rather than assuming the app's purchase status syncs all connection details. See the guide to purchased apps and using Shadowrocket on iPad. Restoring a purchase only restores access to the app; it does not migrate configs or verify server parameters.

To repeat the complete connection setup, return to the Shadowrocket setup guide. For common issues, see the FAQ and troubleshooting guide. To verify the app's source, visit the three-point authenticity check. Cross-check the app icon, developer Shadow Launch Technology Limited and app ID 932747118 on the App Store listing. Keep configs understandable, verifiable and reversible; rule count and file length are not measures of quality.