Shadowrocket Config File Syntax: An Advanced Setup Guide

1. Start with the file structure

Shadowrocket is a paid Apple-platform app distributed through the App Store. Its developer is Shadow Launch Technology Limited, and its App Store app ID is 932747118. Buying the client does not include a service plan. This guide assumes you already have your own connection details; it does not provide or recommend servers or subscriptions. Check the App Store listing for current compatibility and system requirements.

A .conf file is a text-based configuration organized into named sections. A section heading appears on its own line inside square brackets, such as [General] or [Rule]. The lines below that heading belong to it until another section heading appears. This structure lets you keep general behavior, proxy definitions, routing rules, and other settings in separate places rather than combining unrelated values.

In Shadowrocket, open Config to manage configuration files. The precise available actions can depend on how a file was added and on the current app version. Before editing, preserve an unchanged copy so that you can compare it with your working version or restore it if a change causes unexpected routing. A file that imports successfully is not necessarily correct: the parser can accept the structure while a rule still points to an unavailable policy or matches the wrong traffic.

Use the exact section names and directives supported by the configuration format you are editing. A file written for another parser may use similar headings but differ in accepted options, rule behavior, or remote-resource syntax. If you are adapting a file supplied by your own provider, keep its required entries and check that provider’s documentation before renaming policies or removing sections. Treat an unfamiliar line as something to verify, not something to delete automatically.

2. Understand the roles of sections

[General] is where a configuration may define broad behavior and other global options. Keep changes here limited and deliberate: a global setting can affect many destinations, making it harder to identify the cause of a new problem. If you are changing DNS behavior, for example, first record the current setting and test the change separately from routing edits. Avoid copying options from an unrelated configuration just because their names appear familiar.

[Proxy] contains connection entries, while [Proxy Group] can present multiple entries under a policy name. Rules normally select a policy, not an arbitrary line from the file. For example, a rule ending in ,PROXY only makes sense if PROXY resolves to a usable policy in that configuration. If you rename a proxy group, search the file for every rule and group member that refers to its old name.

[Rule] is the section most users need to inspect when a particular domain takes an unexpected route. Rules are evaluated in order, so a broad match near the top can prevent a more specific rule beneath it from being reached. [Host] may define host mappings, and other sections can provide features such as URL rewriting or scripts. These features are distinct from routing: changing a host mapping does not automatically create a proxy rule.

The following excerpt shows the general shape of a rule section. The domains and policy names are placeholders. Confirm that each rule type and policy is supported by the file you are using before applying an example.

[Rule]
DOMAIN,api.example.com,PROXY
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY

• DOMAIN: targets the exact domain shown in that rule.
• DOMAIN-SUFFIX: matches a domain and qualifying subdomains. Put a narrower domain rule above a broader suffix rule when their outcomes differ.
• GEOIP: applies a network-location condition where that rule type is supported. It is not a substitute for a domain-specific exception.
• FINAL: acts as a fallback when no earlier rule matches. Choose its policy intentionally; it can affect a large share of traffic.

3. Edit and test a rule safely

Make one focused change at a time. Start with a destination you can identify, keep the original file, and record which policy you expect to be selected. A useful test is not simply “the page loaded”: it should establish which rule matched, which policy was selected, and whether the request completed. This makes it easier to distinguish a syntax problem from an unavailable connection or an incorrect routing decision.

1. Duplicate the file

   In Config, preserve the existing configuration and create or select a separate working copy using the actions available in the current app. Do not overwrite the only known-good file.

2. Choose one test

   Write down a domain you control or can safely use, the expected matching rule, and the policy you expect. Avoid changing several unrelated domains in one edit.

3. Place the rule

   Add the narrow rule above any broader rule that could also match. Check commas, the rule type, the domain, and the policy name. Keep the final fallback below the rules it is meant to back up.

4. Load the config

   Save the edited file, select it in Config, then use the app’s available validation or reload action. If it reports a parse issue, undo the last edit and inspect that line before changing other settings.

5. Check the request

   Connect with your own working server details, make the test request, and inspect the request log. Find the destination and note the matched rule or policy shown by the app. If the result differs from your expectation, check rule order and policy spelling before rewriting the whole file.

Request logs are evidence about a particular request, not a guarantee that all traffic follows the same path. A browser may reuse a connection, resolve a different hostname, or make additional requests to other domains. Repeat the test after clearing or restarting the relevant app session if needed, and compare the actual logged destination with the domain you intended to match. Do not publish logs containing account identifiers, private addresses, or other sensitive data.

4. Reference remote rule sets carefully

A remote rule set can keep a large collection of matching rules outside the main configuration, reducing repeated entries. Some configuration formats support a remote list directive such as RULE-SET; the exact spelling, argument order, accepted URL, policy field, and update behavior are parser-specific. Do not assume that every file accepts the same syntax. Check Shadowrocket’s current behavior and the documentation for the configuration source you are using.

A representative pattern, when supported, is shown below. This is a placeholder and does not identify a real list or service:

[Rule]
RULE-SET,https://rules.example.com/custom.list,PROXY
DOMAIN-SUFFIX,example.org,DIRECT
FINAL,PROXY

Before relying on a remote list, verify that you are authorized to use it, that its URL is correct, and that the response is a rule list rather than a login page or an HTML error page. A URL returning a successful web response does not prove that its contents can be parsed. Check whether the configuration expects a plain-text list, a particular rule syntax, or a particular policy name. If the request fails or the list is empty, the result may be an unreachable source, an unsupported format, or a policy mismatch.

• Keep a fallback: Retain a local test rule or another known working entry while confirming that the remote list loads.
• Check precedence: Place exceptions in an order that lets them take effect before broader rules or remote sets that would match first.
• Review updates: A remote list can change independently of your local file. When routing changes unexpectedly, compare the current list and update status with your earlier test.
• Use a stable source: If the list is maintained by your own provider or organization, ask its maintainer about supported syntax and update behavior rather than editing its URL by guesswork.

5. Treat MitM as a privacy-sensitive feature

MitM decryption is different from ordinary routing. It can allow eligible HTTPS traffic to be decrypted for features such as inspection or rewriting, which means it can expose the contents of requests and responses. Only consider it on a device and for applications and domains you own or are authorized to inspect. Do not enable it broadly as a routine way to fix connection problems, and do not assume that a certificate makes a connection safer.

Use the app’s current in-app instructions for certificate setup, because the available steps can change. On iOS, certificate trust settings can be reviewed under Settings → General → About → Certificate Trust Settings. Enabling full trust gives the certificate a consequential level of access on that device. Review which certificate is installed, why it is needed, and how to remove it when the test is finished. If the purpose or source of a certificate is unclear, do not trust it.

Keep any test narrow: use only the domains and apps needed for the authorized task, avoid sensitive services, and turn off the feature when you have collected the information you need. Check the resulting configuration for a limited host scope rather than a catch-all entry. Never share certificate private keys, account credentials, or unredacted request logs. If you do not specifically need decrypted traffic, leave MitM disabled and troubleshoot routing with request logs instead.

6. Advanced Config FAQ