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

1. What a .conf file does: distinguish it from connection details

Shadowrocket’s .conf file is a text-based configuration file. Section names in square brackets determine which feature reads the content that follows. [General] commonly contains parameter assignments, [Rule] contains ordered rules, [Host] defines local hostname mappings, and [URL Rewrite] describes URL matching and handling. The syntax for one section cannot be used interchangeably with another.

Connection details listed in Home and the configuration file selected in Config are separate things. Updating a subscription usually syncs connection entries; editing a local .conf file changes how requests are handled. Updating a subscription does not necessarily replace the rules file currently in use. Likewise, importing a .conf file does not mean you already have usable connection details.

Before editing, check which file is selected in Config and keep a copy of the original. In Home, check Global Routing: select Config to test [Rule]. Proxy and Direct change global routing behavior, while Scene also involves scene settings. Don’t confuse these states with tests of individual matching rules in Config.

1. In Config, confirm which file is selected, not just that the file has been imported.
2. Open the file’s editor and make sure section names use straight square brackets.
3. In Home, confirm that connection entries are available, then set Global Routing to Config.
4. After saving your changes, establish a new test connection rather than reusing a long-lived connection from before the changes.

2. [General]: Global settings, not routing rules

[General] uses the format key = value. Each parameter’s scope depends on its definition; placing it at the top does not make it override every other section. For example, DNS parameters affect name resolution, while bypass parameters determine whether some traffic enters the processing flow. Neither can replace domain rules in [Rule].

[General]
dns-server = system
skip-proxy = 127.0.0.1, localhost

Here, dns-server = system means to use the system DNS settings; it does not specify a fixed server. 127.0.0.1 is the local loopback address. Adding it to skip-proxy serves a different purpose from sending a public website through DIRECT. This snippet shows two parameter formats; it is not a general-purpose network optimization recipe.

• Use one parameter assignment per line. Don’t append a DOMAIN-SUFFIX rule to a parameter value.
• Separate list items with standard commas. A full-width comma can cause the entire entry to be read incorrectly.
• Record the original value before changing DNS. If the new setting prevents domains from resolving, restore the original value before troubleshooting the rules.
• Keep only parameters with a known source and purpose. Don’t add multiple duplicate keys in an attempt to stack their effects.

Settings → On Demand controls when connections start or stop based on conditions; it is not another way to access [General]. If a connection comes back automatically during troubleshooting, check the On Demand triggers too. Don’t assume that automatic reconnection means the .conf file wasn’t saved.

3. [Rule]: Match from top to bottom; FINAL is the fallback

Rules in [Rule] are evaluated in order and typically consist of a type, a match value, and a policy. For requests that can be evaluated, the first matching rule determines the policy. A longer domain does not automatically take priority, and the last line does not override every rule above it. Put specific exceptions before broader rules.

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

In the example above, api.example.com matches DOMAIN first and uses PROXY. www.example.com can match the later DOMAIN-SUFFIX rule and use DIRECT. If the suffix rule comes before the exact-domain rule, it matches first and the exception for the API no longer takes effect.

no-resolve is an option for IP rules. It means no additional domain lookup is initiated for that rule. It does not disable DNS for the entire app, nor does it mean a domain request will necessarily match that IP range. Whether it applies depends on whether the request already has a destination IP.

PROXY and DIRECT describe policies, not protocols. The connection used by PROXY must also be available in your existing setup; changing FINAL to PROXY does not create a connection entry. Connection types such as Shadowsocks, VMess, VLESS, Trojan, Hysteria2, and WireGuard are a different layer from match types such as DOMAIN-SUFFIX and IP-CIDR.

4. [Host]: Map a hostname to an address; it doesn’t select an outbound policy

[Host] defines local hostname mappings. The example below maps a test domain to a documentation address: put the domain on the left and the IP address on the right. 192.0.2.10 is in a range reserved for documentation examples and should not be treated as an accessible production server.

[Host]
demo.example.test = 192.0.2.10

Host affects which resolution results may apply; entering a domain does not automatically make its traffic go direct. Whether a request uses DIRECT or PROXY still depends on Global Routing, the rules, and the actual outbound route. If the domain is resolved remotely, don’t assume a local mapping will determine the final destination address.

Host mappings don’t change the requirement for an HTTPS certificate to match the domain. Even if the domain resolves to the specified IP, a certificate error can still occur if the server does not have a valid certificate for that domain. Check the server’s domain configuration rather than blaming rule priority.

5. [URL Rewrite]: Check the regex, destination URL, and status code

A common [URL Rewrite] redirect uses a match expression, a destination URL, and a redirect status code, separated by whitespace. It operates on URLs, not simple domain matches. Periods, parentheses, and boundary markers in regular expressions all have specific meanings.

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

This rule matches URLs beginning with http://example.com/ and inserts the captured remainder into $1 in the destination URL. For example, http://example.com/docs?a=1 should redirect to https://example.com/docs?a=1. This illustrates the syntax; it is not a request to visit an external test page.

• ^ anchors the match at the start, so text within an unrelated URL isn’t mistaken for the target.
• \. matches a literal period; a plain . matches any single character.
• (.*) creates a capture group, and $1 refers to its contents.
• 302 indicates a temporary redirect. When debugging, keep in mind that the browser may have cached an earlier result.

Whether HTTPS URLs can be handled depends on whether encrypted traffic is decrypted with proper authorization and whether the required configuration is in place. Adding a URL Rewrite rule alone does not provide access to HTTPS paths or content. This guide uses an HTTP input to demonstrate the format; it does not require HTTPS decryption settings or a trusted certificate.

6. How to verify changes after saving: test each function separately

The order of sections in a configuration file does not represent the full request-processing order. Don’t read the four sections from top to bottom as a fixed pipeline. To verify a change, first confirm the selected file and global mode, then check resolution, rule matches, and URL behavior separately. Change only one factor per test.

1. Set a baseline: Keep a copy of a working configuration and note the test domain, network type, and Global Routing state.
2. Check the syntax: Verify the brackets, equals signs, standard commas, and spelling. Make sure each rule is in the correct section.
3. Verify the rule: In Config mode, create a new request to the target. Check the destination, policy, and matching rule against the app’s connection records. When records are available, use them as evidence instead of relying only on page load speed.
4. Verify the mapping: Use a domain you control with a correctly configured service, then confirm the actual destination address. Don’t use the documentation address in this article to test connectivity.
5. Verify the rewrite: Use an HTTP test endpoint you control. Check the destination URL and redirect count, and make sure old cached results aren’t masking the changes.
6. Roll back if something goes wrong: Restore the original configuration and reconnect. If it works again, reapply only the item you just changed.

Manage remote configurations separately from local files. If a remote update can overwrite the file you’re editing, save a separate copy and confirm that the copy is selected. Check subscription updates and remote configuration updates separately; a change to connection entries in Home alone does not mean the local rules have been replaced.

7. Common questions: Why doesn’t the result match expectations if the file saved?

At minimum, a useful troubleshooting record includes the selected configuration file, Global Routing state, the section and specific line changed, the test destination, and the observed result. Before sharing, remove subscription URLs, tokens, and connection credentials. The relevant rules and redacted destination details are usually enough to discuss matching behavior.