Shadowrocket Remote Rule Sets: Advanced RULE-SET Setup Guide

1. What RULE-SET does—and what it does not do

A RULE-SET entry tells Shadowrocket to use rules obtained from a remote list and apply a policy when a request matches that list. It is a rule source, not a server, subscription, or policy by itself. The policy at the end of the entry determines what happens to a matching request: for example, it may use DIRECT, PROXY, or a policy name that exists in your active configuration.

This distinction matters when you troubleshoot. A remote list can load successfully while its policy is missing or unsuitable. Conversely, a valid policy does not help if the list URL is unreachable, the list syntax is incompatible, or an earlier rule has already matched the request. A RULE-SET also does not create connection details. It assumes you already have a working connection and a configuration that provides the policy you intend to use.

Think of remote rules as one part of a sequence. In Global Routing, Config uses the active configuration’s rules; choosing Proxy or Direct changes the routing behavior rather than testing a particular RULE-SET entry. For a rule-list test, confirm that the intended file is selected in Config and that Home → Global Routing is set to Config.

2. RULE-SET syntax and a .conf example

In a [Rule] section, a remote rule-set entry follows this general pattern:

RULE-SET,https://rules.example.invalid/lists/sample.list,PROXY

The first field identifies the rule type. The second is the list URL. The last field is the policy applied to a match. The address above uses the reserved .invalid domain and is intentionally nonfunctional; it is a syntax illustration, not a usable list. Use a URL whose content and format you have verified, and make sure the named policy is available in the active configuration.

Here is a minimal example showing where the remote entry belongs and why its position matters. It is not a complete configuration and does not include connection details:

[Rule]
DOMAIN-SUFFIX,internal.example,DIRECT
RULE-SET,https://rules.example.invalid/lists/sample.list,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY

In this example, a request matching internal.example is handled by the local rule before Shadowrocket reaches the remote list entry. A request that does not match that local rule can be checked against the RULE-SET. If it matches, the specified policy is applied. If no earlier rule matches, the later rules are evaluated in order, and FINAL provides the last fallback. The exact result depends on the actual list contents, the active configuration, and the policies available there.

Do not assume that every remotely hosted list uses the same syntax. A list may contain Shadowrocket-compatible rule lines, or it may use a different format, include headers, or rely on syntax that the client does not accept. Review the list’s documentation and, when possible, inspect a small portion of its content before adding it. Do not paste an unrelated file format into [Rule] and expect Shadowrocket to convert it automatically.

3. Rule order, overlap, and policy selection

Rule order is one of the most common reasons a remote list appears to have no effect. Shadowrocket evaluates rules in the active configuration in sequence. If a request matches a rule above the RULE-SET, its route may already be decided. For example, a broad domain rule or an IP range rule placed earlier can take precedence over a more specific match that appears later.

Before changing order, identify the behavior you want. If a local exception should override a broad remote list, place and test that exception accordingly. If the list should decide first for a particular class of traffic, ensure that an earlier rule does not capture that traffic. Avoid moving FINAL upward: it is intended to catch requests that remain unmatched, not to replace the evaluation of rules below it.

• Check the active file: Config may contain several imported files. Confirm which one is selected before editing or testing.
• Check Global Routing: use Config when you intend to test configuration rules. A global Proxy or Direct selection can make a rule-order test misleading.
• Check the policy name: the target must be a supported policy or an available policy name in the active configuration. A typo or a renamed policy can prevent the intended behavior.
• Check overlap: compare the target domain or IP with rules above the remote entry, not only with the remote list itself.
• Start a fresh request: after changing a rule, create a new connection to the test destination. An existing long-lived connection may continue using its established route.

Domain and IP rules do not necessarily describe the same part of a request. A domain rule depends on the domain information available to the matching process; an IP range rule matches an address range. If an application connects by IP, uses a different hostname, or makes requests through several domains, testing only one browser URL may not explain all of its traffic. Use a destination that clearly corresponds to the rule you are checking, and record the exact host or address used during the test.

Keep the fallback policy deliberate. With FINAL,PROXY, requests not matched earlier use the proxy policy. With FINAL,DIRECT, unmatched requests go direct. Neither is universally correct; choose the behavior that fits your own configuration and then verify it. A remote list should add targeted decisions, not silently change the meaning of every unmatched request.

4. Updating remote lists safely

A remote list can change after you add it: its maintainer may add, remove, or reorganize rules, and the content at its URL may become unavailable or change format. Treat a list update as a configuration change. If routing behavior matters for a particular destination, test that destination again after refreshing the relevant configuration or rule data rather than assuming its previous match is unchanged.

Use the update controls available in the active configuration and check the result shown by Shadowrocket. The exact control and wording can vary with the interface and configuration source, so do not rely on an assumed refresh interval. If a configuration is supplied by a subscription, updating that subscription and updating a locally managed configuration are distinct operations. Confirm which file contains the RULE-SET line before refreshing anything.

1. In Config, select the file that contains the remote entry and keep a copy of your current working configuration.
2. Check that the URL is complete, uses the intended scheme, and is accessible from the network available during the update.
3. Review the list format and confirm that its entries are compatible with Shadowrocket’s rule syntax.
4. Refresh using the control provided for that configuration, then check whether the operation reports success or an error.
5. Test one known matching destination and one destination that should not match, using the same network and routing mode.

If updates fail only on a particular network, distinguish a URL-access problem from a rule-parsing problem. A timeout or connection error suggests the list could not be retrieved; a successful retrieval followed by unexpected routing points instead to content, policy, or precedence. Do not repeatedly change several settings at once, because that makes it harder to identify which change affected the result.

5. Troubleshoot stale, incompatible, or ineffective lists

When a remote set seems stale or ineffective, work from the point of failure rather than replacing the whole configuration. Check the selected file, the exact URL, the update result, the list’s syntax, the rule’s position, and the target policy. Then make one test request and inspect the result using the diagnostic information available in Shadowrocket. A single failed page load cannot, by itself, identify whether the problem is retrieval, matching, routing, or the underlying connection.

For a failed fetch, verify the URL character by character, including its path and file name. Check whether the host requires a particular access method or returns a page instead of a raw rule list. A web page containing a download button is not necessarily the same thing as a directly retrievable text list. If the response is accessible but the rules do not behave as expected, inspect the content for unsupported directives, unexpected headers, malformed separators, or a policy name that is absent from the active configuration.

For a list that appears stale, compare its current content with the behavior you expect and confirm that you refreshed the file actually in use. Avoid assuming that updating connection details also refreshes a separately selected local configuration. If the list’s maintainer has changed its format or location, revise the entry only after checking the new address and syntax.

Finally, keep the example scope narrow. Add one remote entry, test a small number of known destinations, and record the selected file, Global Routing mode, network type, update result, and observed route. Once that baseline is clear, add exceptions or additional lists one at a time. This makes it much easier to tell whether a future change came from rule order, remote content, policy selection, or an unrelated connection issue.