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

At a glance

A Shadowrocket .conf file is a text configuration organized into sections, not a server subscription. To read one, identify the section names in brackets, then review the parameters, match conditions, and policies. When applying it, also check that Home → Global Routing is set to Config. This guide is for users who already have their own connection details and want to inspect or edit a configuration. It explains four common sections, with readable examples and ways to test each change individually.

1. Identify the sections: a .conf file is not a server list

A configuration file is divided by section names such as [General] and [Rule]. Entries after a section name belong to that section until the next section name appears. Square brackets, hyphens in keys, and commas in rules are part of the syntax; do not replace them with other punctuation. Keep the space in [URL Rewrite].

Server details tell you where to connect and which protocol and authentication settings to use. A configuration file mainly determines how traffic is resolved and routed, and whether requests are rewritten. Even if a file contains PROXY, that does not mean it includes a usable server. The examples below assume you already have your own service provider and subscription, and have selected a server in Home.

What each section does—and what it does not do
Section	What it handles	What it cannot replace
`[General]`	Global options such as DNS and IPv6	Routing rules for specific domains
`[Rule]`	Match conditions and policies for domains, destination IPs, and more	Server addresses and authentication details
`[Host]`	Local DNS mappings for specified domains	HTTP redirects or connection policies
`[URL Rewrite]`	URLs that can be matched and rewrite actions	Automatic decryption of all encrypted traffic

These snippets illustrate syntax; they are not complete configurations to use in place of an existing file. example.com is a sample domain, and 192.0.2.10 is in a documentation-only address range. Do not use it to test a real service. Keep a copy of your original file before editing, and avoid publicly sharing a complete configuration that contains private addresses, authentication details, or subscription credentials.

2. General: check global options before changing routing rules

The [General] section uses the format “key = value.” These examples show how to read three common options; they are not a recommended combination for every network. DNS and IPv6 settings in particular can affect resolution or address selection. A setting that works temporarily is not necessarily correct for every situation.

[General]
dns-server = system
ipv6 = false
bypass-system = true

General options

dns-server: system means use the system DNS.
ipv6: false disables IPv6 support in this configuration.
bypass-system: true means bypass some system traffic.

These options affect global behavior; they are not rules matched individually by domain.

Rule policies

PROXY: Route through a proxy policy; a working server must already be available.
DIRECT: Use a direct connection without forwarding through a proxy server.
REJECT: Reject matching requests.

Global options and rule policies serve different purposes. When troubleshooting, change only one at a time.

For example, if only one domain takes the wrong route, check [Rule] first rather than changing DNS. If several domains fail to resolve, check dns-server and your current network. Setting ipv6 = false does not change the device’s other network settings, so it does not mean every app on the device stops using IPv6.

3. Rule: matching runs top to bottom; put FINAL last

A typical [Rule] entry has the format “rule type, match value, policy.” FINAL takes a policy directly and does not need a match value. Rules are generally evaluated from top to bottom, with the first match taking effect. Put specific exceptions before broader rules, and place the fallback rule last.

[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

DOMAIN,api.example.com,DIRECT: matches only this exact domain, making it an exception to the suffix rule below.
DOMAIN-SUFFIX,example.com,PROXY: matches example.com and its subdomains. The suffix match respects domain boundaries; it does not match arbitrary strings containing that text.
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve: matches the specified IPv4 range. no-resolve prevents a DNS lookup solely to evaluate this rule.
GEOIP,CN,DIRECT: uses geographic data for the destination IP; it does not use the page language or domain suffix.
FINAL,PROXY: uses the proxy policy when no earlier rule matches. It does not guarantee that the request will succeed.

With these rules in this order, api.example.com matches the exact-domain rule first, while www.example.com matches the suffix rule. If you swap the first two rules, the broader suffix rule will take precedence over the exact-domain exception. This is a common reason a rule appears not to work even though it is present.

4. Host: change the resolved address, not the URL

The [Host] section can map a specified domain to an address. The line below means “resolve this domain to this address.” It does not redirect the browser to the IP address or directly set DIRECT or PROXY.

[Host]
lab.example.com = 192.0.2.10

After changing the resolved address, the browser’s address bar can still show lab.example.com. For HTTPS, the domain used in the request must still match the server’s certificate. Mapping a domain to an address that only serves other sites can result in a certificate error, the wrong site, or a failed connection—not the requested content.

Distinguish “which address to connect to” from “which route to use”

Host mapping

Check that the full domain is correct.
Check that the mapped IP still serves the intended service.
HTTPS still requires the domain and certificate to match.

Rule routing policy

Check the domain rule and its position in the list.
Check the IP rule and the resolved address.
Use DIRECT or PROXY to specify the connection policy.

Host and Rule can both be used, but a mapped address cannot replace a policy, and a policy cannot fix an incorrect mapping.

A local mapping explicitly overrides the usual resolution, so verify it again if the service address changes. If an issue begins only after adding a Host entry, remove that mapping, save, reconnect, and test the same domain again. Do not change DNS, rule order, and server settings at the same time; otherwise, you will not know which change resolved the issue.

5. URL Rewrite: read the pattern, target, and action together

The [URL Rewrite] section defines URL rewrite rules. This example redirects the root path of a specific HTTP domain to HTTPS; the final 302 indicates a temporary redirect. It illustrates the syntax and match scope—it is not a recommendation to apply the same rule to every website.

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

Pattern: ^ anchors the match at the start, and $ anchors it at the end. \. matches a literal period, so the dots in the domain are not treated as regex wildcards.
Target URL: https://example.com/ is the redirect destination. This example uses a fixed target and does not preserve other paths or query parameters.
Action: 302 is a redirect status code, not a server port or proxy protocol.

Because the pattern includes an end anchor, this rule will not match http://example.com/docs or a URL with a query string. Before broadening the match, decide whether paths and parameters need to be preserved. Sending every request to the same root path can break login callbacks, search results, or API calls.

6. Apply and verify: check the routing mode, then test one change at a time

A file being saved, selected, and used to route traffic are three different states. After editing, check the selected file in Config, then return to Home and verify Global Routing. The guidance below describes Shadowrocket’s own routing behavior for connections it handles; it is not an absolute guarantee about all network activity on the device.

Config

Recommended

Select a policy using the rules in the current configuration. The FINAL rule determines the destination for unmatched requests; there is no universal rule that “everything else goes direct.”

Best for: testing the Rule examples in this guide and routing traffic by rule in everyday use.

Proxy

Use the proxy as the global routing mode instead of following the per-rule routes in Config. Switching to this mode can help determine whether an issue is related to rule selection.

Best for: temporarily comparing the proxy route. Not suitable for testing DOMAIN-SUFFIX match order.

Direct

Use direct connections as the global routing mode. If a website loads in this mode, that does not prove a PROXY rule in the configuration is working.

Best for: comparing direct connections on the current network to distinguish proxy-routing issues from problems with the destination service.

Scene in Global Routing lets you configure routing behavior for specific scenarios; it is not simply another name for Config. When first reviewing a configuration, select Config explicitly. If Settings → On Demand is also enabled, check the automatic connection conditions so a reconnect is not mistaken for an effect of your file change.

Keep a backup

Open Config and save a copy of your current working configuration before editing the file you want to test. Do not replace the entire file with an example snippet.
Select the file

Save your changes in Config and check that the selected-file indicator points to the intended filename. For remote files, also check whether a later update could overwrite your local changes.
Check the routing mode

Go to Home → Global Routing, select Config, then check that the server selected in Home is one of your own working servers.
Reconnect

To rule out an existing connection, turn the connection switch off and back on in Home, then make a new request to the target. Do not just refresh a page that may reuse its existing connection.
Retest one change

First check the basic connection status with Home → Connectivity Test, then test the specific domain. Change only one rule or setting at a time and record the result.

A successful Connectivity Test does not replace end-to-end app testing: it does not prove that a URL Rewrite rule ran or that every resource on a particular site uses the same policy. Websites often request content from multiple domains. If the main page loads but images fail, check the relevant domains individually rather than adding a broad rule.

7. Troubleshooting: the file looks right, but traffic behaves differently

I added DIRECT. Why is the request still going through the proxy?

First check that Home → Global Routing is set to Config, then verify which configuration file is selected. Next, look for a broader DOMAIN-SUFFIX or other matching rule above the rule in question. Move the specific exception above the broader rule, save, start a new connection, and test again.

Will importing a subscription automatically replace the Rule section?

Updating a server subscription and updating a configuration file are separate operations. A changed server list in Home does not mean the rules file in Config has been updated. Check the server list and the selected configuration separately. If the configuration comes from a remote URL, save local changes before updating to avoid having them overwritten.

I added an IP under Host. Why am I getting an HTTPS error?

First check whether the IP serves the domain’s service and whether the server certificate covers that domain. Temporarily remove the Host entry, reconnect, and revisit the same address to compare. Disabling certificate verification is not a fix for an incorrect domain mapping.

Can I connect by adding only FINAL,PROXY?

No. FINAL specifies only the fallback policy; it does not provide a server address, port, or authentication details. Confirm that you already have your own server selected in Home, then run Connectivity Test. If the connection itself fails, adding more domain rules usually will not fix it.

Check these in order: current file, Global Routing mode, rule order, DNS and Host, then the result for the specific request. For more rule syntax, see the Rules reference. For routing modes, see Routing Modes. Keeping a copy of the file before each change makes it easier to revert and identify the cause than changing several groups of settings at once.