How to Read a Shadowrocket .conf File: General, Rule, Host, and URL Rewrite Explained

1. Understand .conf files, connection entries, and current status

A Shadowrocket .conf file organizes configuration behavior; it is not a connection account. Entries in Home store details such as the server address, port, and authentication. Files in Config control settings such as DNS, rules, local mappings, and URL rewrites. A Rule snippet alone does not provide a working connection service.

Before reading on, confirm which file is active and check the current selection under Home → Global Routing. Rule troubleshooting in this guide applies when Config is selected. Proxy and Direct are different global routing modes, so their results cannot by themselves confirm whether an individual rule is correct. Scene lets you select settings for specific situations; when troubleshooting, check the settings for the relevant scene rather than treating it as a separate fixed ruleset.

Square brackets mark the start of a section. The lines that follow belong to it until another section name appears. General commonly uses key-value pairs, while Rule entries typically use comma-separated fields; don’t interchange these formats. The steps below are a manual troubleshooting sequence, not a claim that every network request follows the four sections in the order they appear.

2. General: Check DNS first, then other global settings

In [General], the key name determines what a global option does; don’t look only at the value after the equals sign. If a domain won’t load, find dns-server first, then distinguish a DNS lookup failure from a successful lookup followed by a connection failure. The former calls for checking the resolution path; the latter may also involve routing, the destination port, or authentication settings in an existing connection entry.

[General]
dns-server = system

Here, system means using the DNS settings provided by the operating system. It is not a server address named system, nor does it mean requests will necessarily connect directly. The actual result can also depend on the current network, cache, and other DNS options. If the original file contains additional DNS settings, review them in context instead of drawing conclusions from this line alone.

1. In Config, open the file currently in use, note the existing value of dns-server, and keep a copy you can restore.
2. Reproduce the issue using the same test domain, and note whether you’re on Wi-Fi or cellular.
3. Change just one DNS setting, save, confirm the edited file is still active, and then start the request again.
4. If the issue persists, check separately whether the domain resolves to the expected IP, whether the expected Rule matches, and whether a connection to the destination is established.

3. Rule: Order specific matches first and keep FINAL last

[Rule] matches requests to policies. Rules are generally evaluated from top to bottom, and the first matching rule determines how a request is handled, so put specific rules before broader ones. The snippet below is for reading only: example.com is a sample domain, and PROXY depends on a valid connection you already have configured. This is not a complete, ready-to-use configuration.

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

DOMAIN-SUFFIX,example.com,PROXY matches example.com and its subdomains, such as www.example.com. It does not match any string that happens to contain the text. If a domain should use a specific policy, place this rule before broader checks such as GEOIP so another rule doesn’t match the request first.

IP-CIDR matches an IP address range; 192.168.0.0/16 in this example represents the corresponding private address range. no-resolve affects DNS resolution behavior for that rule only; it does not disable DNS throughout the app. GEOIP,CN,DIRECT uses location data for the destination IP and does not mean “send all Chinese-language websites direct.”

4. Host: Change name resolution, not connection policy

[Host] explicitly maps domain names to addresses. It answers “which address does this name resolve to?”; Rule answers “which policy should handle this request?” They are not interchangeable. Adding a mapping does not create a DIRECT rule, provide server software, make a route reachable, or supply a valid certificate.

[Host]
demo.example.com = 192.0.2.10

192.0.2.10 is a documentation example address, not a usable test service. In practice, create mappings only for targets you’re authorized to manage or whose addresses you know for certain. Don’t pin a public website to an arbitrary IP just to make it “seem to load”—address changes and distributed deployments can make a fixed mapping stop working.

• Mapping scope: This example lists only demo.example.com. Don’t assume other subdomains will get the same mapping.
• HTTPS validation: The requested hostname remains unchanged, so the destination service must provide a certificate valid for that name. Mapping an IP does not remove the certificate requirement.
• Troubleshooting: Remove or restore the mapping, reconnect, and compare the results to avoid drawing the wrong conclusion from a reused connection.
• Rule matching: Check which Rule actually matches the request. A mapped IP is not the same thing as the resulting policy.

5. URL Rewrite: Narrow the match, then verify the redirect

[URL Rewrite] matches request URLs against patterns and applies the specified action; it does not assign IP addresses to domains. The HTTP temporary redirect below illustrates three parts: the match expression, replacement target, and action. It’s a syntax example for reference, not something you need to add to a configuration you use every day.

[URL Rewrite]
^http://example\.com/old$ http://example.com/new 302

The ^ at the start and $ at the end of the expression anchor the entire match; \. represents a literal dot in a domain name. This example matches only http://example.com/old. It does not automatically cover HTTPS, other subdomains, or URLs with query parameters. The final 302 indicates a temporary redirect; whether the client follows it depends on how the requester handles redirects.

1. Write down a complete URL that should match, then one that shouldn’t—for example, http://example.com/older.
2. Limit the rule to a specific domain and path. Broad expressions can affect sign-in, payment, or API requests.
3. Check whether the replacement target also matches the original expression; if so, the rule may cause a redirect loop.
4. When testing, check the redirect status and destination URL—not just whether the page eventually appears.

6. Importing and updating: Keep connection sources separate from file sources

Updating a connection subscription and updating a .conf file are two separate tasks. This guide assumes you already have your own provider and subscription: a subscription can maintain connection entries in Home, while a configuration file maintains rules and other behavior in Config. A successful subscription update does not mean you’re using new Rules. Updating a remote configuration may also overwrite local edits made directly to the file.

1. Before importing: Note the selected entry in Home, keep a copy of the existing file in Config, and record the selection under Home → Global Routing.
2. Check the contents: Confirm the text actually contains configuration sections such as [General] and [Rule]; don’t judge by the file extension alone.
3. Use the file: In Config, confirm the imported file is selected and active. If you only save the file without switching the active configuration, you may still be testing the old rules.
4. After updating: Check that your custom Rule, Host, and URL Rewrite entries are still there, then repeat the same requests to the same targets.

Also check Settings → On Demand separately for automatic connection behavior. On Demand determines whether a connection starts under certain conditions; it does not replace Rule matching. If the connection resumes after you manually disconnect, check the trigger conditions rather than repeatedly deleting FINAL. To isolate variables, note the original settings, temporarily disable on-demand triggers, test a manual connection, and restore the settings afterward.

Before sharing a configuration, check every line, not just Rule. Subscription URL tokens, connection credentials, and certificate private keys should never appear in a public snippet. This site does not provide, sell, or recommend nodes or subscriptions; the domains, addresses, and rules in this guide are for illustrating formats and troubleshooting methods only.

7. Common questions: Find the section that matches the symptoms

For a reliable final check, keep the test target and network conditions consistent: use the same domain, request path, and Wi-Fi or cellular connection, and change one setting at a time. Troubleshooting is easier when you can explain which configuration was active, which rule matched, which address was resolved, and where the connection failed. Reimporting the entire file repeatedly is no substitute for checking each step.