Shadowrocket Configuration File Explained: What [General], [Rule], [Host], and [URL Rewrite] Do

Understand .conf sections and processing order first

A Shadowrocket .conf file is not a script that runs from the first line to the last. It is a declarative configuration divided into bracketed sections. The section name determines which processing module handles the following lines: [General] stores common parameters, while [Rule] stores routing rules. Blank lines are generally for readability, and comments at the start of a line are explanatory only; they do not participate in matching.

When reading a configuration, first confirm the section names, then check the delimiter used on each line, and finally look for ordering dependencies within the same section. A missing closing bracket, a Chinese comma, or a misspelled policy name can invalidate a line. After editing, return to Config, select the configuration again, and verify it with a real domain request rather than checking only whether the file imports.

The four core sections do not all operate at the same stage. [Host] affects which address a domain resolves to, [Rule] determines the policy used for a request, and [URL Rewrite] redirects or rejects recognizable URLs. Mixing these functions into one section will not produce the expected result, even when each individual line looks correct.

[General]: DNS, bypass, and basic behavior

[General] is the common-parameter section of the configuration. Its entries can affect DNS resolution, system bypass behavior, local network address handling, and other basic options. It is not a routing-rule list, so DOMAIN-SUFFIX and FINAL do not belong here. Configurations from different sources may contain different entries; when checking one, use the fields that Shadowrocket can currently import and export as the reference.

dns-server specifies the DNS resolver entry used by the configuration. Setting it to system uses the DNS settings available from the system. When entering an explicit address, first confirm that it is reachable on the current network. DNS converts a domain into an address, but it does not determine whether the final connection uses PROXY or DIRECT; that policy is determined jointly by Global Routing and [Rule].

[General]
bypass-system = true
dns-server = system
ipv6 = false
skip-proxy = 127.0.0.1, localhost, *.local, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16

bypass-system controls whether system-related bypass handling is used, while skip-proxy explicitly lists hosts or address ranges that should not be sent through the proxy. The example includes a loopback address, .local names, and three common private address ranges. It illustrates the syntax and is not a universal template. Corporate networks, home storage devices, and printers may use different subnets, so check the device's current local address before making changes.

ipv6 = false is an example of explicitly disabling IPv6 behavior in this configuration, but it should not be treated as a universal fix. If the current network, existing service configuration, and target site all support IPv6 normally, disabling it may instead change the resolution result. During troubleshooting, change one item at a time and record the DNS results and access behavior before and after each change.

[Rule]: Top-to-bottom matching and FINAL fallback

[Rule] is the section most affected by ordering. When Global Routing is set to Config, Shadowrocket checks requests from top to bottom in the order shown in the configuration. Once the first applicable rule matches, its trailing policy is used and later, “more specific” rules are not considered. For this reason, specific domains generally belong before broad suffix or regional rules.

Common rules use English commas as separators. DOMAIN matches a full domain, DOMAIN-SUFFIX matches a domain suffix, IP-CIDR matches an address range, GEOIP matches based on the region associated with an address, and FINAL handles requests not matched earlier. Policies are typically written as PROXY, DIRECT, or REJECT.

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

In the example, the first line gives api.example.com priority and sends it through DIRECT. If the second line comes first, the full domain matches DOMAIN-SUFFIX,example.com before the exception can run. no-resolve prevents that IP rule from triggering an additional domain lookup solely for matching, which is useful when the rule only needs to inspect the destination address.

Global Routing changes whether rules participate in the decision. Config uses the rules in the current configuration; Proxy forces the proxy policy; Direct connects directly; Scene determines the behavior from the configured scene conditions. When testing a single rule, first confirm that the mode is not still Proxy or Direct, or changes to [Rule] will not produce the expected difference.

1. In Home, confirm that the server configuration you want to test is selected.
2. Switch Global Routing to Config.
3. In Config, confirm that the target .conf file is selected.
4. Move the specific rule being tested above broader rules.
5. Send the request again and check whether the matched policy is as expected.
6. Finally, confirm that FINAL is at the end of the rule section.

[Host]: Fixed domain mappings, not routing rules

[Host] maps specified domains to explicit addresses. Think of it as an override for domain resolution within the configuration. It answers “Which address should this domain resolve to?” It does not decide whether the request uses PROXY, DIRECT, or REJECT. The final policy still needs to be handled by [Rule].

The format below uses documentation-only addresses. 192.0.2.0/24 and 2001:db8::/32 are reserved for examples and should not be treated as real service addresses. Use target addresses that you manage or have confirmed as available in the actual configuration.

[Host]
example.com = 192.0.2.10
api.example.com = 192.0.2.20
ipv6.example.com = 2001:db8::10

A common Host-mapping mistake is inconsistent domain levels. Writing only example.com does not automatically mean that api.example.com receives the same mapping. To cover subdomains, confirm the matching syntax supported by the current configuration for each entry, then verify the actual resolution result rather than relying on visually similar domain names.

[URL Rewrite]: Redirects, rejection, and HTTPS visibility

[URL Rewrite] changes the result of a request based on a URL matching expression. Common uses include returning a 302 redirect or using reject to block matching requests. It handles URLs, while [Rule] primarily selects a policy by domain, address, or region; neither replaces the other.

Dots in expressions must be escaped, and path boundaries should be made as explicit as possible. An overly broad expression may match pages, APIs, and static assets at the same time, causing missing page elements or failed app requests. Start with one test domain and one path, confirm the result, and only then expand the scope.

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

The first line redirects an exact old address to a new address; the trailing 302 indicates a temporary redirect. The second line uses a hyphen as the replacement target and reject as the action. Fields are separated by spaces, and Chinese punctuation should not be added inside the regular expression.

The path of an HTTPS request is encrypted, so checking the connection by domain alone may not reveal the full URL. To inspect or rewrite an HTTPS path, complete the certificate and decryption-scope setup in Shadowrocket with explicit user authorization, and enable it only for test domains you have confirmed. Without the relevant scope configured, an HTTP example may work while an HTTPS example does not; this reflects encrypted-content visibility rather than necessarily an incorrect regular expression.

• Start by limiting the exact test address with the complete beginning anchor ^ and ending anchor $.
• Write the dot in a domain as \. to avoid matching any character.
• Test one rule first to rule out an earlier expression matching before it.
• If page resources are missing, temporarily disable the rewrite line added most recently and test again.
• For HTTPS, check only domains that have been confirmed and authorized.

A minimal complete configuration and post-import checks

When combining the four sections, start with a minimal configuration containing only a few test lines. Its purpose is not to cover every requirement, but to make each behavior traceable to one line: General controls DNS, Host controls address overrides, Rule controls routing, and URL Rewrite controls URL actions.

[General]
bypass-system = true
dns-server = system
skip-proxy = 127.0.0.1, localhost, *.local, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16

[Host]
test.example.com = 192.0.2.10

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

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

After importing, open Config and confirm that the configuration is selected, then return to Home and set Global Routing to Config. If you use a configuration subscription supplied by your existing service provider, check your local edits again after an update; a remote update may replace the previous content. To test a URL-form entry, use an obvious example such as https://example.com/sub?token=xxxx to understand field positions, but do not treat the example value as a usable service.

1. Keep the original .conf file and give the test file an easy-to-recognize name.
2. Check that every section name uses English square brackets and that no extra characters follow the section name.
3. Check that Rule lines use English commas and that the policy appears at the end of the line.
4. Confirm that specific rules come before broad rules and that FINAL is last.
5. Confirm that addresses in Host use the correct format and that domains contain no scheme prefix or path.
6. Confirm that the regular expression, replacement target, and action fields in URL Rewrite are all present.
7. Open Home to check Global Routing, then test resolution, routing, and rewriting separately.

If the configuration does not work correctly, do not change multiple sections at once. Temporarily keep [General] and one FINAL rule to confirm basic connectivity. Then add one DOMAIN test rule, add the Host mapping, and test URL Rewrite last. Restoring the sections in stages quickly identifies whether the error is in resolution, matching, or rewriting.

The final standard for checking a configuration

A configuration cannot be validated merely because the connection switch is on. Complete verification should cover at least four points: whether the domain resolves to the expected address, whether Global Routing is in the expected mode, whether the request matches the correct policy, and whether URL Rewrite affects only the target path. Each result should be traceable to a specific section and configuration line.

Shadowrocket is a closed-source commercial app for Apple platforms, primarily used on iPhone and iPad. Compatibility and system requirements for Mac, Apple TV, and Apple Vision are listed on the App Store page. The official source is the App Store; the developer is Shadow Launch Technology Limited, the app ID is 932747118, and the app is sold as a one-time purchase. Buying the client and using an existing service configuration are separate matters.