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

1. .conf file structure: Section headers determine how each line is interpreted

A Shadowrocket .conf file is a text-based configuration file. Names in square brackets are section headers, such as [General]. The lines that follow belong to that section until the next header. The same line can mean different things in different sections, so check where it appears before editing.

[General] contains global settings, [Rule] defines traffic matching and policies, [Host] provides local domain mappings, and [URL Rewrite] defines URL rewrites. These are not four routing rules that run one after another. In particular, the order of sections in the file does not represent the sequence every network request follows.

The example below is for understanding the file structure. example.com is a sample domain, and 192.0.2.10 is a documentation-only address, not a real service address. Do not replace your active configuration with this example. Standalone comment lines beginning with # are for explanation and are not used for rule matching.

[General]
dns-server = system

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

[Host]
lab.example.com = 192.0.2.10

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

Use standard ASCII square brackets, commas, and equals signs when copying configuration lines. Do not append explanatory text in Chinese or any other language to the end of a rule. To keep changes easy to review, add a standalone comment above the relevant line to explain the change instead of rearranging every section.

2. General: Global settings and DNS

Settings in [General] commonly use the form key = value. In this example, dns-server = system means to use the system-provided DNS server. This is not a routing rule, nor does it mean all requests use DIRECT. Resolving a domain to an address and choosing a policy for the connection are separate things to check.

DNS lookups commonly use port 53, but a single port in the logs does not reveal the entire resolution path. Encrypted DNS and standard DNS use different transport methods. If your existing configuration has explicit DNS settings, note their original values before making changes. Don’t replace all DNS settings just to troubleshoot one domain.

Settings in the file are expressed differently from toggles in Settings. For example, Settings → On Demand controls when a connection is triggered; it does not change a domain’s policy to DIRECT. During troubleshooting, note the original On Demand state. Otherwise, a connection triggered again after you disconnect manually might make it seem as though your configuration change wasn’t saved.

3. Rule: Match criteria, order, and FINAL

Rules in [Rule] are checked in order. The policy specified by the first matching rule is applied. For that reason, put specific exceptions before broader matching conditions. Adding an exception after FINAL will not override the catch-all result above it.

DIRECT means a direct connection, PROXY applies a proxy policy, and REJECT blocks the request. PROXY does not include a server address, credentials, or a connection service. This guide assumes you already have a service provider and subscription. Before using the example, make sure Home has a working connection entry.

no-resolve prevents a domain lookup solely for matching that IP rule. It does not disable all DNS or make a domain resolve automatically. GEOIP relies on an IP database; it does not determine location from a webpage’s language, a domain suffix, or the user’s location.

Proxy, Direct, Config, and Scene in Global Routing are different routing modes. Config routes traffic according to configuration rules; with Scene, you also need to check the settings for the selected scene. Note the current mode so you can reproduce rule-related issues.

4. Host: Local domain mappings are not routing policies

In [Host], use domain = IP address to create a local mapping. The line below maps lab.example.com to a documentation-only address. It maps a domain to an address; it does not also specify whether the request uses DIRECT or PROXY.

[Host]
lab.example.com = 192.0.2.10

• Enter the domain on the left, without https://, a path, or query parameters.
• The address on the right must come from an environment you manage or are authorized to use. The example address cannot be used for real connectivity tests.
• This line does not specify a server port. HTTPS uses port 443 by default; specify other ports in the request URL or the app’s connection settings.
• HTTPS still verifies the domain against the certificate. Mapping the domain to a different IP does not make the certificate match.

If the old address is still used after you change Host, close the existing webpage and make a new request. Browser and app caches, as well as existing connections, can affect what you observe. Check the destination domain and address in the request log instead of judging only by whether the page changed.

Some apps use their own DNS resolution or connect directly to a preset IP, so they may not use this mapping as expected. First check whether the app is actually requesting a domain or an IP address. Don’t try to fix an unverified DNS issue by adding increasingly broad Rules.

5. URL Rewrite: Rewrite URLs by pattern, not route traffic by domain

[URL Rewrite] uses a different field structure from [Rule]. The example below contains a match expression, a destination URL, and 302. It describes an HTTP redirect: when the specified old URL matches, the client is sent to the new URL. It is not a PROXY policy and does not configure server connection settings.

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

1. ^ anchors the match to the start of the string, preventing URLs with similar text elsewhere from matching.
2. \. represents a literal dot in a domain name. An unescaped dot in a regular expression matches a wider range of characters.
3. /old$ matches only the specified path at the end of the URL, so URLs with additional query parameters won't match.
4. https://example.com/new is the redirect destination. The next request still needs to resolve normally, match a routing rule, and establish a connection.
5. 302 indicates a temporary redirect. When testing, check the redirect chain rather than only the final URL shown in the address bar.

This example deliberately matches a plain HTTP URL. The path and query parameters of an HTTPS request are encrypted, so this example should not be taken to mean that any HTTPS page can be rewritten. Rewriting HTTPS requests requires additional MITM conditions and trust settings; adding a URL Rewrite line alone is not enough. Setting up those conditions is outside the scope of this introductory editing guide.

To avoid redirect loops, make sure the destination URL does not match the same rule again. For your first test, use a single, controlled URL and keep the match precise. Once you’ve confirmed the result, decide whether to broaden the match. Don’t start with a regular expression that matches every domain.

6. Import and edit in Config: Test one change at a time

Home is mainly for connections and routing modes, Config is for managing configuration files, and Settings is for app preferences. Having a connection entry or subscription does not mean a .conf file is selected. Importing a file does not automatically make it the active configuration either. After editing, return to Config and check which file is selected.

1. Save a copy. Before editing, save a copy of the current working configuration. Note the file name, the Global Routing mode, and the specific line you plan to change.
2. Prepare your file. Import a .conf file you own, or use a configuration URL you trust. Remote text can change DNS, routing, and rewrite behavior, so review it before importing.
3. Open Config. Use the add option to choose how to import the file or URL. After importing, check the file name and make sure it contains the section headers you expect.
4. Open the editor. Use the configuration’s action menu to open the text editor. Change one setting or rule at a time, then save. The exact location of the edit option depends on the current interface.
5. Select the configuration. In Config, select the saved file, then go to Home → Global Routing and confirm Config is selected. Reconnect before testing if needed.
6. Reproduce the request. Visit the same destination again and check the matching rule, policy, and destination address in the request log. If it fails, revert only the item you just changed, then test again.

Updating a remote configuration and updating a connection subscription are separate operations. The former may replace the contents of a .conf file; the latter mainly refreshes connection entries in an existing subscription. If you make custom changes directly to a file that gets overwritten by remote updates, those changes may be lost. Keep a separate copy and compare key sections before and after updating.

To verify a configuration, check all four: the saved file, the currently selected file, the Global Routing mode, and a newly initiated request. Seeing a save confirmation alone does not prove that requests are using the new rules.

7. Common questions about editing configuration files