Shadowrocket .conf Configuration Guide: General, Rule, Host, and URL Rewrite Sections

1. .conf Section Names, Key-Value Pairs, and When Settings Take Effect

A configuration file is plain text. Names in square brackets identify sections, such as [General]. Everything up to the next section belongs to the current one. Preserve spaces in section names: don’t change [URL Rewrite] to a different spelling. Settings typically use the key = value format, while rules use comma-separated fields. These formats are not interchangeable.

Home manages connections and server selection; Config manages configuration files. Importing or saving text does not enable it. In Config, make sure the intended file is selected, then go to Home → Global Routing and choose Config. Proxy routes all traffic through the proxy, while Direct routes it directly. Scene selects a routing mode according to the configured scene. When checking rule order, keep routing set to Config so a scene change doesn’t affect the result.

The example below shows a standalone basic structure. Unmatched traffic goes to DIRECT, making it useful for checking whether the file parses correctly. It is not a ready-made configuration for every network. example.com is a documentation example domain, not a service provided by this site.

[General]
dns-server = system

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

• Edit the file as plain text and use standard ASCII punctuation. Don’t append explanatory text to a rule on the same line.
• Put each rule on its own line. For a note, start a new line with #.
• Keep a copy of the original file, then edit a separate test copy. Don’t change DNS, rules, and rewrites at the same time.
• Real-world configuration files may contain more sections; the four covered here are not a complete list of the app’s capabilities.

2. General: Basic Configuration, Not Rule Ordering

Use [General] for global settings. For example, dns-server = system uses the system DNS settings; it does not guarantee that the selected resolver is reachable on every network. Before changing this line to use another DNS method, note your current Wi-Fi or cellular network, the domain you’re testing, and what happens when the request fails.

DNS resolves domain names to IP addresses; Rule selects a traffic policy. They’re related, but they aren’t the same setting. If name resolution fails, adding a DOMAIN-SUFFIX rule won’t fix the resolver. Likewise, a DNS response doesn’t mean the destination port or proxy route is reachable.

When editing the file, don’t guess what a setting does based on its name. Unsupported or unverified keys may be ignored or cause parsing issues. To add General settings, refer to the corresponding options and descriptions in the app’s configuration editor, and keep a record of the original values. Check On Demand separately so automatic reconnections don’t interrupt troubleshooting.

3. Rule: Match from Top to Bottom, with FINAL Last

Each line in [Rule] defines a matching condition and an action. Rules are evaluated in order, and the action for the first match is applied. Put specific domain rules before broader rules, and place FINAL last. If a catch-all rule comes first, later rules won’t get the intended chance to match.

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

no-resolve prevents DNS lookup solely for matching this IP rule. It does not turn off all DNS: the request itself or other rules may still require name resolution. If a request has a domain name but no IP address to match against, an IP rule with no-resolve may not match. Check the actual request log.

PROXY and DIRECT are routing policies, not protocol names. Shadowsocks, VMess, VLESS, Trojan, Hysteria2, and WireGuard describe connection protocols; connection details still come from your own service. Setting a policy to PROXY won’t create a working connection. Before testing, make sure a usable server is configured in Home.

4. Host: Map Domains to Addresses, Not to Routing Policies

Use [Host] to map domain names to addresses. The basic syntax is domain = IP address. This changes the address associated with a domain; it doesn’t replace DIRECT or PROXY in Rule or make an unreachable address reachable.

[Host]
lab.example.com = 192.0.2.10

This snippet demonstrates the syntax only. 192.0.2.10 is a documentation-only address and cannot be used to test connectivity. In your own test environment, use a domain you control and an address that is actually reachable, and check which port the service listens on. A Host entry maps a name; don’t append a port like 192.0.2.10:443. HTTP commonly uses TCP port 80 and HTTPS TCP port 443; the port is determined by the URL or the app’s connection settings.

• Enter the domain as lab.example.com, not as https://lab.example.com/path.
• For HTTPS, the server certificate must still match the requested domain. Pinning an IP address does not bypass certificate validation.
• Close the existing connection and make a new request before testing, so a reused connection or cached response doesn’t hide the change.
• Remove the test mapping and check again to make sure a temporary address hasn’t been left in the production configuration.

If the address changes but the page still won’t load, check reachability, the service on the port, the certificate, and the routing policy separately. Host can help diagnose name resolution; it’s not a good idea to put arbitrary addresses found online in a long-term configuration.

5. URL Rewrite: Match a URL and Set a Redirect Action

[URL Rewrite] handles URL matching and rewriting. This example uses a regular expression to match an HTTP URL, then returns a redirect to the target with 302. It doesn’t create a DNS mapping or provide another way to route a domain through PROXY.

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

1. ^ anchors the match to the start of the URL, and $ anchors it to the end, so the expression doesn’t match only part of the address.
2. In example\.com, the dot is escaped to match a literal period, not any character in the regular expression.
3. (.*) captures everything after the slash; $1 in the target refers to the first capture group.
4. 302 specifies a redirect. The browser receives it and makes a separate request to the target; traffic isn’t passed directly between the two endpoints.

This expression matches only URLs starting with http://example.com/. It won’t match https://example.com/ or http://example.com:80/ with an explicit port. Document these boundaries before testing. Don’t loosen the domain match just to “match everything,” or unrelated requests may be rewritten.

If redirects loop, remove the new rewrite rule first and check the original site’s response. Even a one-way HTTP-to-HTTPS rule can interact with the server’s own redirects. Record the initial URL, response status, and redirect target separately instead of checking only whether the final page loads.

6. Test One Section at a Time: Separate Resolution, Routing, and Rewriting

The four sections cover basic behavior, traffic routing, hostname mapping, and URL handling. They aren’t four steps in a fixed pipeline. How a request is handled depends on factors such as whether it needs DNS resolution, whether the URL is visible, and whether a domain rule matches. The figures below describe this guide’s examples, not the app’s full support range.

1. Keep a copy of the original file in Config and make sure the test file is selected. On Home → Global Routing, set routing to Config.
2. Test General and Rule first, without other changes. Use a destination you know is reachable, and note the time, network type, and selected server.
3. Disconnect and reconnect, then make a new request. Distinguish DNS errors, connection timeouts, TLS errors, and HTTP status codes.
4. If you need Host, add just one mapping for a domain you control and compare the destination address before and after.
5. Test URL Rewrite separately at the end and check the redirect target. If it fails, undo the most recent change instead of replacing the whole configuration.

A successful server latency test only shows that the specific test received a response. It doesn’t prove that the target website’s DNS, TCP 443, TLS, and HTTP request are all working. An HTTP 403 means the server returned a response; check its access requirements rather than assuming the .conf syntax is at fault.

7. FAQ: Why Didn’t My Changes Take Effect After Saving the File?

After saving, check three things: the correct file is selected, Global Routing is set to the intended mode, and a new request matches the expected rule. Once these are confirmed, investigate DNS, the destination service, and rewrite boundaries. This helps avoid mistaking a connection problem for a file-format error.