Shadowrocket
Rules and Config Reference

[General]

Config File Structure and Scope

A Shadowrocket Config file is more than a list of domains. It separates runtime settings, request routing, hostname mappings, and URL handling into sections, each introduced by an English name in square brackets. To read the file, find a section header, then identify the syntax used by each following line until the next header. Two lines containing domains do not necessarily belong in the same section: a domain in Rule determines policy, while a domain in Host determines hostname mapping. They serve different purposes.

Build a Verifiable Baseline from a Minimal Config

Once you have a working server, use the snippet below to understand the structure. General here only indicates whether some system traffic is bypassed; Rule sets the LAN and final policies. This is not a complete template for every network and contains no server credentials. Make a copy of the active Config before editing, keep the original, and change one item at a time in the copy. In particular, do not remove existing DNS, rules, or network settings just to fit an example.

[General]
bypass-system = true

[Rule]
IP-CIDR,192.168.0.0/16,DIRECT
IP-CIDR,10.0.0.0/8,DIRECT
FINAL,PROXY

bypass-system = true affects whether some system traffic is handled by the client. It does not mean every system request will appear in the connection log. Rule logs show only requests the client actually handles and can identify. If a system feature has no log entry, first check whether its traffic is within the handling scope before assuming a Rule is wrong. Do not immediately add a broad domain rule.

Distinguish the Config File, Server List, and Active Connection

The Config file describes how traffic is handled; the servers listed in Home provide connection targets. Writing PROXY in a rule does not add a server address to the Config or mean the client has selected a working connection. Troubleshoot these separately: the active Config file, the Global Routing mode, and the selected item in Home. Similar filenames or a successful import do not prove that the current request is using the file you just edited.

Save your changes, return to Config to confirm the intended file is selected, then reapply the connection as prompted by the app. For remote Configs, distinguish local edits from upstream updates: downloading again may overwrite local changes, while saving a separate copy may stop it from following the original. Give copies descriptive names and note the reason for changes at the top of the file instead of distinguishing similar versions only by number.

Start syntax checks with the characters and their section

Rule fields use English commas, key-value settings typically use English equals signs, and section and policy names stay in English. Chinese punctuation, invisible characters copied along with text, or a rule broken across lines can prevent parsing as expected. Use one valid entry per line; put comments on a separate line beginning with #. Do not insert comments between fields or copy line numbers from a webpage into the file.

A file that saves successfully does not necessarily match your intent. Saving addresses text and syntax; actual behavior also depends on the active file, mode, traffic handling scope, and server status. Keep a known-working baseline, change one type of setting at a time, and retest with the same request. This makes it clear what to roll back if something fails, rather than having to investigate changes across several sections.

[Rule]

Domain Rule Scope and Boundaries

Domain routing is useful for specifying a policy for a service, but first choose the right matching scope. The three common domain keywords in Rule are DOMAIN, DOMAIN-SUFFIX, and DOMAIN-KEYWORD. None matches a complete URL: do not put the scheme, path, query parameters, or port in a domain field, or use the full browser address in place of a hostname. Break the request into scheme, host, port, and path first, then identify the host.

DOMAIN: Match a Specific Hostname

DOMAIN,example.com,PROXY matches the specified domain; it does not automatically include api.example.com. DOMAIN is easier to review when an individual host needs an exception. For example, a service's main site and file API may need different policies. Listing the exact host first helps prevent a later site-wide rule from swallowing the exception. Domains are generally case-insensitive, but using lowercase consistently makes duplicates easier to spot.

[Rule]
DOMAIN,files.example.com,DIRECT
DOMAIN,api.example.com,PROXY
DOMAIN,example.com,PROXY
FINAL,DIRECT

This snippet covers only the three listed hosts; other names use FINAL. If a page still lacks images or API data, it may reference other unlisted domains rather than indicate that DOMAIN failed. Opening a page can create connections to several hosts. When testing, check the host of each failed resource separately from the main document host; one address-bar hostname does not tell you where every resource goes.

DOMAIN-SUFFIX: Match a Root Domain and Its Subdomains

Use DOMAIN-SUFFIX,example.com,PROXY when services under the same domain should use the same policy. It covers example.com and its subdomains, such as api.example.com; it is not an arbitrary string-ending test. otherexample.com is not a subdomain of example.com. Put only the domain suffix in the rule field: do not add a leading asterisk or write https://.

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

The exact host is listed before the suffix rule, so local.example.com can use DIRECT while other matching requests use PROXY. If the two lines are reversed, the suffix rule handles that host first, leaving no opportunity for the later exception to apply. Rules do not automatically rank themselves by specificity; putting the exact rule first is an ordering choice made by the file's author.

DOMAIN-KEYWORD: Review Broad Matches Carefully

DOMAIN-KEYWORD matches a keyword in a domain, without regard to domain ownership boundaries. For example, DOMAIN-KEYWORD,example,PROXY may match multiple names containing example, not just example.com and its subdomains. Use it when a broad match is intentional; do not choose it over DOMAIN-SUFFIX just because it is shorter to write. The shorter the keyword, the more likely it is to match unintended targets.

Check where the domain came from instead of guessing who owns the site

Whether the client can match a domain depends on whether usable domain information is available for the connection. An app may connect directly to an IP, reuse an existing connection, or use its own resolution method, so the logged details may differ from what you entered in a browser. Check the destination and matched rule in the request log before choosing a domain or IP condition. Do not use a very short keyword to route an entire app through a proxy; the broader scope can cause hard-to-explain side effects.

For internationalized domains, the characters shown in the interface may differ from the encoded form used in the request. Use the hostname in the log when troubleshooting. A search result's redirect link is not necessarily the final site: a redirect can involve multiple domains, and each new connection is evaluated separately. If you want “send selected sites through PROXY and everything else through DIRECT,” see DOMAIN-SUFFIX and FINAL,DIRECT use cases. Start with an explicit domain list before expanding the scope.

[IP]

IP, GEOIP, and USER-AGENT

Domain rules match service names; IP rules match destination address ranges. They are not interchangeable: one domain may resolve to multiple addresses, and one address may host multiple services. For a website that should always use a particular policy, consider a domain condition first. For direct access to an office subnet or a specific device, IP-CIDR may express the intent more clearly. Before choosing a condition, decide whether you need to control a set of names or a set of addresses.

IP-CIDR and Prefix Length

An IPv4 CIDR consists of a network address and a prefix length after the slash. A longer prefix covers fewer addresses: /32 represents a single IPv4 address, while 192.168.0.0/16 represents a much larger private address range. Do not put a port in the CIDR field or substitute a domain for a network address. If you need to handle one device, specify its address rather than covering the entire private network for convenience.

[Rule]
IP-CIDR,192.168.1.20/32,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT
IP-CIDR,10.0.0.0/8,DIRECT
IP-CIDR,172.16.0.0/12,DIRECT
FINAL,PROXY

These three larger ranges are common private IPv4 address spaces; they do not mean your current network uses them. Adjust the rules to your own address plan if your network has overlapping routes, a remote private network, or specific access requirements. DIRECT means the connection does not use a proxy policy; it cannot create a missing system route or make an unreachable address accessible.

IP-CIDR6 and Dual-Stack Requests

Use IP-CIDR6 for IPv6, for example IP-CIDR6,fd00::/8,DIRECT. Do not put IPv4 and IPv6 addresses under the same keyword. A device may have both address types, and an app may prefer one over the other. Changing only IPv4 rules may therefore leave the actual connection unchanged. When testing, check the address family used by the request, not just the result of a single DNS lookup.

[Rule]
IP-CIDR,192.168.0.0/16,DIRECT
IP-CIDR6,fd00::/8,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY

This snippet combines different address conditions; it does not promise to handle every LAN setup. IPv6 link-local scope, network interfaces, and system routes have their own constraints. If the log shows an IPv6 destination but the Config has only IPv4 rules, confirm the intended behavior before adding a specific range. Do not route all IPv6 addresses directly as a general-purpose fix.

GEOIP Uses IP Geolocation Data

GEOIP,CN,DIRECT checks the destination address against the IP geolocation database used by the client. It does not identify a webpage's language, the domain's registration location, or an account's region. A content delivery network may return different addresses in different locations, and its database may not reflect actual deployment. GEOIP can be part of a broad policy, but it is not definitive proof of where a site belongs. For important services, place explicit domain rules before it.

When a domain request encounters a rule that needs a destination address, resolution may be involved. The optional no-resolve prevents that IP rule from triggering an additional lookup for a domain to match it, for example IP-CIDR,192.168.0.0/16,DIRECT,no-resolve. It does not disable DNS for the whole app, nor does it stop matching a known IP. Choose it based on your resolution requirements; it is not a switch that always improves speed.

USER-AGENT Visibility Limits

USER-AGENT,ExampleApp*,DIRECT matches available User-Agent information; the example asterisk matches following characters. This matches a request identifier, not an app's installed package name in the operating system. Multiple programs may use the same identifier, and one program may send different identifiers in different requests. It is not a reliable substitute for per-process routing.

The client may not be able to read HTTP headers in encrypted requests. Adding USER-AGENT to Rule does not make that information available, and you should not change certificate settings blindly to obtain it. If the log has no such field, treat it as unavailable and use observable domain or address conditions instead. Requirements that depend on paths or request headers should be evaluated separately from ordinary connection routing, so a rule that can never match does not create a false sense of completeness.

[Policy]

Policies and Global Routing

A rule answers “does this condition match?”; a policy determines “what happens when it does?” PROXY, DIRECT, and REJECT are policy names, not protocol types or server addresses. Shadowsocks, VMess, VLESS, Trojan, Hysteria2, and WireGuard describe connection methods. A rule using PROXY can be carried out through the currently available proxy connection. Changing a policy name to a protocol name does not configure a server.

PROXY: Route Requests Through the Active Proxy

A rule using PROXY requires a configured, usable proxy target. Address, port, authentication, transport, and TLS settings are connection configuration; whether a domain matches the rule is a routing question. Either can work or fail independently. If the log shows a PROXY match but the page still fails, the rule may be working while the selected server is unreachable, authentication is incorrect, or the server cannot reach the destination.

Check the selected item in Home first, then use Connectivity Test to help assess connectivity. A test result describes performance under its specific test conditions; it does not guarantee that every site, port, or protocol will work. For a field-by-field review of the Trojan password, SNI, and TLS settings, see Trojan parameter reference. Do not try to mask a remote authentication failure by adding domain rules.

The Limits of DIRECT and REJECT

DIRECT means the destination connection does not use a proxy policy; it is still subject to the local network, system permissions, DNS, routing, and destination service. A failed direct connection does not prove that a proxy is required or that the client blocked the request. REJECT denies a matching request and is suitable for a target you have confirmed should be blocked. It does not switch to another connection or provide a temporary fallback when a proxy fails.

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

This example puts the reject condition first, followed by an internal service, then a suffix rule for the remaining subdomains. How REJECT presents a failure to a particular app may depend on the request type, so the appearance of an error page is not a reliable indicator of whether the rule matched. Check that the destination, policy, and rule log agree instead.

The Three Global Routing Modes

The Global Routing modes Config, Proxy, and Direct correspond to the interface labels Config / Proxy / Direct. Config routes traffic according to the active Config and is the main mode for verifying Rule. Proxy and Direct route all connections within the handling scope through the proxy or direct path; do not assume ordinary Rule entries continue to run individually as they do in Config. The overall scope is still constrained by system traffic handling and does not mean every device connection follows the same path.

Use mode comparisons to troubleshoot, not to change several settings at once

If Config fails but Proxy succeeds, the routing direction or resolution path may be involved; check the logs to confirm. If both fail, check the proxy connection and destination service before expanding Rule. If Direct succeeds but Proxy fails, check whether the proxy server supports the destination and port. Start a new request after each mode change so a reused connection does not misrepresent the new mode.

On Demand determines when a connection starts based on network conditions. It operates at a different level from whether a domain ultimately matches PROXY or DIRECT. An automatic connection being triggered does not mean the policy is correct; if it fails to trigger, Rule cannot fix the trigger conditions. Check the connection toggle, Global Routing, Config, and server selection separately to narrow down the issue. For related interface terms, see the glossary.

[Priority]

Rule Order and Common Patterns

The key Rule principle is to check entries from top to bottom: the first matching valid condition determines the policy. Shadowrocket does not collect every match and then choose the most specific one, nor does a later entry automatically override an earlier one. Put explicit exceptions before broad conditions and keep FINAL at the end. This matters more than memorizing keywords: many cases of “rules not working” happen because an earlier condition has already matched the target.

Route Selected Domains Through PROXY and Everything Else Through DIRECT

This pattern suits a clearly defined proxy scope where other requests should use the local network. List exact exceptions first, then domain suffixes, and put FINAL,DIRECT last. It does not automatically discover every service a website depends on. If login, images, or APIs use other domains, confirm each one in the request log. Do not widen the scope to DOMAIN-KEYWORD or change FINAL to PROXY just because a page is incomplete.

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

For testing, prepare at least three targets: a host that should use the proxy, an exception that should remain direct, and a host not on the list. Check the matched rule and policy for each to verify the intended behavior. A successful request to example.com alone does not prove that the local.example.com exception or FINAL policy is correct.

Route Private Addresses Directly and Everything Else Through PROXY

Another pattern keeps access to local devices direct and sends other requests through PROXY. “Everything else” is broad: it includes unlisted business domains and app connections. Confirm the server works and understand how the remote path changes access. Private address entries must also match your actual network. If your business needs to reach a remote network with the same private address range through a proxy, a generic LAN direct rule may conflict with that goal.

[Rule]
IP-CIDR,192.168.0.0/16,DIRECT
IP-CIDR,10.0.0.0/8,DIRECT
IP-CIDR,172.16.0.0/12,DIRECT
IP-CIDR6,fd00::/8,DIRECT
FINAL,PROXY

This snippet omits GEOIP to keep its intent clear. Adding GEOIP,CN,DIRECT would create a different routing plan with a broader scope. Either approach can express a requirement, but a new condition is not behavior-neutral decoration. Every line should have a clear purpose and correspond to requests you can test.

FINAL Is Not a Fallback for Network Failures

FINAL applies when none of the preceding conditions match; it does not take over after an earlier connection fails. Once a request matches PROXY and then times out, it will not normally continue down to FINAL,DIRECT. Availability switching requires understanding the relevant policy settings; it cannot be implemented by listing multiple FINAL rules. A single clear FINAL is easier to review than several copies of the same keyword.

[Rule]
# Keep the exception for a single host first
DOMAIN,download.example.com,DIRECT
# Then cover the remaining subdomains
DOMAIN-SUFFIX,example.com,PROXY
# Finally handle requests that did not match above
FINAL,DIRECT

Resolve Rule Shadowing Before Merging Configs

Before combining two sets of rules, compare their FINAL entries, broad domain conditions, and large IP ranges. If the first set's FINAL remains in the middle, the second set may never be checked even if its syntax is valid. Likewise, a suffix rule covering all of example.com can shadow several specific hosts below it. Duplicate entries can also mislead maintainers into thinking a later change has taken effect.

Review rules in a sequence such as explicit blocks, specific exceptions, service domains, address ranges, regional conditions, and final policy. This is an organization method, not a priority enforced by the client. If your use case requires an IP condition before a domain condition, set the order deliberately and document why. Do not sort mechanically by keyword; sorting can change which rule matches first.

For shared services, avoid replacing a lasting domain rule with an IP from a single lookup. Addresses can change or serve unrelated traffic, so putting one first may affect other requests. Record the differences before and after each change, and keep a rollback copy. This is more reliable for maintaining a complex Config than assuming more entries make it more complete. For other common cases, see Help and troubleshooting.

[Host]

Host Mappings and DNS Paths

Host and Rule often appear in the same Config, but solve different problems. Host specifies which address a name maps to; Rule determines the policy for a request. Mapping a domain to an IP does not set DIRECT, and routing a domain through PROXY does not fix its DNS result. When troubleshooting domain access, separate “how the name resolves to an address” from “how the connection reaches the destination.” Otherwise, you may keep changing the wrong section.

Basic Static Mapping Syntax

The Host example below uses a documentation address to show the structure on either side of the equals sign. The left side is a full hostname and the right side is a destination IP; neither includes a scheme or URL path. For real use, replace them with an address you manage or are authorized to use. Do not test connectivity using the example address or permanently pin an unknown address to a frequently used service.

[Host]
portal.example.com = 192.0.2.20

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

Here, DOMAIN explicitly selects DIRECT, while Host specifies the address, making it easier to explain the two decisions separately. Even if the destination resolves to 192.0.2.20, that does not mean it can be reached over the current network. Routing, listening ports, access permissions, and server status must also be correct. Test with a valid address you control. A log showing that the mapping took effect and successful access to the service are two separate checks.

A Fixed Address Does Not Change the Certificate Name

HTTPS still verifies identity using the original domain, and the server typically uses SNI to select a certificate and site. Host changes the address mapping; it cannot make an incorrect certificate valid or make a server that does not host the domain serve the right content. If a certificate error appears after adding a mapping, check whether the server actually serves that domain rather than weakening certificate verification to hide an incorrect address.

Similarly, visiting an IP directly in a browser may not produce the same result as using a domain with a Host mapping. The request's host information may differ, and the server may serve different virtual sites. When troubleshooting, keep the original domain and access path unchanged and vary only the mapping you intend to test. Otherwise, multiple changes make it impossible to tell which one affected the result.

Check Resolution Settings in General Separately

General can include DNS settings. For example, dns-server = system uses the system resolver as its source. This is a concise example for understanding the default path, not a value required in every environment. The network, apps that resolve names independently, and proxy-side handling can all affect what you observe. Do not treat changing DNS servers as a universal fix.

[General]
dns-server = system

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

This snippet has no static mapping, making it easier to compare with the Host approach. If an old mapping is still active, changing the DNS server may not change the address for that host. If an app reuses an existing connection, another DNS lookup may not change the active connection either. Check for a Host entry and confirm that a new connection was created before judging whether the resolution setting had an effect.

Caches, App Resolution, and Multiple Addresses

DNS results can be cached by the system, client, or app, and website connections may be reused for a long time. Refreshing a page immediately after a change may not trigger a new resolution. Stop any active task, reapply the connection, and reopen the destination; if needed, use the app's cache controls. Do not reset all Config and network settings just to clear an old result for one target.

If the same name returns both IPv4 and IPv6 addresses, pinning one address or checking only one lookup is not enough to prove that every connection follows the intended path. Use the actual address in the connection log to check the address family, matched rule, and policy separately. For internal names, also test on the original network and another network: away from the office, the DNS search domain and private address routes may no longer be available.

Document the purpose of each fixed mapping and periodically confirm that the server still accepts the domain. Once troubleshooting is complete, remove mappings you no longer need and restore the baseline so an expired address is not mistaken for a rule failure months later. Do not add Host entries based only on guesses about requests you cannot observe. First collect the request hostname, destination address, and error type, then choose where to make a change.

[URL Rewrite]

URL Rewrite Expressions and Limits

URL Rewrite processes recognizable URLs; unlike Rule, it does not select a connection policy based on a host or address. Use it for a specific URL rewrite or redirect requirement, not as an app-wide routing switch. Before adding a rule, ask what needs to change: the connection path, the address mapped to a name, or the request URL itself? The first two are generally handled by Rule and Host; only the third belongs in this section.

Start with an Observable HTTP Redirect

The snippet below redirects a matching plain HTTP URL to the HTTPS version of the same domain, using 302 for a temporary redirect. It demonstrates syntax only and does not prove that the destination site supports HTTPS. The expression on the left matches the original URL, the middle gives the replacement, and the final field specifies the action. Spaces separate fields; do not replace them with Chinese punctuation.

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

^ anchors the match at the start of the string, \. represents a literal dot in the domain, (.*) captures the remaining content, and $1 refers to the first capture group in the replacement. If the domain's dot is left unescaped, the regular expression matches a wider range than intended. If you omit the capture reference, the original path may be lost and the redirect may lead to a different page.

Restrict the Host and Path to Avoid Overbroad Matches

A safer rule explicitly limits the scheme, host, and path prefix rather than rewriting every URL containing a particular word. A keyword may appear in both a domain and a path, and an expression without anchors may match unexpectedly in a query parameter. Prepare one URL that should match and several similar ones that should not. Test boundary cases instead of checking only one successful example.

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

This example handles only the old path prefix on a specified host; it does not rewrite other sites or paths. If the original URL includes query parameters, check that the captured replacement still behaves as intended. Take particular care with URLs containing login state, temporary authorization, or submission actions: changing the path or redirect method can affect how the server interprets the request.

A Rule Does Not Automatically Make HTTPS Visible

HTTPS encrypts request contents, so the client may not be able to read the full URL path or request headers directly. Adding an HTTPS expression to a rule does not mean it can process every encrypted request. Available information depends on the connection and related settings. Do not confuse adding Rewrite with gaining visibility into encrypted traffic, and do not enable certificate-related settings blindly just to make an example match.

Some apps use additional certificate restrictions or their own networking stack, so a method that works in a browser may not work for them. If you only want to route a site through PROXY, a domain Rule expresses that intent without reading encrypted content. Keeping the change at the necessary connection layer reduces dependencies and makes its scope easier to verify.

Misdiagnosis from Redirect Loops and Caching

If the client rewrites A to B and the server redirects B back to A, the result is a loop. Symptoms may include repeated loading, too many redirects, or a page that never finishes, rather than a clear indication of which Rewrite rule is responsible. Disable only the newly added rewrite first and leave Rule unchanged to see whether the loop stops. Do not also switch Global Routing, or you will not know which change affected the result.

A browser may remember a server redirect or a strict transport policy and upgrade an HTTP URL to HTTPS before sending the request. If you do not see the HTTP rule match, the expression may still be valid. Test with a controlled address and a fresh request while checking the actual request scheme and redirect chain. Do not repeatedly replay actions on a production service to test rules, especially if they submit data.

Rewrite and Rule may both apply during one visit: after the original URL is rewritten, the new request is still handled according to its actual destination. To find the final policy, check the final request, not just the URL originally entered. Document each rewrite's purpose and expected input and output, then remove temporary entries after testing. For sensitive flows such as authentication or payment, preserve the service's original URL behavior instead of applying a generic example.

[Diagnostics]

Validation, Maintenance, and Troubleshooting

To validate a Config, confirm both that the expected condition matched and that the connection completed along the intended path. Seeing a page load is not enough: it may come from cache or an existing connection, and a test tool reporting connectivity does not mean the destination service accepted the request. Use a repeatable test action, change one setting at a time, and record the destination host, address, matched rule, policy, and result.

Check These Six Points in Order

1. Confirm the client connection is enabled and the network has not just changed.
2. Check that Global Routing is set to Config for this test, not left in Proxy or Direct.
3. Confirm the selected file in Config and verify that your changes were saved.
4. Check the selected server in Home, including its connection settings and basic connectivity.
5. Make a new request and inspect the actual domain, address, and matched policy, ruling out a reused connection.
6. Change only the setting directly related to what you observed, then repeat the same test and record the difference.

This sequence separates the connection layer from the rules layer. If the first step fails, changing DOMAIN-SUFFIX is pointless. If the wrong file is active, correct syntax will not affect the request. If you are unfamiliar with importing a Config, follow the setup guide to establish one working connection before refining rules. It is easier to diagnose than adjusting server and routing settings together in an empty Config.

Choose a Troubleshooting Path by Symptom

If the log shows an unexpected rule, look upward in the file for the first condition that covers the request. If it shows the expected policy, investigate the connection and destination service instead. If requests to the same domain behave differently, compare address family, port, actual address, and connection creation time. Do not reduce these distinct conditions to “the rules work sometimes and fail sometimes.”

Reproduce the Issue with a Small Config Instead of Deleting Everything

When a complex file is hard to troubleshoot, copy the active Config and keep only the necessary General settings, one target condition, and one FINAL in the copy. Keep the original for rollback; do not clear it. The snippet below can help check whether a domain condition matches. Replace the test target with an existing service, and do not treat access to example.com as evidence about your own server.

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

If the minimal snippet behaves as expected, restore the original rules group by group and note when the result changes. This can reveal shadowing rules, overly broad keywords, or a FINAL placed too early. Keep General and resolution settings consistent during restoration; otherwise, a behavior change may come from the DNS path rather than the Rule you just added. One successful test does not prove the whole file is correct. Test examples for proxy, direct, reject, and fallback behavior.

Maintain Subscription Updates Separately from Local Config

Subscribe updates mainly concern existing server details, while Config updates concern rules and traffic handling. They may come from different sources and refresh differently. After an update, check exactly what changed; do not assume that refreshing the server list also fixes local rules. Get subscription links from your service provider. For the difference between a single share link and a subscription, see share link formats.

Configs, exported files, and logs may contain server addresses, account details, or links with authorization parameters. When describing an issue to someone else, include only the necessary rules and sanitized log details; remove credentials and full subscription URLs. Example domains in rules may be fine to discuss publicly, but real connection logs can reveal usage patterns. Review each item before sharing instead of sending the entire Config.

Regression Checks After Changes

Finally, test the target service, LAN access, and other apps that previously worked on your usual networks to ensure the new rules have not expanded their impact. If you use On Demand, test connection triggers separately after a network change rather than combining them with domain matching tests. Keep the original file, a note about each change, and a few test cases so you can distinguish Config issues from server or destination service changes later.

This page explains Config principles and rule boundaries. For installation and download options, see the download guide; for common errors, see Help and troubleshooting; and for terminology, see the glossary. When you encounter a new issue, gather observable facts first, then check the relevant section. The aim is for every rule to have a clear purpose, every change to be testable, and every failure to be reversible—not simply to make the Config longer.