Shadowrocket Config File Syntax: An Advanced Rules Deep Dive

At a glance

This guide is for Shadowrocket users who already have their own subscription and want to understand or safely edit a .conf file. It explains how sections, rule order, policies, and remote rule sets fit together, then shows how to make a small change and verify the result. Treat the examples as incomplete documentation snippets, not ready-to-import configurations: keep a backup of your active file, preserve its existing policies, and never publish subscription URLs, credentials, or private configuration data.

1. How a .conf file is structured

A Shadowrocket configuration file is a text document organized into named sections. A section begins with a heading in square brackets, such as [General] or [Rule]. The lines beneath it belong to that section until another heading begins. The section name tells you what kind of information follows; it does not mean that every configuration must contain the same sections or settings.

Common sections include [General] for general behavior, [Proxy] for proxy definitions, [Proxy Group] for named policy groups, [Rule] for traffic-matching rules, and [Host] for host mappings. Other sections can control features such as URL rewriting or TLS interception. A configuration downloaded from a source you trust may contain additional sections. Before editing one, identify what it already defines and what other sections refer to those definitions.

[General]

General configuration options; inspect before changing defaults

[Proxy]

Proxy definitions, commonly supplied through your own subscription

[Proxy Group]

Named policies that rules can select

[Rule]

Conditions and actions used to route matching connections

Most rule lines are comma-separated fields. A typical rule has a rule type, a match value, and an action or policy. For example, DOMAIN,docs.example.com,DIRECT means that a request matching that exact domain uses the DIRECT policy. The domain ending in .example is reserved for documentation; this line is a syntax example, not a service recommendation or a complete configuration.

Keep section headings and values on separate lines, and avoid pasting a line into the wrong section. A valid-looking rule placed under [General] may not be interpreted as a rule. When editing, change one item at a time, preserve comments that explain the file, and do not assume that saving a file proves every referenced policy or remote resource is valid.

2. Rule syntax, policy names, and first-match order

Rule order matters. Shadowrocket evaluates applicable rules in the active configuration, and an earlier matching rule can determine the action before a later, broader rule is reached. A common pattern is to put specific exceptions before broad domain or network rules, then finish with an intentional fallback such as FINAL,PROXY or FINAL,DIRECT. The correct fallback depends on the configuration’s purpose; do not replace the existing one without understanding what unmatched traffic should do.

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

This excerpt illustrates structure only. DOMAIN is for an exact domain match, while DOMAIN-SUFFIX covers the named suffix and its subdomains. IP-CIDR matches an IPv4 address range written in CIDR notation. The address block 192.0.2.0/24 is reserved for examples and should not be treated as a real destination range. The optional no-resolve flag can avoid resolving a domain merely to test an IP rule, but it also means the rule cannot match an address that has not already been obtained. Use flags only when their effect is understood.

Rule form	Typical scope	Practical check
`DOMAIN`	An exact host name, such as `docs.example.com`.	Use when the intended target is one specific host, not every subdomain.
`DOMAIN-SUFFIX`	A domain suffix and its subdomains.	Check whether a broader match could also affect sign-in, images, or other essential hosts.
`IP-CIDR`	An IPv4 address or range in CIDR notation.	Confirm whether the destination address is known and whether the optional flags fit the use case.
`FINAL`	Traffic that did not match an earlier rule.	Read the action after the comma; the fallback is not automatically a proxy route.

The action must refer to a policy that the active configuration can use, such as DIRECT, PROXY, or a named group defined in [Proxy Group]. If a rule points to a group name that is missing or has been renamed, the intended route may not work. Policy names are references: check that spelling and punctuation match between the rule and the group definition. A policy named Work has no special meaning unless the configuration defines it.

Takeaway: Read from the narrowest match toward the fallback

Before changing a broad rule, check whether an earlier specific rule already handles the domain. Then check the referenced policy and the final fallback. This simple order—match, action, policy definition, fallback—often reveals why a request took an unexpected route without requiring a wholesale rewrite.

3. Remote rule sets: convenient, but still part of your configuration

A remote rule set lets a configuration refer to a rules resource maintained at a URL rather than embedding every rule line locally. A common form is RULE-SET followed by a resource URL and a policy name. For example:

[Rule]
RULE-SET,https://rules.example/route.list,PROXY
FINAL,DIRECT

The URL above is a placeholder and does not provide a usable list. The syntax, accepted resource format, refresh behavior, and availability of remote rule-set features can depend on the Shadowrocket version and the configuration source. Check the active file and the app’s current behavior rather than assuming that every URL or list format is supported. A remote list may also contain many individual conditions, so its position relative to local rules can affect which action wins.

Assess a remote rule set as configuration code, not as a harmless label. Confirm who controls the source, whether the address uses HTTPS, what the list is intended to match, and which policy receives matching traffic. If the source changes its contents, the behavior can change even when you do not edit your local file. Avoid adding a URL from an unknown message or copying a list whose contents and maintainer you cannot verify. Never put a private subscription URL, token, or account detail into a public rule list.

Keep a record of the original file before adding a remote reference. If routing changes unexpectedly, temporarily disable or remove only the new reference in a copy of the configuration and compare the result. Do not delete unrelated rules or policy groups as a first response. If you rely on remote rules, periodically review whether the resource still exists and whether its current purpose matches the policy you assigned.

Choose a rule arrangement that matches how you maintain the file

Local rules

Keep a small, targeted exception close to the configuration it affects.
Review the exact match and action before saving changes.
Back up the file so you can undo a test quickly.

Remote rule set

Use only a source whose owner and purpose you can verify.
Check the referenced URL, list format, and selected policy.
Re-test after updates because list contents can change remotely.

Keep local edits narrow; use remote rules only when you can review and trust the source that controls them.

4. Make one change and verify the actual match

Start by identifying the active configuration in Shadowrocket’s Config area. A file present in the list is not necessarily the file currently controlling traffic. Note its name and source, and save a separate copy before editing. If the configuration is remote, a later refresh may replace local changes; preserve the original and understand how the source is updated before testing an edit.

Back Up the File

In Config, identify the active file and use its available export or share action to save a copy to Files. Open the saved copy or check that it is readable before making changes. Keep private URLs and credentials out of screenshots and shared documents.
Find the Rule

Search the active file for [Rule], the target domain, its suffix, and any referenced policy name. Also inspect the rules immediately above and below the intended insertion point. A later rule may never be reached if an earlier rule already matches.
Change One Line

Add or edit one narrow rule using a documentation domain such as docs.example.com only in examples; use a real target only when you have a specific reason. Preserve the rest of the configuration, and confirm that the action names a policy that exists.
Reload and Test

Save the edited file and make it active if required by the current interface. In Home, confirm Global Routing is set to Config for a rule-based test. Generate a new request to the same target and inspect the available connection or request details to see which rule or policy was applied.
Restore if Needed

If the test breaks other access or does not show the intended match, restore the backup and compare again. Change only one variable per test: do not simultaneously switch servers, DNS options, and rule order, or the result will be difficult to interpret.

Use a repeatable test: keep the device, network, selected server, target domain, and Global Routing mode unchanged between comparisons. A successful latency test does not prove that a particular domain matched the intended rule. Likewise, an active connection indicator does not establish that a web request used the policy you expected. Check the request’s observed rule or policy where the app exposes that information, then test the destination itself.

Do not paste a complete private configuration into a public troubleshooting post. A configuration may expose server addresses, authentication values, subscription URLs, internal host mappings, or other identifying details. If you need help interpreting a syntax error, share only a minimal redacted excerpt and replace sensitive values with clearly fictional placeholders.

5. Certificate trust, URL rewriting, and script boundaries

Most routing rules do not require installing or trusting a certificate. A configuration may include [MITM] settings for TLS interception, and some URL rewrite or script features may depend on interception to inspect encrypted traffic. These features can expose request data or allow changes to app responses. Enable them only for a clear, limited purpose, and understand which domains and functions are affected before accepting any certificate trust prompt.

Never install a certificate merely because an unfamiliar rule list or script tells you to do so. Certificate trust changes the security boundary of the device. If you have a legitimate need for an interception feature, read Shadowrocket’s current instructions, identify the certificate source, restrict the scope as much as the available settings allow, and remove or disable the feature when it is no longer needed. Do not use interception to bypass security warnings or to inspect traffic you are not authorized to access.

Third-party scripts deserve at least as much scrutiny as remote rule lists. A script can alter responses or perform actions beyond simple routing, depending on its type and permissions. Before adding one, check its maintainer, source, update behavior, requested permissions, and exact purpose. Do not run a script copied from an unverified source, and do not include credentials or private subscription details in script arguments, URLs, or shared configuration snippets.

Why did my new rule have no effect?

Confirm that the edited file is active, Global Routing is set to Config, the request matches the rule’s exact domain scope, and an earlier rule is not taking precedence. Then verify that the rule’s policy name exists.

Can I replace the whole [Rule] section with an example?

No. Examples here are partial. Replacing the section can remove existing exceptions, remote rule references, policy choices, or the intended FINAL behavior. Back up the file and edit only the necessary line.

Should I trust a certificate to fix routing?

Not for ordinary rule matching. Certificate trust is relevant to features that inspect encrypted traffic, not a general remedy for a rule that points to the wrong policy or appears in the wrong order.

Keep the boundary clear: Shadowrocket is a paid client, while any connection service is separate. A client purchase does not include a service plan; obtain your own subscription from your service provider. Treat configuration files, remote lists, certificates, and scripts as separate trust decisions, and make each change small enough that you can identify and reverse its effect.