Shadowrocket .conf File Explained: General, Rule, Host, and URL Rewrite

What You’ll Learn

Shadowrocket’s .conf file is configuration text, not a service plan. This guide is for users with a working connection who want to read or edit a configuration: learn what each of the four sections does, make changes in a copy, then check the rules with Config selected under Global Routing. The examples illustrate syntax only; their domains and addresses are for documentation and do not provide a working service.

1. Read the section headers before the individual lines

Square brackets mark the start of a section. Settings under [General] belong to General until the next section header. Blank lines help separate content visually but do not start a new section. When editing, preserve English keywords, commas, equals signs, and square brackets; make sure your input method hasn’t converted punctuation to full-width characters.

These four sections are not four proxy protocols or four network stages executed in file order. General provides global options, Rule selects how requests are handled, Host maps specified domains, and URL Rewrite applies expressions to matching URLs. The “top to bottom” rule applies to matching order within Rule; it should not be mechanically applied to the entire file.

4 sections

This guide covers: General / Rule / Host / URL Rewrite

2 delimiter types

General and Host commonly use equals signs; Rule uses commas

1 fallback rule

The minimal example puts FINAL at the end of Rule

[General]
dns-server = system

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

[Host]
test.example.com = 192.0.2.10

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

2. General: global options are not traffic-routing rules

General settings commonly use the form parameter = value. For example, dns-server = system means to use the system DNS. This setting affects name resolution; it does not mean that all requests go DIRECT or all requests use a proxy. Request handling also depends on the current Global Routing mode and the applicable rules.

[General]
dns-server = system

Before changing DNS, identify where the problem occurs: does name resolution fail, or does the connection fail after the destination address has been resolved? Don’t change DNS, rules, and remote connection settings at the same time; even if things improve, you won’t know which change made the difference. An existing configuration may include other General settings, so this one-line example is not a reason to replace the entire section.

Keep valid settings in the existing configuration; change only the item you’re checking.
Use half-width characters for values; don’t append explanatory text in Chinese directly to a value.
Don’t put DOMAIN-SUFFIX or FINAL in General; they belong in Rule.
If system DNS and the specified resolver return different results, record the results first, then decide whether a change is needed.

3. Rule: check the match, policy, and order together

A typical Rule entry has the form type,match,policy. DOMAIN-SUFFIX,example.com,PROXY matches example.com and its subdomains, then uses PROXY. The match value does not include https://, a path, or a complete URL. To match a single hostname, use DOMAIN for a more precise rule.

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

In this example, api.example.com matches DOMAIN first, so it never reaches the DOMAIN-SUFFIX rule below. Other example.com subdomains can match the suffix rule. If you swap the lines, the broader suffix rule matches first and the single-domain exception won’t work as intended. FINAL handles requests that did not match any preceding rule and usually goes last.

Match by domain

DOMAIN: Matches an exact domain, such as api.example.com.
DOMAIN-SUFFIX: Matches example.com and its subdomains—not any string that happens to contain it.
DOMAIN-KEYWORD: Matches a keyword in the domain; the scope may be broader than expected.

Put specific exceptions before broader matches; domain rules don’t include URL paths.

Match by address and set a fallback

IP-CIDR: Matches an IP address range; 192.0.2.0/24 is a documentation-only example range.
GEOIP: Matches the destination IP using a geolocation database; results depend on its records.
FINAL: Leave out the match value and specify a fallback policy directly, such as FINAL,PROXY.

no-resolve avoids triggering an additional DNS lookup for this IP rule; it does not disable DNS entirely.

DIRECT means connect directly; PROXY sends the request to the proxy policy. These policy names are not server addresses. GEOIP results depend on IP address and database data, so a Chinese-language website is not guaranteed to match CN. For an exception targeting a known domain, use a clear domain rule rather than guessing from the website’s language.

4. Host: map a domain to an address, not a policy

Host maps a specified domain to an address, typically in the form domain = IP address. That is different from Rule, which determines what policy to use after a match. Mapping a domain to an address does not automatically make the request DIRECT; check the result against the current routing mode and rules.

[Host]
test.example.com = 192.0.2.10

This line maps only test.example.com; it does not automatically cover every subdomain of example.com. If a site relies on dynamic addresses or distributed endpoints, a fixed address may stop working after a service change. Record why you added the mapping, and test again after removing it. Don’t keep unexplained Host entries from old configurations indefinitely.

Choose between Host and Rule based on what you need to change

To specify an address for name resolution

In Host, enter the full domain and the known destination address.
Make sure the address actually belongs to the service you want to access.
Remove the documentation-only example address before testing real access.

To change how a request is handled

Add DOMAIN or DOMAIN-SUFFIX under Rule.
Choose DIRECT, PROXY, or another valid, defined policy.
Put specific exceptions before broader rules and FINAL.

Check the resolved address and routing policy separately; don’t use Host in place of a traffic-routing rule.

5. URL Rewrite: match URLs, not traffic by domain

URL Rewrite uses an expression to match an address, then specifies a replacement or action. The example below redirects HTTP to HTTPS with a 302 response: \. in the regular expression matches a literal period, (.*) captures the path, and $1 in the replacement refers to the first capture group.

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

Example input: http://example.com/help.
Replacement URL: https://example.com/help.
^ and $ anchor the match to the beginning and end, so it won’t match just part of an address.
302 is a redirect response status—not a proxy port or a Rule policy.

This example matches URLs that start with HTTP; it does not mean every HTTPS path can be read directly. HTTPS paths are encrypted, so handling them involves additional requirements. Adding a URL Rewrite section alone does not meet those requirements. This guide does not require certificate changes, and you should not expand the scope just to test this HTTP example.

6. Save, select Config, and test one change at a time

Editing a file and making it take effect are separate steps. After saving your changes in Config, make sure that configuration is selected. To test Rule, go to Home → Global Routing and select Config. If Proxy or Direct is still selected, the result won’t tell you whether the routing rule you just changed is correct.

Keep a copy of the original

In Config, find the local configuration you’re currently using and make a copy or backup of the original text first. Note the file name; don’t overwrite your only working configuration.
Change one thing

Open the editor for the target configuration and change just one item in one section. For example, first add DOMAIN,api.example.com,DIRECT; don’t change Host and DNS at the same time.
Save and select

After saving, return to Config and make sure the target configuration is selected. Then go to Home → Global Routing → Config to confirm that this test is using rule-based routing.
Start a new request

Make the request again instead of relying on an existing long-lived connection. Record the domain, expected policy, and actual result; reconnect before testing if needed.
Compare with the original

Remove the line you just added and test the same target again. If the difference isn’t what you expected, check the match order and active configuration instead of adding more changes.

Config

Recommended

Requests are handled according to the rules in the selected configuration. Whether a request matches DIRECT or PROXY depends on the rule content and order; unmatched requests are not necessarily DIRECT.

Use for: testing Rule changes in this guide and everyday rule-based routing.

Proxy

Handles requests using the proxy mode, without selecting a routing policy for each request through Rule. Use it to check whether a proxy connection works, but not to verify that a rule matched.

Use for: separating connection issues from rule issues when you already have a service to connect to.

Direct

Handles requests using direct mode. Results in this mode can’t tell you whether a PROXY rule is correct.

Use for: checking how the same destination behaves with a direct connection.

Scene in Global Routing applies scene settings and should not be confused with testing rules in Config. Settings → On Demand manages conditions for connecting on demand; it is not where you edit Rule. If the connection changes automatically with network conditions, check these separate settings before testing so a connection-state change isn’t mistaken for a .conf syntax error.

7. If a configuration doesn’t take effect, narrow it down by symptoms

A successful save only confirms that the editing operation completed; it does not prove that every rule does what you intended. First check the file and routing mode, then verify the target, rule order, and syntax. You can work through the checks below with your existing working connection—there’s no need to switch services.

Symptom	What to check first	What to do
No change after adding a Rule	Active file and Global Routing mode	Make sure the file is selected in Config, then choose Config under Home → Global Routing.
A domain-specific exception doesn’t work	Rule order	Put the DOMAIN exception before the broader DOMAIN-SUFFIX rule, and keep FINAL at the end.
Only one domain is unreachable	Static mapping in Host	Remove the old mapping for that domain and test again without changing DNS at the same time.
URL Rewrite has no effect	Protocol, hostname, and expression	Check whether the request uses HTTP or HTTPS, and whether the escaped period and path match.
Parsing problems after saving the file	Section headers and half-width punctuation	Check the square brackets, commas, and equals signs. Undo the most recent change, then reopen the configuration.

A subscription you already use may maintain connection details, but updating it does not necessarily update the local .conf file currently in use. If the configuration comes from a remote source, distinguish the remote original from your local copy; a later update may change its contents. Keeping a record of local edits makes issues easier to trace than repeatedly importing the same file.

For a minimal test, keep only the necessary General settings, the target Rule, and FINAL. Leave out example sections you don’t need.
Record one change, one test target, and one result at a time. Avoid changing multiple variables together.
For the full syntax and more details about each section, see the Configuration Reference. For definitions of key terms, see the Quick Glossary.