Shadowrocket
Rules and Configuration Guide

Find the active file first, then identify what each section controls.

Use Config to confirm which file is active

A configuration file is not simply another way to list servers. Server details describe the address, port, protocol, and authentication required to connect to a remote endpoint. A configuration file determines how requests are classified, which policies are selected, and how certain parsing and handling tasks work. In Config, first verify which file is active; importing a file does not mean it is in use. File availability, saved content, selected file, and Global Routing set to Config are four separate states to check. If a recent rule change has no effect, checking these four is usually more useful than adding another similar rule.

Before editing, keep a copy of the file currently in use and note the selected server and Global Routing setting. If this is your first time reviewing a configuration, start with the section headings, then read the fields within each section rather than trying to infer the whole file line by line. Bracketed headings mark sections, and subsequent entries are interpreted in that context; the same text can mean different things in different sections. Domains in examples illustrate syntax and are not usable connection services.

What the four common sections do

Settings in General control the basic handling environment; ordinary routing rules do not belong there. Each line in Rule specifies a match condition and its result, such as selecting DIRECT when a domain matches. Host changes the address mapping for a specific hostname; it does not assign a proxy policy to that host. URL Rewrite modifies visible request URLs and does not replace Rule's routing decisions for ordinary connections. Confusing these functions can lead to questions like, “If the domain already maps to an address, why is it still using a proxy?” Address resolution and policy selection are separate decisions.

[General]
dns-server = system

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

This minimal example uses system DNS, sends example.com and its subdomains through PROXY, sends a local network range through DIRECT, and lets FINAL handle other connections. It contains no usable server and does not describe a complete network setup; it simply makes section boundaries and rule structure clear. Do not add empty Host or URL Rewrite sections just to fill out the outline. A lean file makes it easier to see the effect of each change.

Editing, saving, and importing are different steps

After importing a configuration file, check that sections are complete, line breaks are preserved, and commas are standard ASCII characters. Rich-text copies can introduce localized punctuation, invisible spaces, or collapsed line breaks. The text may look right while parsing differently. After saving, reopen the editor to confirm the stored text matches what you intended, then return to Config and confirm the selected file. If you update a configuration from a remote source, verify separately whether local edits are preserved; one successful save does not guarantee that future updates will merge them automatically.

For a complex configuration, establish an understandable baseline, then move in only the settings you need. Test after each group rather than copying every advanced field at once. A filename cannot prove that its contents suit your device, and a comment saying “direct” does not override the actual policy. Confirm the result using the saved text, current mode, and connection records together. The same approach applies throughout the following sections.

Global Routing sets the routing mode; the policy determines what happens after a match.

Where to check Config, Proxy, and Direct

Config, Proxy, and Direct in Global Routing are routing choices, not synonyms for individual rules. Config applies the active configuration to connections and is the first place to check when validating the Rule section. Proxy is useful for temporarily checking the proxy path; Direct helps compare access over the local network. Neither choice proves that every system connection is handled the same way. Basic bypass settings, system-reserved connections, and the network environment can affect what you observe, so focus on the specific request being tested.

For example, a domain connects in Proxy but fails in Config. That narrows the investigation to the configuration path, resolution differences, or policy selection; it does not prove that all domain rules are wrong. Check which line matched the connection in Config and where its policy points. Conversely, if Direct works but Proxy fails, check the connection settings for your existing server, remote reachability, and protocol requirements rather than immediately adding the domain to more DIRECT rules.

What PROXY, DIRECT, and REJECT do

PROXY in a rule means to use the proxy path, but it does not contain a server address. The actual connection depends on the selected server and any policy references in the configuration. DIRECT connects to the destination without using the proxy path specified by that rule; it does not mean DNS is skipped or that the destination is reachable. REJECT blocks matching connections and is intended for targets you explicitly want to block. Blocking a connection successfully and keeping a page working are different outcomes: rejecting a resource that the page depends on may break its functionality.

[Rule]
DOMAIN,api.example.com,PROXY
DOMAIN,printer.example.com,DIRECT
DOMAIN,blocked.example.com,REJECT
FINAL,DIRECT

These three domains demonstrate different policies; they are not a complete configuration to use as-is. Changing DIRECT to PROXY changes the chosen connection path, but does not fix the destination address, certificate, or authentication settings. Changing a failed connection to REJECT does not fix the failure; it deliberately ends the connection. When maintaining a configuration, comment on why a policy is needed rather than merely restating its name. That makes it easier to reassess rules when the network environment changes.

Policy names, selected targets, and fallback behavior

If a file uses custom policy names, confirm that each one is defined in the active configuration and that its spelling, capitalization, and spacing match exactly. Do not copy a reference without the policy it refers to. With policies that include selection or probing, a rule match only completes the first stage of classification; the final connection may still depend on the selected target's state. After you see the expected policy name in the record, check the actual connection target as well. A correct rule and an unavailable server can both be true, and should be investigated separately.

Also distinguish “no earlier rule matched” from “a matched connection failed.” In the first case, a later rule or FINAL handles the request. In the second, a connection failure does not usually send the same request back through Rule to try the next rule that might connect. Retries or switching within a policy depend on the relevant configuration and feature; Rule order is not a list of backup servers. This distinction helps explain why a seemingly usable second rule may never be tried.

After changing a mode or policy, establish a new test connection and record the mode, matched rule, and connection target before and after the change. Do not judge success by the appearance of the connection toggle, and do not change the mode, server, and DNS all at once. Keeping other conditions constant makes the cause of a change clear. To learn rules, start with a few explicit rules in Config and establish repeatable results before expanding to a daily configuration.

Exact domains, domain suffixes, and substring matches have different scopes.

DOMAIN: match an exact hostname

DOMAIN matches one complete hostname and is useful for a clearly scoped exception for a single service endpoint. In DOMAIN,api.example.com,PROXY, the target is api.example.com, not every host under example.com. Do not include a protocol prefix, path, port, or the entire URL copied from a browser's address bar in the domain field. A standard DOMAIN rule cannot distinguish paths on the same host. First determine whether the need is domain-based routing or request URL handling.

An exact rule keeps its scope manageable and makes it easier to correlate with logs. When adding an exception for an API, check the actual request hostname rather than looking only at the page URL. A page may request separate login, static asset, and API domains; changing the main page's rule will not necessarily affect those other requests. If part of a page works and another part fails, inspect the destination of each failed connection instead of treating the whole page as a single request to one domain.

DOMAIN-SUFFIX: cover a domain hierarchy

[Rule]
# Put exact exceptions before broader suffix rules
DOMAIN,api.example.com,PROXY
DOMAIN-SUFFIX,example.com,DIRECT
FINAL,PROXY

DOMAIN-SUFFIX,example.com,DIRECT covers example.com and its subdomains. It matches at a domain-suffix boundary, not an arbitrary substring, so an unrelated hostname that happens to contain the text example.com is not necessarily a match. Suffix values generally need no asterisk or protocol prefix. Place this broad rule after exact exceptions: api.example.com matches the first line, while other targets under the suffix then use DIRECT.

If the two lines above are reversed, the broader rule will catch api.example.com first. The more detailed exact rule below it will not automatically take priority. When reviewing a configuration, check both what each rule expresses and which broader rules precede it. A suffix rule is useful for a shared policy across a domain hierarchy, but does not mean all related dependencies use that suffix; external resources and redirect destinations may need separate consideration.

DOMAIN-KEYWORD: use broad substring matches with care

DOMAIN-KEYWORD matches a string in a hostname and is useful when you deliberately need to catch the same text across multiple domain hierarchies. It does not identify targets by brand or verify domain ownership. For example, the keyword example could match many different hosts containing that string, usually covering more than a specific suffix. If you only need example.com and its subdomains, prefer DOMAIN-SUFFIX. Before using a broad keyword, list the targets it could catch unintentionally and decide whether that scope is acceptable.

These rule types have no built-in order where “more exact” automatically outranks “broader.” They still follow the order in the Rule section. You can organize rules with narrow exceptions first, shared suffixes next, and keywords last when needed. This makes the configuration easier to understand; it is not a parser requirement. If a keyword rule already covers several suffixes with the same policy, adding more suffix rules may only increase maintenance work.

Do not guess when the domain is not visible

If an app connects directly to an IP address, uses its own resolution mechanism, or the record does not include a hostname, do not assume the DOMAIN family can still see the full hostname. Check the visible destination in the record first, then decide whether an IP rule is appropriate. Seeing a domain in a browser does not mean every underlying connection has the same information. Whether a domain rule can match depends on what is available when that connection enters processing, not on what appears elsewhere in the interface.

When organizing domain rules, note the purpose and exceptions for each group, and remove duplicates already fully covered by earlier rules with the same policy. Test at least the target domain, one subdomain, and a similar domain that should not match. This checks both that the rule catches the intended connections and that its scope is not too broad; one successful test cannot establish that the rule boundaries are correct.

Different rules read different information; first check what the connection actually exposes.

IP-CIDR and IP-CIDR6 network ranges

IP-CIDR describes a set of IPv4 addresses using a network address and prefix length; IP-CIDR6 is for IPv6. A longer prefix represents a smaller range. Use /32 for a single IPv4 address and /128 for a single IPv6 address. Before adding a range, confirm that it covers only targets you actually need to handle. Do not change an entire large block to one policy because a single address failed. Shared infrastructure in an overly broad range may affect services unrelated to your original need.

[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
GEOIP,CN,DIRECT
FINAL,PROXY

The first two lines demonstrate common private IPv4 ranges, and the third shows the IPv6 unique local address range; they do not cover every local network. A particular LAN may use another private range or a different addressing plan, so check the device's actual network. IPv6 is not automatically covered by IPv4 rules: an IPv4 range does not mean IPv6 connections for the same service use the same policy. If connections to the same domain behave inconsistently, check the address family in the records.

no-resolve avoids extra DNS lookups; it does not create a destination address

no-resolve after an IP rule prevents the rule from initiating a DNS lookup solely to perform that match. It is useful for connections that already have a known destination address or to avoid unnecessary resolution during evaluation of IP rules. It does not disable DNS entirely or mean that every domain skips later address checks. If a connection has a hostname but no available destination address, an IP rule with no-resolve may not match it; another rule will still need to determine the policy.

So, adding only a private IP range with no-resolve may not be enough to send a local hostname through DIRECT. If the hostname is available only through local DNS, check how it resolves, whether the result is visible, and whether an earlier domain rule has already matched the request. Do not treat no-resolve as a general speed boost. It controls whether an extra lookup occurs during matching, so use it to manage lookups when needed rather than appending it mechanically to every rule.

GEOIP classifies addresses; it does not determine service ownership

GEOIP,CN,DIRECT applies DIRECT according to how the target IP is classified by the address database. It does not identify a website's language, match a domain suffix, or prove who operates a service or where its content is hosted. The database, actual destination address, and resolution result can all affect a match. A domain may use infrastructure in multiple locations, and a later resolution change may alter its address classification. For services that need a stable policy, explicit domain rules are often a better way to express intent, with GEOIP used as a broader fallback classification.

When troubleshooting GEOIP, note the address used by the connection and check whether an earlier domain rule already ended matching. An address in the expected range does not mean the GEOIP rule was reached. Conversely, a missed GEOIP match does not immediately point to a database error; the connection may not have entered that evaluation path. Do not treat geographic classification as a precise security boundary or use it in place of authentication, access controls, or certificate verification.

USER-AGENT visibility limits

[Rule]
# Use this condition only when request information is available for matching
USER-AGENT,ExampleApp*,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT

USER-AGENT matches User-Agent information available in the request. The asterisk in the example is a wildcard in the pattern. This is not process identification based on the name of an installed app, and it cannot identify every connection made by an app. Encrypted requests or connections that do not include the relevant field may not provide matchable information. When troubleshooting, distinguish “the app made a connection” from “the connection exposed a matchable User-Agent.” The app's name alone does not prove that a rule should match.

For a configuration using several condition types, you can review it in this order: explicit domain exceptions, request-information conditions that are genuinely needed, specific network ranges, broader address classifications, then FINAL. The intended behavior still determines the final order. For each condition, note what information it depends on and what handles a request when that information is missing. This is more useful for maintenance than simply counting rules, and avoids treating different rule types as interchangeable.

Rules are checked from top to bottom, and the first match wins. A more specific rule is not automatically higher priority.

Trace the order instead of judging by rule names

To read the Rule section, take a specific request and check each rule in turn, starting at the top. When a condition matches, its policy applies; later ordinary rules do not reclassify the request. A broad rule near the top can therefore override many precise rules below it. “Exceptions first” is not a hidden mechanism; it is the result of placing exceptions before shared rules. When reviewing a file, map the overlaps first, then decide whether the order needs to change.

[Rule]
# Keep the single-host exception first
DOMAIN,api.example.com,PROXY

# Then handle the whole domain hierarchy
DOMAIN-SUFFIX,example.com,DIRECT

# Known local network targets
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve

# Broader address classification
GEOIP,CN,DIRECT

# Final policy for all other connections
FINAL,PROXY

For api.example.com, the first line matches, and the suffix rule does not change its policy. For static.example.com, the first line does not match, so the suffix rule sends it through DIRECT. A known LAN IP may not match either domain condition, so the network-range rule catches it next. Only connections with no earlier match reach FINAL. These are conditional checks, not attempts to connect through multiple routes in sequence; a network failure after a policy is selected happens at a later stage.

FINAL handles the remaining connections

FINAL is not “the most important domain rule.” It is the final policy for connections not classified by earlier conditions. FINAL,PROXY expresses a design that uses the proxy path by default; FINAL,DIRECT expresses one that connects directly by default. Neither is inherently better without context. Choose based on the exceptions above it and your actual needs. Changing FINAL often has a wider impact than adding an exact domain rule because it changes the handling of every uncovered connection.

Place FINAL at the end of the rule list, and do not append ordinary rules that you expect to work after it. If you add lines at the bottom without noticing an earlier FINAL, those lines may never run. Watch for duplicate FINAL rules when merging files: do not append two complete Rule sections and expect the second to work unchanged. Set one default policy first, then reorganize the useful exceptions from both files above that FINAL.

Duplicate, conflicting, and unreachable rules

Duplicate conditions with the same policy usually add only reading overhead; if the same condition has different policies, the earlier line wins. Less obvious conflicts come from overlapping scopes: an earlier DOMAIN-SUFFIX can cover a later DOMAIN, or a broad network range can cover a smaller one. When reviewing, do not search only for identical text; compare the sets of targets each rule covers. If a narrow exception is necessary, move it earlier and comment on how it relates to the broader rule below.

If a configuration references external rule sets, treat each reference as one decision point in the current order, not as a completely separate priority system. Changes to external content can expand or shrink its match scope, so later local rules may no longer receive the same requests. When behavior changes after an update, check both the local reference position and the external content. Comparing only the local file may miss what actually changed the match results.

Build a repeatable test matrix

Before changing the order, choose at least four test cases: an exact exception, a shared suffix, a known local address, and a target that should reach FINAL. For each, note the expected matching line and policy, then establish a new connection and verify them one by one. You do not need extensive numerical records; the key is an explainable result for the same target in the same mode. If a new rule fixes one target but changes another that worked, revisit the overlap rather than appending another patch at the end of the file.

Keep the reason for the rule order in nearby comments, especially for exceptions that must precede broader rules. These notes prevent a later reordering or merge from breaking behavior in pursuit of a tidier list. The goal is not visual sorting: it is to make intended requests stop at the right rule and give uncovered targets a clear final destination.

Resolution, routing, and request rewriting are related, but none replaces the others.

Separate domain resolution from the connection path

DNS resolves hostnames to addresses; Rule determines the policy for a connection. They can affect what you observe, but they are not the same control. A domain may resolve through one path before a rule selects a direct or proxy connection; some connection methods may resolve it elsewhere. When troubleshooting, record both “which address was obtained” and “which policy the connection used.” Do not infer from PROXY that resolution necessarily happened remotely, or from DIRECT that all DNS lookups followed the same local path.

[General]
dns-server = system

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

dns-server = system means to use the DNS configuration provided by the system. It is a simple starting point for describing basic behavior, not a fixed answer for every network. If system DNS cannot resolve an internal hostname, assigning DIRECT to that hostname will not create the correct address. First check whether the name requires a particular network to resolve, then verify that the device is connected to it. Conversely, successful resolution does not prove the destination port is reachable; it is only one step toward a connection.

Host mappings: use cases and maintenance costs

[Host]
# Documentation example address; not a reachable service host
lab.example.com = 192.0.2.10

[Rule]
DOMAIN,lab.example.com,DIRECT
FINAL,PROXY

The Host section can map a specified hostname to an explicit address. The example address 192.0.2.10 is reserved for documentation and illustrates the field structure. This mapping does not imply DIRECT; the policy is specified in Rule. For a real mapping, confirm that the address belongs to the intended target and consider certificates, server-side hostname checks, and service updates. Pinning a domain to an old address may make resolution look stable while sending requests to a dead endpoint after a migration.

A temporary mapping can help isolate resolution during troubleshooting, but after testing decide whether to keep it and document why. A long-term static mapping may disrupt normal scheduling if the target uses dynamic addresses or load balancing. Do not copy an address from one lookup and assume it will always be correct. If a certificate name does not match, do not hide the problem by disabling verification; check whether the destination address, hostname, and server certificate are actually consistent.

URL Rewrite acts on visible request URLs

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

This example uses a regular expression to match one complete URL and redirects it to another URL with a 302 response. The leading ^ and trailing $ set the match boundaries, and the dots in the domain are escaped with backslashes so they are not treated as wildcards. A request with query parameters or a trailing slash may not match this exact expression. That does not mean rewriting failed; the condition simply does not cover that form. List the URL forms you need to match before deciding whether to loosen the boundaries.

A redirect does not select PROXY or DIRECT for the original connection. The browser may issue a new request after receiving the redirect, and that request is routed according to its own destination. If rewriting creates a loop, check whether the new URL matches the same or another expression again. Start testing with one narrow rule whose result is easy to observe. Broad expressions across an entire domain hierarchy make it harder to find which redirect changed the request.

Respect visibility limits for encrypted requests

An HTTPS request's full URL is generally not exposed directly to ordinary network routing. Adding URL Rewrite to a configuration does not mean every encrypted request automatically provides a full URL to match; handling depends on request visibility and related settings. Ordinary domain routing does not require broader inspection just to read paths. The rewrite example here explains section syntax only. Learning the rules does not require enabling additional certificate-related features, and such settings should not be the first response to every connection problem.

When maintaining these sections, consider caching and existing connections. The system, app, or browser may retain resolved addresses, redirect results, or connection state. After a change, test with a new request and distinguish a cache effect from a configuration that has not taken effect. If behavior differs between apps, first compare their actual request domains, addresses, and protocols rather than attributing the difference to section priority. Use the records visible for the current connection to explain its result.

Express needs with narrow conditions, then merge them gradually with a way to roll back.

Define the default behavior in one sentence first

Before writing a configuration, answer two questions: how should connections not explicitly listed be handled, and which targets need an exception? The first defines FINAL; the second defines the exception set. If you cannot explain the default behavior in one sentence, it is usually hard to tell whether a new rule is needed. Do not start by collecting a long list of domains and then guess what the whole file is for. More rules mean more overlap to manage, and content from separate files does not automatically reduce maintenance work.

[Rule]
# Proxy by default; use direct connections only for specified targets
DOMAIN,printer.example.com,DIRECT
DOMAIN-SUFFIX,home.example.com,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
FINAL,PROXY

This example uses the proxy by default and direct connections for specified targets. printer.example.com and home.example.com are example names; check your own environment, as they do not provide local services. If you want direct connections by default and a proxy for only some domains, create a few PROXY conditions instead and change FINAL to DIRECT. Do not simply combine files with opposite defaults: exceptions in one may be redundant or conflict with rules in the other.

Exceptions, shared rules, and blocked targets

[Rule]
# Put the single-host exception before the shared suffix
DOMAIN,api.example.com,PROXY
DOMAIN,blocked.example.com,REJECT
DOMAIN-SUFFIX,example.com,DIRECT
FINAL,PROXY

This combination includes a proxy exception, a reject exception, and a shared suffix policy. Put the two exact host rules before the suffix so they retain their distinct behavior. Use REJECT only for targets you explicitly want to block; do not add it just because a connection was slow. If a page loses functionality after adding a reject rule, first check whether an essential API was blocked rather than changing DNS. A rule can match correctly while expressing the wrong policy, so verify both routing and functionality.

For direct connections to local devices, do not turn every address you have encountered into a permanent rule. First check whether the device has a static address, whether its hostname is stable, and whether access requires the same LAN. A rule selects a path; it cannot make a device reachable when it is not on the current network. If your setup depends on a local range, check the address plan again when switching Wi-Fi. The same range can refer to different devices on another network.

Manage subscription data separately from rule files

Connection details imported through Subscribe and routing rules in Config serve different purposes. When an existing subscription is updated, server names, counts, or parameters may change. If the configuration references connection objects by name, check that those references still work. Do not assume a subscription update automatically fixes every local policy reference, or that backing up a rule file also saves all connection credentials. During migration, check connection details, the active configuration, and the routing mode separately to ensure they work together.

Your subscription URLs, authentication details, and private keys are sensitive. When asking for help, hide them and share only the necessary rule conditions, policy names, and failure stage. Example files should never contain real credentials. For the division between WireGuard fields and routing rules, see the WireGuard configuration parameters guide: protocol settings determine how a connection is established, while Rule determines which targets use that path. Neither layer replaces the other.

How to merge, update, and roll back

When merging configurations, back up the working file first, then list the actual requirements to add. Check whether the new content introduces General settings, Host overrides, URL Rewrite rules, or policy references, not just how many Rule lines it adds. Remove duplicate FINAL rules, put exceptions before relevant broader rules, and confirm that referenced names exist. Merge one related group at a time, save and activate it, then test representative targets. If something breaks, you will know exactly which change to roll back.

Treat a configuration update from a remote source as a change review, not just a completed update action. Compare rule order, default policy, and address overrides; pay particular attention to local exceptions that may no longer be present. If you maintain the configuration manually over time, remove advanced fields with unclear purposes and document the important rules. The easier a file is to understand, the easier it is to restore during a problem. Maintainability comes from clear boundaries and verification records, not from the number of rules.

Keep a compact baseline to distinguish network problems from complex configuration issues. It still relies on your own server; it is not a standalone connection service. When the daily configuration behaves unexpectedly, test the same target with the baseline. If it works, restore the complex rules one group at a time. This provides clearer evidence than repeatedly importing the entire file and helps avoid losing settings that were already working.

Confirm the handling path first, then compare the same target. Do not treat one successful attempt as conclusive.

Step 1: Check the current state and start a new connection

When a rule appears not to work, record the device's current network, Global Routing mode, selected configuration, and connection target. Then issue a new request to a clearly identified target. An existing connection may retain the state it had when it was established; changing the file and refreshing a page that reuses the connection is not enough to draw a conclusion. An enabled connection toggle only indicates that the client is in a corresponding operating state; it does not prove the expected rule handled the target. Check the record for this request, not just whether a button looks right.

Next, confirm that you are testing one target. A page in the browser may request many resources; one image loading does not prove the API connection works, and one failed API does not mean the entire domain hierarchy is failing. Choose a clearly identifiable failed hostname and record its domain or IP, matched rule, policy, and error. If the current interface does not show a particular detail, mark it as unknown rather than inferring a match record from what the page looks like.

Step 2: Distinguish no match, wrong policy, and execution failure

If FINAL matched, trace the same target from the first line. Check whether a full URL was entered as a DOMAIN value, whether the connection exposed only an IP with no hostname, or whether no-resolve prevented the expected address check. If the wrong policy matched, look for a broader rule earlier in the list. If the expected policy matched but the connection failed, analyze classification and execution separately. Next, check the selected connection target rather than repeatedly moving the exact rule higher.

Step 3: Compare the local network with your existing server

Connectivity Test can help you assess the connectivity of an existing server, but one successful test does not prove that every target, protocol, or real-world service works. A failed test alone does not prove that Rule is at fault either, since the test may use a different target and handling path from a particular request. Treat the result as supporting evidence and identify the stage of the actual request: did the destination fail to resolve, could a remote connection not be established, or did the service return an error after the connection was established? Different stages require checking different settings.

If Config and Proxy behave differently, hold the same existing connection target constant and compare the target's resolution and match records. If Direct also fails, check whether the local network can access the target, especially for LAN hosts and internal hostnames with environmental requirements. If performance is slow rather than completely unavailable, investigate the local Wi-Fi or cellular network, transport settings, and actual route separately. See step-by-step connection speed troubleshooting; do not expand PROXY coverage repeatedly instead of finding the cause.

Step 4: Roll back variables and retest representative targets

Roll back only one group of recent changes at a time, then establish a new connection to the same target. If removing a broad rule restores normal behavior, find out what it covered instead of permanently deleting every rule of that type. If undoing URL Rewrite fixes redirects, investigate the expression and any redirect loop rather than changing the server. If the same problem persists with a compact configuration, complex rules may not be the main cause; shift the investigation back to the network, resolution, and existing connection settings.

[Rule]
# Temporary test for one target's classification; not a complete daily configuration
DOMAIN,api.example.com,PROXY
FINAL,DIRECT

This compact example can verify whether a known target uses the expected policy, but replace the example with the domain you are actually testing and keep the original configuration available for recovery. After testing, switch back to your daily file; otherwise, other connections will follow the test file's FINAL policy. Give temporary configurations clear names and purposes so you do not forget which file is active days later. After a successful test, restore the original rules group by group and retest until you can identify the smallest change that caused the difference.

If the issue occurs while purchasing, reinstalling, or restoring a previous purchase, first read the restore purchases guide; these steps are unrelated to Rule matching. Shadowrocket is available only through the App Store and is primarily used on iPhone and iPad. Check the App Store listing for system requirements and compatibility. After restoring the purchase, you still need to check your own connection details and configuration; purchase history does not restore every part of your setup.

State the conclusion as a verifiable fact, such as “The domain matched an earlier suffix rule; moving it to an exact exception changed its policy to PROXY,” rather than simply saying “the configuration is fixed.” Keeping this cause-and-effect record makes it easier to recognize the same issue next time. To review the full setup process, return to the getting started guide. To understand a particular rule, use this page's contents to find the relevant section, and base your assessment on the actual input, match, and result.