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

At a glance

.conf is a configuration text file, not another name for a server subscription. This guide is for users who already have their own subscription and want to read or edit a Config. The steps use the iPhone / iPad interface; Mac, Windows, Android, and Linux users can check the equivalent settings in their version. Learn to distinguish global settings, routing rules, local mappings, and request rewrites, then verify changes by backing up, editing one item, reconnecting, and checking the logs.

1. Know the Difference Between Config, Servers, and Global Routing

In Shadowrocket, Home is where you view and select existing servers, while Config is where you manage configuration files. A server entry stores the address, port, protocol, and authentication details needed to connect. The four sections covered here define how requests are resolved, routed, and rewritten. Importing a .conf file containing these sections does not create a usable server or replace a subscription you already have.

Before editing, check Home → Global Routing. Proxy, Direct, Config, and Scene are routing modes, not server protocols. To test the [Rule] section in this guide, select Config. Results from a global Proxy or Direct mode do not show whether a particular rule matched.

Mode	What to check	How it relates to this guide
Proxy	Global proxy routing	You can't use this mode to determine how [Rule] routes traffic.
Direct	Global direct routing	Whether a server is available is not what this mode directly tests.
Config	The currently active configuration file	Use this mode to verify the rule order and policies described here.
Scene	Scene conditions and their associated settings	Check which routing mode and configuration the Scene actually uses; don't assume it's the same as a fixed Config.

Back up the configSelect a fileEdit one itemReconnectCheck the logs

This sequence describes the editing and verification workflow, not the order in which network processing happens. DNS resolution, domain matching, and IP matching can affect one another during a connection; [URL Rewrite] is not a step that every request passes through. Settings → On Demand controls conditional connections and does not replace routing rules in Config.

2. .conf Syntax and a Safe Editing Workflow

Put each section name on its own line and enclose it in English square brackets. Parameters typically use an English equals sign, and rule fields typically use English commas. Don't use commas or brackets from a non-English keyboard layout. The example below shows the file structure; omitting unused sections does not mean the configuration is broken. It illustrates text layout only and contains no server credentials.

[General]
dns-server = system

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT

[Host]
lab.example.com = 192.0.2.10

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

Open Config and keep a copy of the working file. If the file comes from a remote configuration, also record its original URL and your local changes.
Open the editor for the file you want to change. Make sure it's the same file you intend to edit and enable. The edit button may be in a different place on each platform.
Change one type of setting at a time. For example, edit one DOMAIN-SUFFIX rule without also changing DNS, adding a mapping, or modifying rewrite rules.
After saving, confirm that the file is enabled. Go to Home, check that Global Routing is set to Config, reconnect, and make a new test request.

Put comments on their own line, such as a note about a rule's purpose beginning with #. Don't append explanatory text to a parameter value unless you've confirmed that inline comments are supported there. Keep the .conf file extension; some text editors may otherwise append .txt.

3. [General]: Global Settings and DNS Resolution

[General] contains global settings for the configuration. The example dns-server = system uses the system DNS settings; it does not set a server named system. This doesn't guarantee that DNS resolution will work on your current network. If a connection fails, determine whether the cause is a DNS resolution failure, a routing issue, or an unresponsive destination.

[General]
dns-server = system

Don't copy another user's entire list of settings just because it looks familiar. IPv6, DNS, and bypass settings affect different parts of network behavior. For example, changing DNS won't fix incorrect server authentication, and disabling a type of address resolution won't explain every timeout. Keep settings that already work and change one item at a time to address a specific symptom.

[General] checklist

Section: [General]
Setting: dns-server = system
What to verify: DNS results and error logs for a new request

First confirm that resolution succeeds, then check how the connection is routed.

[Rule] checklist

Section: [Rule]
Match: DOMAIN-SUFFIX,example.com,PROXY
Fallback: FINAL,DIRECT

Rules select a policy; they don't provide server authentication details.

Test with a new connection. Existing long-lived connections may retain their original connection state, and the browser or system may cache DNS results. Refreshing a page once doesn't prove that new DNS settings took effect or that saving failed.

4. [Rule]: Match from Top to Bottom and Put FINAL Last

[Rule] checks rules in order. Once a rule matches, later rules generally aren't considered when choosing a policy for that connection. Put specific exceptions before broader rules. In the example below, an exact domain goes direct first; other requests under the same domain suffix use PROXY.

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

DOMAIN matches an exact domain. In this example, status.example.com matches DIRECT first.
DOMAIN-SUFFIX matches example.com and its subdomains. There's no need to write *.example.com, and you shouldn't enter a full URL.
IP-CIDR matches an IP address within a network range. 192.168.50.0/24 is a private network range, not a match for every local network.
no-resolve prevents this IP rule from triggering a DNS lookup just to match it. It is not a setting to turn off DNS for the entire configuration.
GEOIP,CN,DIRECT matches based on the target IP's country database entry, not the page language or domain suffix.
FINAL,PROXY handles connections that didn't match any earlier rule. If you put it first, ordinary rules below it won't get a chance to match.

PROXY and DIRECT are policy keywords, not protocol names. Shadowsocks, VMess, VLESS, Trojan, Hysteria2, and WireGuard describe server connection methods; they can't be used as policies at the end of a rule. If you use a custom policy name, make sure it's defined in the configuration and spelled exactly the same way.

Takeaway: Test an Exact Domain Before Widening the Match

In a copy of the file, add a DOMAIN rule for a test domain you manage and place it before FINAL. Reconnect and check the match log for a new request. Once the result is correct, change the rule to DOMAIN-SUFFIX. This helps distinguish a syntax error from a match that's too broad.

5. [Host]: Domain Mapping Is Not a Routing Policy

[Host] sets up local domain mappings. Put the domain on the left and the address to use on the right. Don't paste in the protocol, port, or path from the browser's address bar. A mapping changes address resolution; it doesn't automatically route the connection DIRECT or fix the destination site's certificate.

[Host]
lab.example.com = 192.0.2.10
api.example.com = 192.0.2.20

Entry or symptom	Issue	What to do
`https://lab.example.com/path`	Using a URL as the domain key.	Keep only `lab.example.com` on the left.
`192.0.2.10:443`	Adding a port to the mapped IP address.	Enter only the address in the mapping. HTTPS port 443 is part of the connection destination.
A certificate error appears after adding a mapping	The service at that address may not have a valid certificate for the mapped domain.	Check the server certificate and domain. Don't hide a mapping issue by ignoring certificate errors.
Traffic still goes through a proxy	An address mapping does not select DIRECT.	Check which policy [Rule] applies to the domain or destination address.

For example, after mapping a test domain you manage to an internal server, make sure the current network or selected proxy can reach that address. If the service is available only on your local network, check the relevant direct-routing rule separately. A correct mapping, reachable address, open port, and valid certificate are four independent requirements; checking just one isn't enough.

6. [URL Rewrite]: Regex Matching and Redirects

[URL Rewrite] applies to request URLs; it's not a tool for updating server subscriptions. The rule below matches only plain HTTP URLs on example.com, keeps the path, and redirects to the HTTPS URL with a 302 response. It changes how the request URL is handled; it doesn't select PROXY or DIRECT in [Rule].

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

^ anchors the match at the start of the URL, and $ anchors it at the end, reducing the chance of matching other URLs by accident.
In example\.com, the dot is escaped and matches a literal period. An unescaped dot in a regex usually matches any single character.
(.*) captures everything after the slash. The replacement URL's $1 refers to that captured text.
302 is a redirect status code, not a port number. Don't change it to the server's port 443.

Test with a service you control. For example, check an HTTP request with a path and query parameters, then verify that the redirect's Location preserves the expected content. A browser may automatically upgrade to HTTPS or use HSTS, so the request may never be sent over HTTP. Seeing HTTPS in the browser alone doesn't prove the rule worked.

Common mistakes include matching too broadly, redirecting to a URL that matches the same rule again, and putting the rule in the [Rule] section. If redirects repeat, disable the new rewrite first and restore the original request, then narrow the regex. Don't add several redirects to try to fix the same loop.

7. Changes Don't Take Effect: Check the File, Mode, and Match Conditions

First confirm which file is active, then check whether the request meets the conditions you're testing. Updating a server subscription is different from updating a remote configuration: the former mainly affects existing server entries, while the latter may replace configuration text. If you've made local changes to a remote configuration, keep a copy before updating so you don't mistake overwritten changes for a failed save.

I saved a rule. Why are all websites still using the same policy?

In Config, confirm that the file you just saved is enabled. Then go to Home → Global Routing and select Config. Check that FINAL is last, close any existing test connections, make a new request, and inspect the match log.

I added [Host]. Why won't the website load?

First compare the mapping value character by character with the actual address of your server. Then check whether the network can reach the destination address and port. For HTTPS on port 443, also check the site's certificate. The 192.0.2.10 address in this guide is for syntax examples only, not an actual service.

Why didn't a subscription update add any new rules?

Check the server list on Home, then inspect the rules file in Config. Updating a server subscription does not update the configuration file. To change [Rule], edit the active configuration instead of pasting rules into the server address field.

Why does it reconnect automatically after I disconnect?

Check the current conditions under Settings → On Demand. For a manual comparison test, you can temporarily pause the relevant automatic connection conditions and restore them after testing. On Demand controls when a connection starts; it doesn't change the order of [Rule] entries.

If you still can't identify the issue, restore the backup and keep the server, network, and test destination the same. If the backup works but the edited version doesn't, add changes back one at a time. If both fail, check the server connection and destination service before broadening rules. Before sharing diagnostic information, remove tokens from subscription URLs, authentication details, and other personal data.

Unsure about global settings? Restore the original [General] values first.
Traffic takes an unexpected route? Check Global Routing, the active file, rule order, and policy names.
One domain won't resolve? Check [Host], the DNS cache, and the results from a new connection.
Requests keep redirecting? Disable the new [URL Rewrite] rules, restore them one at a time, and test each change.