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

At a glance

This guide is for users who already have their own servers and subscriptions and want to read or edit a .conf file. First, check the active file in Config, then review its general settings, routing rules, domain mappings and URL rewrites. By the end, you’ll know where each change belongs and how to troubleshoot with minimal edits. The domain names and addresses shown are syntax examples only, not usable service configurations.

1. What is a .conf file, and how do you check which one is active?

A .conf file contains configuration text; it is not the server list on Home. Shadowrocket can use configuration files to manage rules and related settings, but a successful subscription update does not mean the active rule file has changed. Open Config to check which configuration is selected, then go to Home → Global Routing to confirm the mode. This tells you whether the file’s rules are being used for routing.

In Config, find the currently selected file and note its name. Before editing, save a copy of the original.
Open the file in the editor and identify sections by their bracketed headers. Don’t edit a line just because a search found a domain name.
Go to Home → Global Routing. Select Config to test the file’s rules; Proxy and Direct do not apply its individual rules to choose a route.
After saving, confirm that the edited file is still active, then test the same destination again. If the connection still appears to use its previous state, disconnect and reconnect before checking.

Section headers determine how the lines that follow are interpreted. After [General], you’ll typically see settings in key = value format; after [Rule], you’ll see comma-separated rules. The meaning changes at the next section header. Don’t put a DOMAIN-SUFFIX rule under [Host], and use standard square brackets for section headers.

[General]
dns-server = system

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

[Host]
lab.example.com = 192.0.2.10

2. What do [General] and [Host] control?

[General] manages basic behavior, while [Host] defines static domain-to-address mappings. If you’re troubleshooting name resolution, start by checking these sections in the active file in Config. Neither is a routing rule: adding a domain under [Host] doesn’t mean requests will use DIRECT, and changing DNS settings won’t automatically switch Global Routing to Config.

[General] checklist

Format: key = value
Example setting: dns-server = system
Purpose: Defines basic settings such as DNS
Where to check: Config → Current file → Editor

Check what the existing settings do, then adjust them one at a time. Don’t replace the whole section at once.

[Host] checklist

Format: Domain = IP address
Syntax example: lab.example.com = 192.0.2.10
Purpose: Maps a specified domain to a static address
Does not include: URL paths or service ports

Keep mappings up to date when destination addresses change. An outdated address can cause persistent connection failures.

dns-server = system means the system DNS is used; it does not specify an outbound policy for all requests. If your current file uses different DNS settings, note the original value first and compare resolution results before and after the change. Even when a domain resolves to an address, rules, the selected server and remote resolution behavior can still affect the request. A DNS response alone doesn’t mean the website will be reachable.

[Host] does not change HTTPS identity checks. For example, if you point lab.example.com to a test address you manage, the browser still connects using the original domain, so the server certificate must be valid for that domain. Even with the correct mapping, a certificate error, a port that isn’t listening or a server that isn’t configured for the site can still cause a failure. Don’t ignore certificate errors to hide a mapping problem.

Only one domain is affected: check for an outdated mapping under [Host], then review rules targeting that domain.
Many domains fail to resolve: check the DNS settings under [General] and compare them with the original file.
The domain resolves, but the connection times out: check the route and service port. HTTPS commonly uses port 443; successful resolution doesn’t mean the port is reachable.

3. How are [Rule] entries matched from top to bottom?

[Rule] entries are checked in order, and the first matching rule determines the policy. Go to Home → Global Routing → Config, then check the order of rules in the active file. The flow below describes rule-based routing only; it does not mean DNS, Host and URL Rewrite always run in one fixed sequence internally.

Identify the request Check each rule First match Apply the policy Fallback

[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

Keyword	What the example matches	What to check
`DOMAIN`	Matches only the exact domain api.example.com.	Place exact exceptions before rules with a broader scope.
`DOMAIN-SUFFIX`	Matches example.com and its subdomains.	Don’t include https://, a path or a port.
`IP-CIDR`	Matches addresses in the 192.0.2.0/24 range.	`no-resolve` avoids triggering an additional domain lookup for this rule.
`GEOIP`	Matches CN according to the IP geolocation database.	Based on IP data, not the website’s language or domain suffix.
`FINAL`	Handles requests that did not match any earlier rule.	Put it last to avoid matching requests before later rules can be checked.

Put exact exceptions before broader matches. In this example, api.example.com matches DOMAIN first and uses DIRECT; other requests matching the example.com suffix use PROXY. If you swap the first two rules, the exact domain will match the suffix rule first. PROXY here means a proxy policy; it does not create server settings. Confirm that a usable server is selected on Home.

no-resolve does not disable all DNS. It controls resolution behavior for the corresponding IP rule. Don’t assume a rule with no-resolve will match a domain request when the destination IP is not yet known. For a request made directly to an IP address, the existing address can be used for matching. When troubleshooting, distinguish between tests using a domain and tests using an IP address directly.

Takeaway: move specific exceptions first, then change the fallback policy

If a domain takes the wrong route, first check whether a broader rule above it matches. Move the specific rule ahead of that match. Don’t start by changing FINAL globally, or requests that match no other rule will also take a different route.

4. How is [URL Rewrite] different from domain routing?

[URL Rewrite] matches and rewrites URLs; it does not choose a proxy route. Check this section when you need to redirect a request from one URL to another. To route a domain through PROXY, edit [Rule]. The example below shows HTTP redirect syntax for a documentation-only domain; it is not a rule for everyday browsing.

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

^ and $ define the match boundaries; the backslash in example\.com treats the dot as a literal character.
(.*) captures the remaining text, and $1 in the destination URL refers to that captured group.
302 indicates a temporary redirect for subsequent requests; it is not a proxy server port.
The target matches only http://, so a target already using https:// won’t match this same rule again.

A VPN connection does not automatically expose the full HTTPS path. Rewriting an encrypted URL path or content typically involves the relevant MITM settings, host scope and certificate trust. Adding a URL Rewrite rule alone is not enough. This example uses an HTTP URL to explain the syntax; you don’t need to broaden certificate trust just to read the configuration.

When testing a rewrite, check the redirect chain—not just whether the final page opens. A browser may cache an old redirect, or an app may use HTTPS directly, making a rule appear ineffective. First confirm that the original request matches the regular expression, then check whether the expected 302 occurred. A page opening at the end doesn’t by itself prove this rewrite matched.

5. How to verify changes step by step

Change one variable at a time so you can connect the result to the configuration. Before testing, note the active file, Global Routing mode and selected server. If an existing subscription has just updated its server list, keep the test selection fixed so a server change isn’t mistaken for a rule change.

Establish a baseline: Keep a working copy of the original file. Before making changes, note whether the same destination opens normally, times out, fails to resolve or shows a certificate error.
Confirm the mode: Select Config under Home → Global Routing. If you use Scene, first verify which mode its conditions actually select; don’t assume the file’s rules are in use.
Make one change: For example, add just one exact DOMAIN rule. Save, confirm the file is still active, then send the request again.
Rule out an existing connection: An existing long-lived connection may continue using its original route. End the request, reconnect if needed, and try the same destination again.
Compare by reverting: If the problem appeared after the change, restore the original file and test again. If the problem remains, investigate the server, network and destination service rather than adding more rules.

Connectivity Test is only a connectivity clue; it does not replace testing the actual request. After running the test on Home, open the specific domain that’s having trouble. A successful test means its target was reachable under those conditions; it doesn’t confirm that DNS, Host mappings, rules and URL Rewrite are correct for every domain.

On Demand controls what triggers a connection, not which rule a request uses. If the connection changes automatically with network conditions, check its trigger settings under Settings → On Demand. If it’s enabled but a domain takes the wrong route, check Global Routing and Config instead. Don’t use the same toggle to troubleshoot both issues.

The original file works, but the new one doesn’t: first compare the sections you changed and the rule order.
DIRECT works, but PROXY doesn’t: check the selected server and whether it can reach the destination. Don’t assume DNS is misconfigured.
Only a specific domain is affected: check its exact-match rule, static mapping and rewrite conditions.
The configuration file is updated remotely: keep a local copy and check whether your manual changes were overwritten after an update.

6. Common questions about configuration files

I added rules to the file. Why does everything still use the same route?

On Home → Global Routing, first confirm the mode isn’t Proxy or Direct, then check which file is active in Config. Next, see whether a broader DOMAIN-SUFFIX rule appears above the rule for your destination, or whether FINAL was placed too early. After editing, start a new connection so you’re not reusing an existing session.

If I have a subscription, do I still need to check the .conf file?

Yes. An existing server subscription usually maintains server details, while the rule file handles a separate layer of configuration. After updating a subscription, check for server changes on Home, then confirm the active file in Config. A successful server list refresh doesn’t mean the rules have been updated.

Can I write lab.example.com:443 under [Host]?

Enter a domain-to-IP mapping here; don’t append a port to the domain. The request URL or connection settings determine the service port. If the destination uses HTTPS on port 443, check the address mapping, port 443 reachability and certificate domain separately rather than combining them into one Host entry.

Should I use FINAL,DIRECT or FINAL,PROXY?

Choose based on how you want requests that match no other rule to be handled. The first sends fallback requests directly; the second uses the proxy policy. In Config, review the domains and addresses covered by rules above FINAL before deciding what to do with the remaining traffic. Neither option replaces a complete rule plan.

Will removing [URL Rewrite] fix every website issue?

No. Keep the original file and temporarily remove only the rewrite related to the affected destination, then test again. If nothing changes, restore the original content and continue checking [Host], DNS and [Rule]. If the issue goes away, narrow the regular expression’s scope and check the redirect destination.