Aug 3, 2026 · Config Files · About 10 min

Shadowrocket Config File Structure Explained: What Goes in [General], [Rule], [Host], and [URL Rewrite]

Learn what each .conf section does: [General] for global settings, [Rule] for routing order, [Host] for local mappings, and [URL Rewrite] for URL changes. Includes steps to import and edit files in Config.

At a glance

A Shadowrocket config file organizes settings, rules, and URL handling; it is not a server subscription. This guide is for users who already have service details and want to read or edit a .conf file. Identify the four sections, then import and edit the file in Config, select it, and verify the results in Global Routing and the connection log.

1. Understand the difference between config files, server details, and routing modes

.conf is a text-based config file. Section names appear in square brackets, followed by the settings for that section. Putting rules in [General] or DNS settings in [Rule] will not produce the intended configuration. When reading a file, identify the section first, then check each line’s syntax. Don’t search for a domain and edit it without checking the surrounding rules.

4 sections
This guide covers General, Rule, Host, and URL Rewrite
3 tabs
Home handles connections, Config handles config files, and Settings handles app settings
1 final rule
Put FINAL at the end of the rule list as a fallback

This guide assumes you already have your own service provider and subscription. Server details in Home describe the connection destination, port, and authentication method; a file in Config describes how requests are routed. Importing a config file does not fill in missing server details, and updating a server subscription does not update the currently selected config file.

2. [General]: Set global options as key-value pairs

[General] uses the format key = value. Use this section for global settings such as DNS, not for DOMAIN-SUFFIX rules. When troubleshooting, note the existing value and change one setting at a time. Changing DNS, rules, and the connection destination together makes it difficult to identify what caused the result.

[General]
dns-server = system

This example tells DNS to use the system-provided resolver. It is not a one-size-fits-all setting: if the current network has a DNS issue, keeping system will not fix it automatically. To specify another resolver, use an address you have confirmed works and enter it in a format supported by the app.

Check each parameter line

Section name
[General]
Parameter name
dns-server
Assignment operator
ASCII =
Example value in this guide
system

First confirm which section the parameter belongs in, then check that the value is valid for your network conditions.

Check each rule line

Section name
[Rule]
Rule type
DOMAIN-SUFFIX
Match target
example.com
Policy
PROXY

Rule fields are separated by commas; they do not use the equals sign used for parameter lines.

Don’t add every setting you find online just to make the config look complete. Keep only settings you can explain. Before changing behavior such as IPv6 or timeouts, check the in-app documentation and valid values for the relevant parameter instead of reusing numbers from an unknown source.

3. [Rule]: Rules are checked from top to bottom; put FINAL last

[Rule] determines which policy a request uses. Rules are checked in order, and the policy for the first matching rule applies. Put narrower exceptions before broader rules. The example below shows syntax only; replace example.com with a domain relevant to your needs.

[Rule]
DOMAIN,login.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,DIRECT
KeywordWhat this example matchesWhat to check
DOMAINExact match for login.example.comThis exception is evaluated before the domain-suffix rule below it.
DOMAIN-SUFFIXexample.com and its subdomainsDo not include a URL path, scheme, or port.
IP-CIDRThe 192.168.0.0/16 address rangeno-resolve prevents this IP rule from triggering a domain lookup just to evaluate the rule.
GEOIPAddresses classified as CN in the IP geolocation databaseUses the IP database, not the domain suffix.
FINALRequests that did not match any preceding rulePut this last; rules after it will not get a chance to match normally.

In this example, login.example.com matches the first line and uses DIRECT, while www.example.com matches the second line and uses PROXY. If you swap the first two lines, the suffix rule will match the login domain first, making the exception in the first line ineffective.

4. [Host]: Domain mappings are not proxy rules

[Host] maps a domain to a local address. It answers “Which address does this name resolve to?” while [Rule] answers “Which policy should this request use?” They serve different purposes. After adding a mapping, check which rule the request matches.

[Host]
device.example.com = 192.0.2.10

192.0.2.10 is a documentation example address, not a real device you can connect to. This example only shows the “domain equals address” format. Copying it will not make a website load. Use an address you have verified and confirm that it is reachable on your current network.

If you don’t need a specific mapping, you can leave this section out. If you add a temporary entry to troubleshoot an issue, remove it or restore the original value after testing. Otherwise, an outdated mapping may continue to point to an old address after the remote service changes.

5. [URL Rewrite]: Rewrite requests based on URL patterns

[URL Rewrite] defines URL matching and rewriting; it does not select a proxy policy. A typical entry includes a match expression, a destination URL, and an action. The example below redirects an HTTP URL, showing how to match the start of a string, escape the dot in a domain, and use 302 for a temporary redirect.

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

Choose the section that fits the goal; don’t mix up the two types of rules

To change the connection policy
  • Use [Rule].
  • For example, route example.com through PROXY.
  • Check the connection log to confirm the matching rule and policy.
To change the request URL
  • Use [URL Rewrite].
  • For example, redirect a matching HTTP URL to HTTPS.
  • Check the match expression, destination URL, and potential redirect loops.

“Which connection path to use” and “which URL to request” are separate questions. Verify them independently.

In the example, ^ anchors the match to the start of the string, and \. matches a literal dot. An overly broad expression can affect unrelated URLs. If the destination URL matches the original rule again, it can also cause a redirect loop. HTTPS requests are encrypted, so a rule alone cannot necessarily read and rewrite their paths. Whether additional settings are needed depends on the specific method. This guide does not cover HTTPS decryption settings.

6. Import, edit, and enable a file in Config

Keep a working copy of your existing file before importing or editing a duplicate. Use a remote config URL only if you have verified its source, and make sure it returns config text rather than a login page or web instructions. URLs containing tokens are sensitive; don’t include them in public screenshots or support requests.

  1. Keep the original

    Open Config, note the name of the currently selected file, and save a copy of its original text. If testing fails, restore the original file instead of layering changes onto an unknown state.

  2. Import a file

    In Config, tap “+” in the upper-right corner, enter a config URL you already have, then tap Download. After importing, check the file in the list and verify its contents. Don’t mistake a server subscription URL for a .conf URL.

  3. Edit the text

    In Config, tap the info button beside the file you want to edit, then open Edit Plain Text. Check the section names before editing line by line. If the interface uses localized labels, choose the corresponding text-editing option shown in your app.

  4. Select the config file

    After saving, return to Config, tap the target file, and confirm that it shows as selected. Go to Home → Global Routing and select Config. Saving the text alone does not switch another mode to Config.

  5. Test again

    Confirm that a connection destination is available in Home, then reconnect and test one target domain and one unrelated domain. Check the destination, policy, and matching rule in the connection log. If needed, restore the original file for comparison.

A remote config update may overwrite local edits. Save a separate copy of any rules you want to keep and compare the sections after an update. Before sharing a config file, remove server details, authentication information, and private addresses one by one; hiding only the filename is not enough.

7. Verify the result in Global Routing and the connection log

“Imported” and “currently routing traffic according to the file” are not the same state. To test the [Rule] examples in this guide, first confirm that Global Routing is set to Config. Other modes serve different purposes; results after temporarily switching modes do not prove that the rules in the file are active.

Config

Recommended

Use the rules in the current config file to determine the policy. Test the domain exception, suffix match, and FINAL fallback in this guide in this mode.

Best for: Reading, editing, and testing the routing rules in this guide.

Proxy

Route proxy-eligible traffic through the proxy path. Use this to check whether an existing connection destination works, not to test individual routing rules in this guide.

Best for: Temporarily isolating rule behavior while troubleshooting a proxy connection.

Direct

Use the direct connection path as a network comparison. A change in access after switching to this mode does not mean the domain rules in the original config are wrong.

Best for: Checking whether the current network can reach a destination directly.

Scene

Routing behavior is determined by the configured scene conditions. When troubleshooting, check both the scene conditions and the mode actually in use; don’t rely on the config file alone.

Best for: Situations where scene-switching conditions have been deliberately set and understood.

Test observable results rather than checking only whether the connection toggle is on. Browser cache, existing connections, and how an app makes requests can all affect the result. After making a change, send a new request and check the connection log. The table below suggests troubleshooting checks; it does not guarantee how every app will behave.

What you seeCheck firstWhat to do next
Rule saved, but the policy hasn’t changedIs the current file selected? Is Global Routing set to Config?Confirm the selection, reconnect, and check the log for a new request.
Only one specific domain failsEarlier DOMAIN, DOMAIN-SUFFIX, or REJECT rulesCheck the file in order to find the first matching rule.
Domain resolves to an old addressHost mappings, DNS cache, and existing connectionsRestore the mapping and compare using a new connection.
URL keeps redirectingURL Rewrite match scope and destination URLRemove the rewrite rule first, then restore and test rules one at a time.
Custom rules disappear after an updateWas a remote config with the same name updated?Restore the local copy and compare the text from before and after the update.

After checking, you should be able to identify the file in use, the rule matched by a request, and why that policy was applied. Once you can explain all three, you can add more complex rules. If you don’t need mappings or rewrites, leave those sections empty or omit them.

Verify Shadowrocket on the App Store