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

At a glance

When editing a .conf file, start by identifying each section’s role, then confirm which file is active in Config. General holds shared settings, Rule determines connection policies, Host defines static name mappings, and URL Rewrite handles matching URLs. This guide is for users who already have server details and need to read or maintain a config. The examples demonstrate syntax only; they contain no usable servers and are not a substitute for backing up your existing config.

1. Understand the structure: sections are not execution steps

A Shadowrocket .conf file is a text-based configuration file. Names in square brackets mark sections, such as [General]. Each following line belongs to that section until the next section name appears. Sections use different syntax: general settings and static mappings typically use an equals sign, while Rule entries use commas to separate the keyword, match condition, and policy.

This guide covers four sections, but a complete config is not limited to these. When reading an existing file, keep any sections you don’t recognize rather than deleting them to match the examples. The order of sections in the file also does not represent the order in which network requests are processed. For example, “Host appears after Rule” does not mean that traffic is necessarily routed before names are resolved.

4 sections

This guide covers General, Rule, Host, and URL Rewrite

3 commas

Field separators in the IP-CIDR example with no-resolve

1 FINAL rule

The final policy in this guide’s Rule example

[General]
dns-server = system

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

[Host]
lab.example.test = 192.0.2.10

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

example.com, example.test, and 192.0.2.0/24 are used here for documentation purposes. The address in the static mapping is not a server for real-world access. Don’t replace your everyday config with the entire example. Instead, validate the syntax section by section in a copy of your config.

2. General: shared settings are not routing rules

[General] stores general settings. This guide uses one easy-to-check option: dns-server = system. The parameter name is on the left of the equals sign, and its value is on the right. system means to use the system DNS. Don’t put this in [Rule] or use the comma-separated syntax reserved for rules.

[General]
dns-server = system

[General]: Marks the following lines as general settings.
dns-server: The DNS parameter being configured.
system: Use the DNS provided by the current system instead of specifying a fixed resolver address in the example.

DNS handles name resolution; it does not replace a server connection or determine by itself whether a connection uses PROXY or DIRECT. A domain name may resolve to an IP address even if the connection to the server still fails. Conversely, a successful server latency test does not guarantee that DNS can resolve the target domain. When troubleshooting, record resolution and connection results separately.

3. Rule: matches are evaluated from top to bottom; put FINAL last

[Rule] contains routing rules. After selecting Config in Home → Global Routing, check how the rules in the active config match. Proxy applies a global proxy policy, while Direct applies a global direct-connection policy; neither is suitable for testing the per-rule routing changes you just made. For Scene, first check the selected scene and its conditions. Don’t assume it works the same way as Config.

Match conditions

DOMAIN-SUFFIX: example.com,PROXY
IP-CIDR: 192.0.2.0/24,DIRECT,no-resolve
GEOIP: CN,DIRECT

These three rules match by domain suffix, IP range, and IP geolocation, respectively.

Policies and fallback

PROXY: Send the connection to the proxy policy; a working proxy outbound is still required.
DIRECT: Connect directly to the destination without forwarding through a proxy server.
FINAL: Use the specified policy when no earlier rule matches, for example, FINAL,PROXY.

REJECT denies matching connections; don’t mistake it for a direct-connection policy.

DOMAIN-SUFFIX,example.com,PROXY: Matches example.com and its subdomains, such as www.example.com. It does not perform a fuzzy match on any domain that happens to contain this text.
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve: Matches the specified IPv4 range. no-resolve means the app won’t trigger a DNS lookup just to evaluate this IP rule; it does not disable DNS for the entire app.
GEOIP,CN,DIRECT: Matches CN based on IP geolocation data. This checks IP data, not a domain suffix or a region label in server details.
FINAL,PROXY: Sends connections that did not match an earlier rule to PROXY. It has a policy field but no domain or network-range match condition.

Once a connection matches a rule, later rules are not used to select a different policy for it. Put specific exceptions before broader rules, and keep FINAL at the end. A connection already matched by an earlier rule will not be affected by an exception added at the bottom of the file.

Takeaway: check the routing mode before changing rule order

If a rule looks correct but doesn’t behave as expected, first confirm that Home → Global Routing is set to Config. Then check which file is active and which rule could match first. Don’t start by repeatedly adding the same domain rule.

4. Host: static name mappings don’t select a policy

[Host] maps a specified hostname to a specified address, for cases where you already know the destination address. It answers “Which address should this name resolve to?”—not “Which outbound should this connection use?” Even when an address comes from Host, the handling of the connection still depends on the current routing mode and relevant rules.

[Host]
lab.example.test = 192.0.2.10

lab.example.test is a fully qualified hostname. This entry does not define a wildcard mapping for subdomains.
= separates the hostname from the address; don’t replace it with the commas used in Rule entries.
192.0.2.10 is a documentation example address. For actual use, replace it with a destination address you have verified.

A static address can stop working if the destination service changes, especially when it uses dynamic routing. If something breaks, remove the mapping in a copy of your config and retry the connection to see whether it recovers. Don’t keep adding Host entries.

5. URL Rewrite: rewrites URLs; it doesn’t choose a proxy

[URL Rewrite] applies rewrite actions to URLs that meet specified conditions. Unlike Rule, which selects a connection policy, URL Rewrite acts on the request URL. Don’t put a domain-routing rule in this section or use a rewrite rule in place of proxy server settings.

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

Field	Example	Description
Match expression	`^http://example\.com/`	Matches URLs that begin with the specified HTTP address. The backslash before the period matches a literal period.
Target URL	`https://example.com/`	This example uses a fixed target address and does not demonstrate capturing and reinserting a path.
Action	`302`	Returns a temporary redirect so the client makes a follow-up request to the target URL.

This rule intentionally matches only plain HTTP. If the original URL includes a path or query parameters, this example won’t preserve them automatically because the target field does not reference any capture groups. To preserve the path, define the regex capture groups first and verify each result so login callbacks or query parameters aren’t lost after the redirect.

Don’t extend this example into a rule that assumes all HTTPS URLs can be rewritten by path. Visibility into HTTPS URLs involves additional requirements such as MITM, and depends on app behavior and certificate handling. This guide does not require enabling MITM or installing certificates; it only explains the structure of the fields in this section.

Test the match with one specific URL first; don’t start with an expression that covers every domain.
Make sure the target URL doesn’t match the same redirect condition, which could create a loop.
Browsers may automatically upgrade HTTP or use cached responses. If you don’t see a redirect, first confirm the address of the request that was actually sent.

6. Apply changes in Config: save the file, select it, and reconnect

Finishing an edit does not mean the current connection is using the new config. Config may contain multiple local files and remote configs, so verify which one is actually selected. If filenames are similar, give the test copy a distinctive name and keep the original as a rollback option.

Back up the originalEdit a copySave and selectCheck the routing modeTest again

Open Config, note the name of the currently active file, and keep a copy of the original. Open the file you plan to edit and confirm the section names and the lines you intend to change.
Make a small change to one section at a time. Save, return to Config, and confirm that the edits were retained. Then select the config you want to test.
Go to Home → Global Routing and select Config. If you use Scene, check which scene is selected first; you can switch to Config temporarily to isolate the test.
Confirm that a working server is selected in Home. PROXY is only a policy name; it does not create a server address, port, or authentication details.
If a brief network interruption is acceptable, turn the connection switch off and back on, then send the target request again. Existing long-lived connections may be reused, so don’t rely on a page that was already open before the change.
Check the request log for the target domain, destination IP, and policy result. If the behavior is unexpected, restore the original config and repeat the same test to see whether the change caused the difference.

Also distinguish server subscriptions from .conf configs: subscriptions are generally used to maintain server details, while .conf files hold rules and general settings. Updating a server subscription does not switch the active file in Config. Fetching a remote config again may also overwrite edits made directly to that file. Before maintaining configs long term, identify which file comes from a remote source and which is your local copy.

Takeaway: validate one reversible config change at a time

Record which line you changed, which file you selected, and which request you tested. Keep a change in your everyday config only when the same request produces an explainable difference before and after the change.

7. Common questions: find the relevant section by symptom

I changed Rule. Why does every site still use the same routing mode?

Go to Home → Global Routing and confirm that Config is selected, then check which file is active in Config. If behavior is still the same, look for an overly broad rule near the top of Rule and check whether FINAL appears too early. Test with a new request rather than refreshing an existing long-lived connection.

I added an address in Host. Why does HTTPS still fail?

Check that the address actually serves the target hostname, and verify that the certificate is valid for that domain. Host only changes the name mapping. Remove the line in a copy of your config for comparison; don’t loosen certificate validation to mask an incorrect address.

URL Rewrite saved successfully, but there’s no redirect. Why?

Check whether the actual request begins with the HTTP address shown in the example, then verify the backslash in the regex, the space-separated fields, and the final action. If the browser upgraded the request to HTTPS before sending it, this HTTP-only rule won’t match.

My manually edited rules disappeared after an update. What should I check?

First, confirm which file is selected in Config, then check whether the remote config was fetched again. Compare it with the local copy you saved beforehand and migrate only the changes you still need. Don’t treat a server subscription update and a config file update as the same operation.

Before making more changes, check the keywords against the rule reference, or use the settings guide to distinguish routing modes from other features. Settings → On Demand manages conditions for on-demand connections; it does not select a Config file or change the syntax of Rule entries.