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

1. How .conf files relate to Home, Config and Settings

A Shadowrocket .conf file is a text-based configuration organized by section names in square brackets. [General] typically contains global settings, [Rule] contains traffic-routing rules, [Host] contains domain mappings, and [URL Rewrite] contains rules for rewriting request URLs. These are the four sections covered here, not necessarily the only sections a config can contain.

Home is mainly for choosing an existing server and controlling the connection. Config is for managing and selecting configuration files, while Settings contains app-level options. Updating a service subscription and updating a remote config are separate actions: the former typically updates server details, while the latter updates configuration content. Before deciding whether a local change was overwritten, check which type of resource was updated.

2. [General]: Global settings and DNS basics

[General] uses the format key = value. DNS settings determine how domain lookups are handled; a successful server latency test alone does not confirm that DNS is working. A latency test only reflects its specific test path. Loading a webpage also depends on the target domain, the resolved address and the subsequent connection.

[General]
dns-server = system
ipv6 = false

dns-server = system uses the system DNS settings. It provides a useful baseline for comparison, but does not guarantee that DNS provided by the current network is available. If you need a specific resolver, use an address you have verified as reachable and trustworthy, and make sure it suits your network. Avoid piling on multiple settings from unknown sources.

ipv6 = false disables IPv6 support for this setting. The example provides a consistent test condition; it does not mean IPv6 should be disabled on every network, nor does it change the device's entire network stack. If your environment relies on IPv6, keep the existing value and assess the DNS records and actual connection results.

• Before making changes, note the existing dns-server value and keep a copy of the config that you can restore.
• Test the same domain and record separately whether it resolves and whether a connection is established. Do not treat the two types of failure as the same.
• Traditional DNS usually uses port 53. Reaching a DNS resolver and reaching a webpage on port 443 are separate checks.
• Do not change DNS, the server and the rules at the same time during testing; otherwise, you will not know which change made a difference.

3. [Rule]: Match order and the FINAL fallback

Rules in [Rule] are generally checked from top to bottom. When a rule matches, its policy is applied. Put more specific rules before broader ones, and place FINAL at the end to handle requests that did not match earlier rules. The examples below use reserved example domains and documentation addresses; they are not recommended destinations.

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

DOMAIN-SUFFIX,example.com,PROXY matches the domain and its subdomains; there is no need to write *.example.com. IP-CIDR matches based on the destination IP's network range. In the example, no-resolve means not to trigger an extra domain lookup for this IP rule. It does not actively resolve every domain and then check its network range.

GEOIP,CN,DIRECT matches using geographic data for the destination IP. It does not check a site's language, domain suffix or operator. Results depend on the database in use, so this rule cannot guarantee that a particular domain will use DIRECT. For predictable domain-based routing, add an explicit domain rule above it.

PROXY here does not include a server address, port or authentication details, and does not create a working service. Actual outbound connections still depend on the user's existing servers and current selection. If you encounter an unfamiliar policy name, first check whether it is defined elsewhere in the config; do not simply replace it with a protocol name.

4. [Host]: Local mappings are not routing rules

[Host] provides local mappings for specific domains. The simplest format maps a domain to an IP address, which is useful in a test environment with a known, fixed address. 192.0.2.10 below is a documentation example address and cannot be used to check whether a real site is reachable.

[Host]
lab.example.com = 192.0.2.10

This entry means “use the specified address for lab.example.com”; it does not mean “use DIRECT.” After resolving or mapping the destination address, the connection is still handled according to the applicable routing settings. To assign an outbound policy to this domain, add a separate rule under [Rule].

• Domain migration: If the server address changes, a fixed mapping may still point to the old IP. Check and update it as needed.
• HTTPS: A mapping does not change certificate validation requirements. The server certificate must still match the requested domain.
• App caching: Reconnect after changing a mapping. An existing connection may not perform another DNS lookup.
• Input format: Enter the domain on the left without https://, a path or a port.

Do not permanently pin an address from a single lookup for a site that uses dynamic routing. If the site relies on a CDN or assigns addresses based on the network, a stale mapping can bypass normal resolution and cause some resources to time out while others continue to work.

5. [URL Rewrite]: Match URLs and specify a rewrite action

[URL Rewrite] applies to request URLs; it does not select a proxy for outbound traffic. A rule typically includes a matching expression, a destination and an action. The example redirects an HTTP request for a test domain to HTTPS. The trailing 302 is an HTTP status code, not a port number.

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

The leading ^ and trailing $ limit the match. \. represents a literal period in a domain name, while (.*) captures the path and everything after it. $1 in the destination refers to the first captured group. If you write the period as ., regular-expression syntax treats it as any single character, which may match more than intended.

1. Start by testing the rule with an HTTP test address you control. Do not begin with a complex sign-in page.
2. Check whether a redirect occurs and whether the path and query parameters are preserved as expected.
3. Make sure the destination does not redirect back to the original address and create a redirect loop.
4. After verifying the rule, expand its match scope gradually. Keep the original rule so you can roll back.

6. Edit, select and verify a .conf file in Config

Before editing, keep a copy of the current working file. If it came from a remote config, save a local copy to experiment with so a future remote update does not overwrite your changes. Name the copy for your own reference, for example local-test.conf; its name does not determine whether it is active.

1. Open Config: Find the target file and use its file actions to open the text editor. The edit icon or entry point may change as the interface evolves; use the options currently shown.
2. Check section boundaries: Make sure each key-value pair is under the right section heading. Do not paste dns-server = system into [Rule], or write FINAL,PROXY as a General setting.
3. Save and select: Return to the Config file list and confirm that the active indicator is next to the file you just saved. Opening a file in the editor does not switch the active config.
4. Check the routing mode: Go to Home → Global Routing and select Config. Proxy and Direct are useful for comparing overall proxy and direct-connection behavior, but they do not confirm that the rules inside a file are working. Scene depends on the conditions configured for it.
5. Start a fresh test connection: If a brief disconnection is acceptable, reconnect and reopen the test page to avoid reusing an existing connection. Check the request log for the destination, policy and error details.

Settings → On Demand uses configured conditions to connect automatically. This is separate from selecting a .conf file. If the connection state changes on its own during troubleshooting, check the On Demand conditions too; do not assume an automatic reconnection was triggered by the config you just saved.

Record observable results so you can compare before and after. For example, suppose the same test domain resolved before a change but timed out on connection, and afterwards still resolved while its rule matched DIRECT. That only shows that matching and outbound behavior changed. To confirm access is restored, check that the page request completes rather than relying on the connection toggle alone.

7. Common config editing questions

After finishing your config, keep a verified working local copy and record the fields you changed and the test results. If a problem comes up later, return to this baseline and restore changes one at a time. This makes it easier to find the cause than replacing the entire config and server at once.