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

1. Know the difference between config files, servers, and routing modes

A .conf file is a text-based configuration file. Section names usually appear on their own line, and subsequent entries belong to that section until the next section name. [General] commonly contains key-value settings, while [Rule] contains one matching rule per line. These syntaxes are not interchangeable: putting dns-server = system in [Rule] does not make it a valid domain rule.

Use Home to select a server, control the connection, and view Global Routing. Use Config to manage and select configuration files, and Settings for app preferences. A server entry determines which outbound connection to use; a configuration file determines how requests are handled. A successful server subscription update does not mean the intended rules file is selected in Config.

To test [Rule], select Config under Home → Global Routing. Proxy and Direct are global modes; they cannot tell you whether a specific rule matched. Scene applies the settings for the selected scene, so check which configuration that scene uses when troubleshooting. Start with Config to avoid changes in routing mode affecting your results.

2. [General]: Start with clear, minimal global settings

[General] uses the key = value format. This snippet can go in a test configuration: dns-server = system uses the system-provided DNS. bypass-system and skip-proxy affect bypass behavior for system traffic and specified addresses; they are not general-purpose switches for improving connection speed.

[General]
dns-server = system
bypass-system = true
skip-proxy = 127.0.0.1, 192.168.0.0/16

127.0.0.1 is the loopback address, and 192.168.0.0/16 is a private address range. The example lists only these two ranges and does not cover every local network. If your LAN uses a different subnet, first check its address range and the destination you need to reach. Avoid copying an overly broad bypass range and trying to compensate with later rules.

Do not add the same key repeatedly in one section to mean “append.” How duplicate entries are handled depends on the setting, so keep one clearly defined target value when editing. Record the previous DNS value before changing it. DNS resolution failures and proxy handshake failures are different issues; switching servers will not automatically fix an incorrect DNS setting.

3. [Rule]: Put specific rules first and FINAL last

In Config mode, rules are checked in order, and the first match determines the policy. The example below shows an exact domain match, a domain suffix, an IP range, a geographic match, and a fallback rule. example.com and example.org are included only to demonstrate syntax; the rules contain no server addresses or subscription credentials.

[Rule]
DOMAIN,blocked.example.com,REJECT
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-SUFFIX,example.org,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

• DOMAIN matches the specified domain exactly, so blocked.example.com matches REJECT here before the later suffix rule.
• DOMAIN-SUFFIX,example.com,PROXY matches the domain and its subdomains. It does not match URL paths.
• IP-CIDR matches based on the destination IP address range. The optional no-resolve means this IP rule will not actively trigger domain resolution; it does not mean the request never needs DNS.
• GEOIP,CN,DIRECT uses the destination IP's geolocation data, not the domain suffix or business location.
• FINAL,PROXY handles requests that did not match an earlier rule and should remain at the end of the rules list.

PROXY, DIRECT, and REJECT are policy keywords, not three different protocols. PROXY requires a working proxy connection; DIRECT connects to the destination directly; REJECT blocks matching requests. If your configuration uses named policy groups, make sure the group referenced by a rule exists. Do not replace PROXY in the example with an undefined name.

4. [Host]: Map domains to addresses only

A common [Host] entry uses the format domain = IP address. The left side is not a full URL, and the right side does not include a path or port. The example uses a reserved test domain and a documentation address to show the format. You can copy it into an isolated test configuration, but these addresses do not represent reachable services.

[Host]
portal.example.test = 192.0.2.10
api.example.test = 192.0.2.20

A Host mapping changes the result of address resolution; it does not automatically make a request DIRECT. To connect your own test domain directly, add the appropriate policy in [Rule]. Even with a correct mapping, an HTTPS connection still requires a certificate that matches the requested domain. A Host entry cannot fix a certificate name mismatch.

1. First check the address and port the service is actually listening on, for example whether your test service is listening on 443.
2. Enter only the domain on the left side of Host. Do not include https:// or :443.
3. Check which policy applies to this domain in Rule; verifying the resolved address alone is not enough.
4. If the destination address has changed, update or remove the old mapping, then make a new request. Existing connections and app caches can affect immediate retest results.

A remote proxy may also resolve the destination domain, depending on the outbound method and how the connection is handled. When troubleshooting, check the request destination, selected policy, and actual connection result together. A single DNS lookup on the device does not prove that the entire connection used the same address.

5. [URL Rewrite]: Separate the expression, destination, and action

[URL Rewrite] processes URLs; it does not select a proxy connection. This example redirects an HTTP request for a sample domain to HTTPS. The match expression, destination URL, and 302 action are separated by spaces. $1 refers to the first capture group in the expression, preserving everything after the hostname.

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

For example, http://example.com/docs?a=1 is redirected to https://example.com/docs?a=1. The backslash treats the dot in the domain as a literal character, and the leading ^ anchors the match to the beginning. A 302 returns a redirect; the subsequent HTTPS request still goes through connection and routing processing.

• Start by testing one specific domain. Do not begin with a broad expression that covers every website.
• This example matches HTTP only and redirects to HTTPS, so the destination does not match the same rule again.
• If the rewrite involves a path, check each slash, capture group, and query parameter to avoid constructing the destination URL incorrectly.
• Adding this rule does not expose the full paths of existing HTTPS requests. Processing encrypted request contents requires additional conditions; this example does not require MITM to be configured.

Do not add URL Rewrite to route traffic by domain. To send example.com through PROXY, add a DOMAIN-SUFFIX rule in [Rule]. To pin the resolved address of your own test domain, use [Host]. Keeping each section focused makes changes easier to undo when something goes wrong.

6. Save, enable, and test: change one section at a time

Before editing, keep a copy of the working configuration in Config, and note the selected server and Global Routing mode in Home. A server subscription and a remote .conf configuration are updated separately: the former typically updates server entries, while the latter updates the configuration contents. Editing a remote configuration directly may mean a later update overwrites your changes, so make a separate local copy for testing first.

1. Set a baseline: In Home, select an existing working server and connect. Use Connectivity Test to check the basic connection. This test does not verify a specific website or rule.
2. Edit a copy: In Config, open the configuration you want to test and find the relevant section. Change just one setting or rule, save, and return to the configuration list.
3. Check that it is enabled: Select the file in Config, then go to Home → Global Routing and choose Config. Reconnect if needed to make sure the new configuration is used for this test.
4. Repeat the request: Make a new request using the same domain, protocol, and path. After changing Host or URL Rewrite, do not rely on a cached page to judge the result.
5. Compare the results: Check the destination and policy in the connection log. If the result is unexpected, revert this one change first, then compare the before-and-after results.

For example, when testing DOMAIN-SUFFIX, always visit the same subdomain. When testing Host, keep the destination service and port fixed. When testing URL Rewrite, explicitly enter http:// instead of using an HTTPS address automatically completed by the browser. Record whether the request was never sent, matched the wrong policy, or failed to connect outbound. This is more useful for troubleshooting than changing DNS, rules, and servers all at once.

7. Common issues: Why a configuration may not take effect

For the full syntax, see the rule manual. In an actual configuration, keep settings whose purpose is clear, and maintain domain routing, address mappings, and URL rewrites separately. Record the destination, expected policy, and rollback file for each change so you can review it after future updates.