Shadowrocket Rules and Config Guide

1. Config Structure and Scope

Servers, subscriptions, and Config files serve different purposes

In Shadowrocket, server entries, subscriptions, and Config files each serve a different purpose. A server entry describes the address, port, authentication, and protocol settings needed to connect. A subscription helps maintain a user’s existing server entries in one place. A Config file organizes how requests are resolved, matched, and handled. These may all be part of the same workflow, but they are not interchangeable. Importing a server subscription does not tell you which Config is active; selecting a Config does not mean you have a usable server. When troubleshooting, separate these two layers to avoid changing settings unrelated to the problem.

A Config is usually organized as a series of text sections. A section begins with a heading in square brackets and continues until the next section heading. Common sections include [General] for general settings, [Rule] for ordered matching rules, [Host] for mapping hostnames to addresses, and [URL Rewrite] for rewriting visible request URLs. Section headings are syntax, not explanatory labels, so don’t translate them. Commas, equals signs, and parameter positions are also part of the syntax; use standard ASCII punctuation when editing.

Understand how the sections fit together

This snippet shows how general settings and rules are written in separate sections. dns-server = system means to use the system’s DNS settings; it does not promise faster resolution on every network. The two domain rules specify different routes, and the final rule handles requests that haven’t matched earlier rules. This is a structural example, not a complete Config to replace an existing file with. In particular, the actual connection target for PROXY depends on the server selected in the app; you can’t determine it from these lines alone.

[General]
dns-server = system

[Rule]
DOMAIN,service.example.com,PROXY
DOMAIN-SUFFIX,local.example.com,DIRECT
FINAL,PROXY

When reviewing a long Config, start by marking each section, then locate the final default rule, and work back through the domain and address rules. This establishes the file’s structure before you examine exceptions. Don’t start by copying a large section into another file: policy names, existing rules, and general settings may differ, and a syntactically valid snippet can still change request routing when merged. If you don’t recognize a setting, find out what it does before keeping or removing it.

Save changes and keep a recovery copy

Before editing in Config, make a copy of the current file and save it with a descriptive name. After editing, check that the changes were saved and confirm that the edited file is the one currently selected. Opening a file in the editor doesn’t make it the active Config. Also check Global Routing: having rules in a Config and having requests handled by those rules are two separate conditions. For your first setup, follow the quick-start steps to select a Config, then return here to check the syntax.

Remotely maintained Config files also have update considerations. If you add personal rules directly to a file that remote content can replace, an update may overwrite your changes. A safer approach is to keep a copy of the original, save a separate working copy, and note why you made each change. Subscription updates, Config updates, and app updates are separate: the first mainly concerns existing server entries, the second concerns rule text, and the app itself is obtained and updated through the App Store.

2. Global Routing and Connection Policies

Check the mode before interpreting rule results

Global Routing is the first setting to check when determining whether rules are being applied. The configuration mode is Config, the proxy mode is Proxy, and the direct mode is Direct. For routine rule troubleshooting, switch back to Config first, then inspect the file. If another mode is selected, editing domain rules alone may not produce the expected result. This section covers overall connection routing; it does not mean the app bypasses system restrictions or can see all system traffic in the same way.

Mode names and policy keywords in rules belong to different layers. Proxy is a mode in the interface, while PROXY is a policy value in a rule. The same distinction applies to Direct and DIRECT. The names look similar, but changing the mode is not the same as changing a rule’s policy. If the routes for many requests change at once, check the mode and selected Config before assuming that individual domain rules have stopped working.

What PROXY, DIRECT, and REJECT mean

PROXY sends a request through the proxy route, but it is not a server address. A successful connection still depends on the selected server, protocol settings, and network reachability. If a rule correctly matches PROXY but the request times out, that doesn’t prove the rule is wrong. Check that the server is available, supports the required transport, and has matching authentication settings. Blaming every failure on the rules can hide a problem at the connection stage.

DIRECT connects directly to the destination; it doesn’t bypass DNS resolution or guarantee that the destination is reachable. Local routing, firewalls, DNS results, and the destination’s status can all affect the outcome. REJECT blocks connections that match its conditions. After a request is rejected, it usually can’t complete; the app may show only a loading error rather than the rule name. Check the match log to confirm what happened.

[Rule]
DOMAIN,service.example.com,PROXY
DOMAIN,intranet.example.com,DIRECT
DOMAIN,blocked.example.com,REJECT
FINAL,PROXY

The three hostnames in this example are deliberately different so the scope of each policy is clear. In a real Config, don’t put a broad reject rule for an entire suffix before an allow rule for one hostname: once the first rule matches, the exception below it won’t run. Also, don’t use REJECT as a fallback route when a server fails. It blocks the request; it doesn’t find another connection path.

Selecting a server doesn’t send every request through it

In Config mode, both the selected server and the rule policy determine the result. A request that matches DIRECT goes direct even if a working server is selected. Conversely, setting the default policy to PROXY doesn’t override earlier direct or reject rules. The server name tells you which target would be used for proxy-routed traffic; on its own, it can’t explain why a particular request took a given route.

To compare proxy and direct connections, use the same test destination and record the mode, network type, and test time for each run. Restore Config when you’re done. Don’t change the server, DNS, and mode at the same time; if the result improves, you won’t know which change helped. If only the proxy route fails, see How to troubleshoot server timeouts and connection failures. If only one domain fails, focus again on its matching conditions and DNS results.

3. DOMAIN Rules and Domain Scope

DOMAIN: Match one exact hostname

DOMAIN matches an exact hostname. The condition should be a hostname, not a full URL, so don’t include the scheme, path, query parameters, or port. A URL can contain all of these parts, but a domain rule only matches its hostname. To handle a specific URL path, use another mechanism that supports it; appending a path to the hostname won’t make an exact domain rule understand the full URL.

The first rule below applies only to api.example.com; it won’t automatically match www.example.com just because both belong to the same organization. Exact rules are useful for a single service endpoint whose scope is known, and for exceptions placed above broader rules. Copying the hostname from a request log is more reliable than guessing from the page title: the displayed brand name may differ from the actual request domain, and static assets or authentication may use other hostnames.

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

DOMAIN-SUFFIX: Match a domain and its subdomains

Use DOMAIN-SUFFIX when a root domain and its subdomains should use the same policy. With example.com as the condition, it matches the root domain and its subdomains—not any hostname that merely contains those characters. Domain labels have clear boundaries, unlike keyword matches. You usually don’t need to add an asterisk before the condition. A wildcard convention from a browser or another syntax may not mean the same thing here.

Suffix rules save you from maintaining every subdomain individually, but they also cover a wider scope. If the same suffix includes an API that should use a proxy and a service available only on the local network, applying one policy to all of it may cause problems. Put narrower exceptions first, then add the suffix rule. In the example above, the login hostname matches DIRECT first; subsequent rules handle other requests under the same suffix. Rule order is part of the intended behavior.

DOMAIN-KEYWORD: Match strings without unintended hits

DOMAIN-KEYWORD checks whether a domain contains a specified keyword, so it can match more broadly than a full domain suffix. It doesn’t understand what the keyword means or determine whether a hostname really belongs to an ad, analytics, or update service. Short conditions can catch unrelated domains, especially if they’re common letter combinations. The snippet below illustrates the syntax only; its keywords are not a verified blocklist and shouldn’t be added to a working Config without testing.

[Rule]
DOMAIN,downloads.example.com,DIRECT
DOMAIN-KEYWORD,ads,REJECT
FINAL,PROXY

The example first preserves an exception for a specific hostname, then demonstrates a keyword-based reject rule. Even so, other domains containing the same characters may also be rejected. If some images fail to load or a sign-in flow breaks, check the hostname of the failed request and see whether a broad condition matched it. If you only need to handle a known domain, an exact or suffix rule is usually easier to explain and maintain.

A webpage can involve multiple connections

A webpage doesn’t load through just one request. The main page, scripts, images, authentication, and APIs may connect to different domains. A rule for the address in the browser bar doesn’t ensure that every resource takes the same route. When testing, distinguish “the main page opens” from “all features work,” and check the key hostnames using fresh requests. Don’t broaden a site’s rules to a keyword just because one image failed, or assign every temporary third-party resource to the same suffix.

Domain rules require hostname information to be available during matching. If a request uses an IP address, or an existing connection is reused, what you observe may differ from a newly edited domain rule’s expected behavior. Close the test page, make a fresh request, and check the destination shown in the log. Once you can reproduce the problem reliably, decide whether to add a domain rule, handle an IP rule, or investigate DNS. You can also look up these terms in the quick reference.

4. IP, GEOIP, and USER-AGENT Rules

IP-CIDR and IP-CIDR6 address ranges

IP-CIDR matches IPv4 ranges, while IP-CIDR6 matches IPv6 ranges. The number after the slash is the network prefix length, not a port or an address count. A longer prefix generally describes a smaller range. Use the correct network address and prefix combination. To match a single IPv4 address, use a full host prefix; don’t omit the prefix and assume every form means the same thing.

The examples below use common private IPv4 ranges and an IPv6 local address range to illustrate the syntax. Whether these rules are needed depends on your network and existing general settings. Some system traffic or general bypass settings may be handled before ordinary rule matching, so a missing match for an address rule doesn’t necessarily mean its syntax is wrong. When troubleshooting a local network service, record the device’s address, gateway, and current network type.

[Rule]
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
IP-CIDR6,fc00::/7,DIRECT,no-resolve
IP-CIDR6,fe80::/10,DIRECT,no-resolve
FINAL,PROXY

What no-resolve controls

no-resolve prevents a DNS lookup solely to evaluate that address condition. It doesn’t disable DNS for the entire app or guarantee that the rule can never match a domain-related connection. The address condition may still match if the request already targets an IP address or an address is available during matching. The parameter controls DNS behavior during matching; it doesn’t turn the rule into a special condition for a particular type of app.

When a Config contains many address ranges, resolving hostnames unnecessarily for each match can add delay and make the DNS route affect the result. On the other hand, adding this parameter everywhere can prevent rules that rely on resolved addresses from being evaluated as intended. Before using it, ask whether the rule needs a hostname resolved to an address to work, then check the actual request log. It isn’t a general speed-boost switch.

GEOIP uses a database; it doesn’t identify website ownership

GEOIP checks a destination address against the geographic IP database in use. A common form is shown below, but country or region codes describe how an address is classified in that database—not who operates a website, what language its content uses, or where the user is located. A domain may use distributed services and resolve to different addresses across networks or over time, which can change its classification. GEOIP works best as a broad fallback rule, not as a replacement for an exact domain condition whose purpose is known.

[Rule]
DOMAIN,service.example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY

If a GEOIP rule behaves unexpectedly, first check the actual connection address and which rule matched. Don’t infer an address’s location from the page language, and don’t reverse the entire geographic policy to accommodate one exception. If a service must reliably use a particular route, a clear domain rule near the top is usually easier to maintain. Database classification, DNS results, and service requirements are three separate facts; record them separately.

When to use USER-AGENT

USER-AGENT matches a request identifier that’s visible to the app, not the name of an app installed on the device. The example shows a prefix wildcard, but a match depends on whether the request includes the relevant field and whether it’s visible during processing. A rule can’t automatically read the contents of an encrypted request. If it doesn’t match, check what information is available before broadening the condition.

USER-AGENT,ExampleClient*,DIRECT

The same app may use system components or different networking modules that send different identifiers. Different apps can also use the same identifier, so this type of rule isn’t a reliable boundary for identifying an app. For ordinary domain routing, domain conditions are usually clearer. Keep a USER-AGENT rule only when you’ve confirmed the request identifier, understand its scope, and can test it consistently. Don’t change certificate trust or broaden content access just to make a match work.

5. Rule Priority, Exceptions, and FINAL

The first matching rule wins; the most specific rule isn’t chosen automatically

In the usual [Rule] evaluation, rules are checked from top to bottom, and the first matching rule determines the policy. An exact domain rule doesn’t get priority just because it’s more specific. If a broad suffix rule above it matches first, the exact rule below won’t change the result. This is a common reason a rule can be present but not take effect. When checking a target rule, also review the rules above it for earlier matches.

Read each line as a test: if its condition matches, apply that line’s policy and stop; otherwise continue. Comments, section labels, and blank lines can make a file easier to read, but they don’t create a separate priority system. An exception won’t override an earlier matching rule just because it’s under a prominent heading. For a long Config, use consistent sections to make the intended order clear rather than relying on memory to place exceptions.

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

Put specific exceptions before broader conditions

The example above handles two specific hostnames first, then covers the suffix, checks address and geographic conditions, and finally applies the default policy. This is one way to organize rules for clarity, not a required order for every network. If a service requires address rules to take priority, reorder them with the effects on domain conditions in mind. The key is not memorizing a fixed sequence; it’s knowing which rule a request that matches multiple conditions will encounter first.

Take office.example.com: even though it also matches the suffix condition, the first rule routes it direct. Move the suffix rule to the top and the result changes. Now consider a domain outside that suffix: it may reach the default rule only after the address and geographic conditions are checked. Testing a few carefully chosen targets is more useful for finding priority problems than judging whether everyday browsing “seems fine,” and makes it easier to tell what each edit changed.

Put FINAL at the end to handle unmatched requests

FINAL has no domain or address condition; it handles requests that haven’t matched an earlier rule. Put it after all active rules. If it appears in the middle, rules below it usually won’t run. Multiple default rules don’t mean that several policies will be tried in turn. The two examples below represent different defaults: send otherwise-unmatched requests through a proxy, or connect directly. Choose one that fits your connection setup and existing Config.

FINAL,PROXY

FINAL,DIRECT

These are alternatives, not rules to add together “just in case.” A default policy affects a wide range of traffic, so before changing it, list representative requests, including services that currently rely on the default route. Testing a domain that already matches an exact rule won’t show whether the new default is right. If you’re unsure how the current Config is designed, keep its default and add a local exception for the specific issue instead of changing routing globally.

Check for duplicate and shadowed rules when merging

When merging Config snippets, check for overlapping scope, not just identical lines. If the same condition appears more than once, the earlier rule usually determines the result; a later rule with a different policy may never run. Broad keywords, suffixes, and address ranges can also shadow exceptions below them. Keep a copy of the original, trace a test domain to its first match, and remove redundant rules only after confirming the result. Alphabetically sorting an entire file can break the priority of an ordered rule section.

When you find a shadowed rule, determine whether it’s an accidental duplicate or a note retained for a future change. Keep active rules clear, and put maintenance notes somewhere they won’t be executed. After editing, create a new connection instead of assuming an existing one proves the new order doesn’t work. Check every relevant hostname separately: one correctly prioritized rule doesn’t guarantee that all related requests are covered.

6. DNS, Host, and Connection Addresses

DNS resolves hostnames; rules choose policies

DNS mainly answers which address belongs to a hostname; rules mainly determine which policy a request uses. They can affect each other, but they aren’t the same thing. Successful DNS resolution means an address was obtained; it doesn’t mean the destination port is reachable. A proxy rule match doesn’t prove DNS took the route you expected. In troubleshooting notes, record the hostname, resolved address, matched rule, and final connection status separately. “It won’t open” doesn’t identify which stage failed.

DNS settings in [General] affect the information used in subsequent checks. With system DNS, results may change between Wi-Fi and cellular networks. If you specify another resolver, check whether that DNS service is reachable. Don’t change several DNS options and judge the result only by how quickly a page opens. DNS caching and reused connections can make a test exaggerate or obscure the difference between Configs.

[General]
dns-server = system

A Host mapping isn’t a server entry

[Host] lets you map a specific hostname to an address. The example maps a documentation domain to a reserved example address to show the format; it doesn’t indicate that a reachable service exists there. The left side of the equals sign is the hostname, and the right side is the destination address. This isn’t a proxy server to enter in Add Server, and it won’t change a remote service’s authentication details. Don’t put server addresses or passwords from a subscription in this section expecting it to import a server.

[Host]
service.example.com = 192.0.2.10
assets.example.com = 198.51.100.20

A fixed mapping can be useful in a controlled environment with a known address requirement, but it bypasses the domain’s normal dynamic routing. After a service moves, an address becomes invalid, or the network changes, an old mapping may keep sending requests to the wrong destination. If a domain fails only with a particular Config, look for a leftover mapping and compare the addresses returned by system DNS and the Config. Don’t keep a fixed address indefinitely if you can’t explain where it came from.

A changed address doesn’t mean a changed certificate identity

When you access an encrypted service by hostname, the connection address is related to server identity verification, but the two aren’t interchangeable. Mapping a domain to a different address won’t give an arbitrary service at that address the right certificate or make it recognize the required hostname. If you see a certificate or handshake error, check the domain, service settings, and system time. Don’t treat weaker verification as a routine fix. To review settings for an existing Trojan server, see Password, SNI, and TLS settings.

Similarly, don’t assume that a Host mapping always takes precedence over domain routing. A domain condition may match before an address condition; a mapping affects the connection destination, while the policy is determined by the matching process. To test how they interact, create a mapping for one controlled hostname, record the actual connection address, and check domain and address rule matches separately. The final address alone can’t tell you what happened in earlier steps.

Caching, dual-stack addresses, and network changes

A hostname may resolve to both IPv4 and IPv6 addresses. Which one is used depends on network reachability and the connection process. An IPv4 rule doesn’t automatically cover IPv6; seeing one IPv6 failure doesn’t prove you should change address-family settings globally. First check which address type the request used, then review the matching rules and network conditions. Recording IPv4 and IPv6 results separately helps explain why one test succeeds while another fails.

After switching networks, DNS caches, app connection pools, and existing connections may affect results for a while. To test a new Config, close the old test connection and make a fresh request to the same destination. If needed, use the app’s available tools to clear relevant caches. Clearing a browser’s page cache won’t necessarily create new network connections. If the issue occurs on only one network, keep the Config unchanged for comparison to separate local network conditions from Config errors.

Keep DNS settings explainable: know which resolver is selected, why each fixed mapping exists, and which address rules depend on resolution. The more old options and unknown mappings a Config contains, the more possibilities you’ll have to rule out when something fails. Don’t keep layering unexplained settings into a working copy. Return to a minimal working setup, then restore only the settings you need, one at a time.

7. URL Rewrite Syntax and Scope

Rewriting a request URL doesn’t choose its connection policy

[URL Rewrite] handles matching visible request URLs; [Rule] selects connection policies. They aren’t interchangeable. Rewriting a URL to another hostname doesn’t automatically send it through a proxy. The new destination still depends on the relevant Config and processing stage. Conversely, a domain rule selects a route but doesn’t automatically change a URL path. First determine whether the problem is URL rewriting or connection routing, then choose the appropriate section.

A rewrite rule typically consists of a matching expression, a target, and an action. When an expression contains special characters, read it as a regular expression rather than a plain string. A period has a special meaning in a regex; escape it to match a literal period in a hostname. A start anchor limits where matching begins, and an end anchor limits where it ends. Without the right boundaries, an expression may match more than intended.

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

How to read the example

The example matches a specific scheme and hostname from the start of the URL, captures the content after the slash, and inserts it into the target URL using $1. The 302 action means a temporary redirect. The reserved example domain is for demonstration only, not something you need to add to your Config. Before using a rule, make sure the destination service supports the target scheme and path. A redirect tells the requester to visit another URL; it can’t make a nonexistent service available.

Whitespace between the expression and target separates them, so don’t insert unhandled spaces into the expression. When copying rules, check that your text editor hasn’t changed quotes, backslashes, or punctuation. Regex rewrites are more prone than simple domain rules to being syntactically valid but matching the wrong scope. Test both a URL that should match and a similar one that should not, to make sure the boundaries are strict enough.

Rewriting requires the request to be visible

The full path and query parameters of an encrypted connection generally can’t be read from a domain-routing rule alone. A rewrite can run only when the app has the required request information and the request can be processed in that context. Seeing a connection’s hostname doesn’t mean the full URL is visible; seeing one URL doesn’t mean every app’s requests are handled in the same way. If a rule doesn’t run, first check whether the request is visible and matches the expression, then review the action and target.

Don’t broaden content processing for all domains or change certificate trust just to test an ordinary rewrite. Processing encrypted content has its own security boundaries and may be affected by an app’s own checks. These are not routine requirements for traffic routing. To route a hostname through a proxy, direct, or reject policy, use [Rule]; you don’t need URL rewriting to achieve the same purpose.

Avoid loops, lost paths, and misplaced sensitive data

A redirect target that matches the original expression may create a loop. Even if the rule appears to change only the scheme, check whether the destination service redirects the request back to its original URL. Be clear about whether the path and query parameters should be preserved: a capture that’s too narrow may drop required parameters, while one that’s too broad may send unwanted data to the new destination. Never rewrite authentication-related requests to another hostname unless you understand what the parameters contain and where they’re going.

If several rewrite rules are active, review their matching scope individually. Test one rule first, then test the combined set. When repeatedly testing the same starting URL, account for cached redirects: a page opening at the new URL doesn’t prove the rule is still running. Record the original URL, final URL, and matched rule, and use a fresh session when needed to verify the result.

If your goal is to block a known hostname, an explicit REJECT rule is usually easier to maintain than a complex rewrite. If you only need to change the route, use the rules section. Keep a rewrite only when URL transformation is actually needed, you can explain how the match relates to the target, and you have a reliable way to test it. Remove experimental rules when you’re done so they don’t unexpectedly run on a later request.

8. Validate, Troubleshoot, and Maintain Your Config

Set up a repeatable test baseline

Before making changes, confirm that the current network can access a basic destination. Record the network, active Config, Global Routing mode, and selected server. Choose fixed test destinations: one for an exact rule, one for a suffix rule, and one that relies on the default rule. Change only one condition at a time, save, and establish a fresh connection. This baseline is more useful than continuously adding rules because you can link each result to a specific edit.

Define what counts as a successful test. Opening a page proves only that some of its requests succeeded; sign-in, APIs, and other resources may still fail independently. First check whether the request matched the expected policy, then whether the connection was established, and finally whether the feature works. Record these as separate results to distinguish “the route is right but the server is unreachable” from “the connection works but the service returned an error.”

Troubleshoot by layer: conditions, matching, connection, and service

1. Conditions: Confirm the app is connected, the right Config is selected, and Config mode is active.
2. Matching: Check the actual hostname or address and find the first matching rule from the top.
3. Connection: Check DNS resolution, destination reachability, server authentication, and transport settings.
4. Service: Check the destination’s response, account status, and whether all required requests completed.

If the expected rule didn’t match, first check for a broad rule that shadows it, a rule placed after the default, the wrong file being saved, or a reused connection. If the expected policy matched but the connection failed, stop editing rules and check whether that route is reachable. Connectivity Test can help compare the connection performance of existing servers, but a successful test doesn’t guarantee that every destination will work, and a failed test alone can’t identify the incorrect protocol setting.

[Rule]
DOMAIN,check.example.com,PROXY
DOMAIN-SUFFIX,example.com,DIRECT
FINAL,PROXY

This short example illustrates how to verify a Config: an exact match should use the proxy, other hostnames under the same suffix should go direct, and destinations outside that scope should use the default policy. In practice, replace the example domains with destinations you’re authorized to test and that actually exist. Don’t use whether an example address opens to judge the Config. Example domains and documentation addresses demonstrate syntax; they aren’t a network connectivity test service.

Distinguish routing problems from speed problems

If the route is correct but the connection is slow, compare local network quality, the destination service, server load, and protocol settings instead of broadening the proxy rules. Latency and transfer speed are different metrics: a quick connection doesn’t guarantee stable long-term transfers. Keep the Config unchanged and compare the same destination on different networks; this usually makes the cause easier to isolate than changing the Config and server at the same time. For a step-by-step method, see How to troubleshoot slow speeds by layer.

If the issue appears only after switching networks, check whether the connection was re-established, DNS results changed, or On Demand affected when the connection started. On-demand behavior triggers a connection; it doesn’t choose a policy in place of domain rules. Don’t treat automatic connection timing and rule matching as the same setting. For more on this, see On Demand and background battery use, then test again with the same destination.

Keep a change log and a recovery copy

Keep a clearly labeled recovery copy of any Config that’s working reliably. Your notes don’t need the full subscription URL; record the change’s purpose, affected section, scope, and test result. After a remote Config update, compare the default policy, general settings, and personal exceptions before switching to it. Merging many unknown rules at once makes the Config harder to understand and may introduce duplicates or outdated mappings. Add only what you need, one item at a time, so you can tell what’s still necessary later.

Before sharing troubleshooting details, remove your subscription credentials, server passwords, personal addresses, and sensitive paths. Screenshots and text should include only the mode, rule type, and redacted destination details needed to diagnose the issue. This is the Shadowrocket official site and manual. Shadowrocket is a closed-source commercial app; system requirements for iPhone and iPad are listed on its App Store page. For purchase verification, see the three checks for an authentic App Store purchase. For common first-connection issues, return to the Getting Started guide and follow the steps.

The goal isn’t to have more rules, but to make every rule’s purpose clear, every exception testable, and every update reversible. When a new issue appears, reproduce it first, identify the first stage where the result differs from what you expected, then make the smallest necessary change. A Config is validated when you can explain how a request moves from its destination through matching and policy selection to the final connection result.