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

First, check what the .conf file does and how it takes effect

Shadowrocket .conf files are text-based configurations with section names in square brackets. Each section handles a specific category of settings. [General] typically contains key-value parameters, while [Rule] contains rules listed one per line. The same line format cannot be used in every section. A valid file extension does not mean every parameter in the file is valid.

Before you begin, open Config and confirm which configuration is selected, then check the routing mode under Home → Global Routing. To test the file’s routing rules, use Config. If Proxy or Direct is selected, the observed outbound result does not tell you whether [Rule] is written correctly. If you use Scene, also check which settings the scene actually uses.

Connection details and routing settings are separate layers. Updating an existing subscription primarily affects the related connection details; do not assume that it also updates a local .conf file. Updates to a remote configuration file may overwrite local edits, too, so keep the original and make changes to a copy.

General: Key-value parameters control global behavior

[General] uses the key = value format. Check the key first, then the value type: some parameters accept Boolean values, while others take an address or a list. Do not replace equals signs or commas with localized punctuation, and do not put rule lines in this section. The examples below show two independent settings; their values are not suitable for every network.

[General]
dns-server = system
ipv6 = false

dns-server = system uses the system DNS resolver; it does not guarantee successful name resolution on every network. ipv6 = false is a global IPv6-related setting, not a domain routing rule, and it does not replace checking IPv6 connectivity to the server. When troubleshooting, keep the original values for comparison. Avoid changing DNS, IPv6, and rule order all at once.

Rule: First match wins; put FINAL last

The key to [Rule] is not the number of rules, but their order. A typical rule line contains a type, a match pattern, and a policy; FINAL does not need a match pattern. Once an earlier rule matches, later rules do not select a different policy for the same request. Put specific exceptions before broader conditions.

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

The 192.0.2.0/24 range in this example is reserved for documentation; it is not a usable service address. DIRECT means a direct connection, while PROXY sends traffic through a proxy outbound. If you use a custom policy name, make sure it is defined in the active configuration. Similar spelling does not make two policies equivalent, and a protocol name is not automatically an existing policy.

Host: Change name resolution, not the request address

[Host] specifies local name-resolution mappings for domains, usually in the form domain = IP. It controls which address a name resolves to, not which outbound route the traffic takes. Even when a domain maps to a fixed address, the active routing settings still determine how the request is sent.

[Host]
lab.example.com = 192.0.2.10

• Use a domain as the key: Enter lab.example.com, not a full URL containing https:// or a path.
• Use an address as the value: 192.0.2.10 is shown for syntax only. In practice, use an address you are authorized to use and can reach.
• Does not change the port: If the original request uses HTTPS on the default port 443, a Host mapping does not change it to 8443.
• Does not change the certificate name: HTTPS still validates the certificate for the original domain. Mapping the domain to another server does not guarantee that certificate validation will succeed.

When troubleshooting, distinguish an incorrect DNS resolution from an unreachable destination. If an app connects directly to an IP address or resolves the address through its own mechanism, do not assume that a Host mapping will be used. After making a change, send a new request; if needed, close existing connections before testing so a reused connection is not mistaken for the result of the new configuration.

URL Rewrite: Match request URLs with regular expressions

[URL Rewrite] handles HTTP request URLs that the app can identify. The example below uses a regular expression to match a specific HTTP URL and returns a 302 redirect. The three parts are separated by whitespace: the match pattern, destination URL, and action. This format differs from the comma-separated format used by Rule.

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

1. ^ anchors the match to the start of the string, so it does not match a similar substring in the middle of a URL.
2. In example\.com, the backslash makes the period a literal dot. An unescaped dot in a regular expression can match other characters.
3. /guide$ anchors the match to the end of the path. A URL with a query string, such as /guide?from=test, does not match this full expression.
4. 302 specifies a redirect. Whether the client follows it depends on the app that made the request.

Do not read this example as meaning that any HTTPS URL can be rewritten directly. A standard encrypted tunnel exposes only the information needed for the connection, not the full HTTPS path. Matching HTTPS content involves MITM, the target host scope, certificate trust, and app-specific limitations. This example starts with a plain-text HTTP request and does not require expanding the decryption scope.

Combine the four sections: Test one change at a time

These four sections are not features that all need to be enabled. If you only need domain-based routing, start with General and Rule. There is no need to add Host without a specific name-resolution requirement, or URL Rewrite without a clear need to change a URL. A small set of relevant settings is easier to troubleshoot than a large collection of parameters from unknown sources.

1. Keep a baseline: In Config, keep the original configuration. Note the current selection under Home → Global Routing and a test destination that was reachable before the change.
2. Change a rule first: Add only one rule for a specific domain, save and select the edited configuration, then test with the Config routing mode.
3. Test name resolution next: Add a Host mapping only if you need a fixed address. Record the domain, expected IP, and port, and distinguish a resolution problem from a connection failure.
4. Test URL rewriting last: Use a specific HTTP path to check the regular expression. Do not add HTTPS decryption settings at the same time, as that would introduce multiple variables.
5. Keep test notes: Use the request logs available in the app to check the domain, matching rule, and actual policy. If the test fails, revert only the last change and repeat the same request.

Settings → On Demand controls on-demand connection behavior; it does not fix rule syntax. If the connection starts again automatically after you disconnect manually, check the triggers here. That does not mean the .conf file failed to save. Keep the connection behavior consistent during testing so you can compare results before and after a rule change.

FAQ: Why does the result differ even though the file saved?