Shadowrocket
Rules & Configuration Reference

A Shadowrocket configuration is not another name for a server list. Server details specify which connection endpoint to use; a configuration specifies how to handle different requests. Updating an existing subscription in Subscribe usually updates connection details. Switching configurations in Config may change rules, DNS, and address mappings. The two can be related, but updating a subscription does not necessarily sync every configuration setting. When troubleshooting, note the selected server and active configuration separately so you do not overlook either one.

Section names define scope; rule lines define conditions

Common .conf files use square-bracketed section names. [General] contains global options, [Rule] contains routing rules evaluated in order, [Host] contains static hostname-to-address mappings, and [URL Rewrite] contains rewrite expressions for visible request URLs. The order of sections in the file does not mean every feature runs in that sequence. Only the list of rules within Rule should be read from top to bottom. Moving Host to the top of the file will not “raise its priority.”

[General]
dns-server = system

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

[Host]
example.com = 192.0.2.10

This example shows three separate functions: General selects system DNS, Rule routes example domains and a private-network address, and Host maps sample hostnames to documentation-only addresses. These addresses illustrate the format and are not real service settings. URL Rewrite is not required for a basic connection, so it is left out of this starting example. If you only want to change routing, leave the other sections alone at first to avoid confusing the results by changing several variables at once.

Confirm which configuration is active before editing

Open Config and check which configuration is selected before editing. Do not assume that a file with a familiar name is the one in use. A remotely sourced configuration, a local copy, and a temporary test file may have similar names but different contents. Test in a copy of the existing configuration, give it a recognizable local name, and note where it came from and why you changed it. Whether a later remote update overwrites local edits depends on how the file is saved. Put rules you need to keep in a clearly maintained location; do not assume every manual change will be merged with remote updates.

After saving your changes, return to Config and confirm that the file is selected. Then check that Global Routing is set to Config. Saving the text only confirms that it was stored; it does not confirm that every new request is using it. Existing connections may retain their previous handling, so test with a new request. If the client reports a parse error, fix it before testing connectivity. Do not confuse the results from a configuration that failed to load with those from the last working configuration.

Text format and minimal changes

Rules usually separate fields with English commas, and options usually connect keys and values with an English equals sign. Full-width commas from an input method, invisible spaces, and quotation marks copied from rich text can make otherwise similar text fail to parse. Use a plain-text editor and put one rule on each line. Do not append explanatory text as an unknown field. Chinese explanations outside code blocks are not configuration content; do not copy section numbers or line numbers with the examples.

Change one behavior at a time. For example, add just one DOMAIN rule and test the domain it should match. If you replace DNS, add a rewrite, move FINAL, and switch servers all at once, you will not know which change affected the result. A useful change log records what happened before, the exact line changed, and the test result—not just “optimized config.” Those details are more useful than a longer rule list when you need to roll back.

Domain rules match hostnames available during request handling, not the full URL shown in a browser's address bar. Including a scheme, port, or path in DOMAIN usually will not give the expected result. For a page on example.com, put only the hostname in the domain field. If you need to match a request path, assess whether URL Rewrite applies; domain rules are not designed to match paths.

DOMAIN: Match one exact hostname

DOMAIN,example.com,DIRECT sends requests for the hostname example.com through DIRECT. It does not automatically cover api.example.com, and it should not be read as “connect every resource on the site directly.” A page may request the main domain, a static assets domain, and an API domain. Loading the main page does not mean every request matched the same rule. DOMAIN is easy to verify and makes exceptions straightforward to remove later when you need to handle a specific API hostname.

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

This snippet sends api.example.com through DIRECT first, then routes example.com and its subdomains through PROXY. Put exceptions before broader suffix rules. Otherwise, the suffix rule matches first and the exact rule never gets a chance to apply. The result depends on rule order—not on DOMAIN being inherently “more specific” or higher priority than DOMAIN-SUFFIX.

DOMAIN-SUFFIX: Match a domain and its subdomains

Use DOMAIN-SUFFIX when you want to handle a domain and its subdomains as a group. DOMAIN-SUFFIX,example.com,PROXY matches example.com and its subdomains. Do not add a path or a leading asterisk. Suffix matching follows domain boundaries; a similar-looking string ending is not enough to establish a match. Choose the domain boundary you actually need, rather than expanding the scope to unrelated hosts just to save a few lines.

DOMAIN-KEYWORD: Broad matches require more care

DOMAIN-KEYWORD checks whether a hostname contains specified text. It does not search page titles, search terms, or web page content. DOMAIN-KEYWORD,example,PROXY matches on the keyword, but does not guarantee that the matched hosts belong to the same service. Shorter keywords are more likely to catch unintended requests. Prefer DOMAIN or DOMAIN-SUFFIX when you have a clear list of domains. Use a keyword rule only when you are comfortable with its broader scope.

Keyword rules can easily hide exceptions further down the list. When testing, check both a hostname you expect to match and a control hostname that should not match. If the keyword comes from a remote configuration, read the nearby rules and comments to see whether it relies on accompanying exceptions. Copying a single line without understanding its context can turn a limited match into a broadly applied rule.

A domain existing does not mean the client received it

Some apps connect directly to an IP address or select addresses internally. In those cases, the routing process may not have a hostname available to match. If the request log shows only an address, do not immediately assume DOMAIN-SUFFIX is wrong. First check whether the request used a hostname or only a destination IP, then decide whether an address rule is needed. Guessing which domain an IP belongs to can lead to the wrong conclusion, especially with shared addresses or dynamic DNS.

A redirect can also send a follow-up request to a different hostname. The initial domain may match as expected while later resources use a different policy. Check the actual hostnames in the request log rather than relying on the website name you remember. For more on broad rules and exceptions, read Custom Rules, Matching Order, and FINAL, then return to this section to narrow down the match scope.

Address rules match destination addresses, not webpage language, user location, or provider names. If a request has not matched an earlier domain rule, an address condition may be evaluated next. If an earlier rule has already matched, a later IP-CIDR or GEOIP rule will not choose a new policy for that request. This distinction helps separate “the address classification is unexpected” from “the request never reached the address rule.”

IP-CIDR: Use a network prefix to specify an IPv4 range

CIDR combines an address with a prefix length after the slash. A longer prefix means a smaller range. 192.168.0.0/16 represents a private address range, while 192.168.1.10/32 represents one IPv4 address. Do not put a port in the address field or use a hyphen to specify a range. Before setting DIRECT for a local device, check its actual address and subnet. Do not assume your network uses the private range shown in an example.

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

These rules illustrate private-address matching; they are not a complete allowlist for local networks. LAN access also depends on system network permissions, device firewalls, listening addresses, and routing. A DIRECT match only means the request is not sent through the selected proxy. It does not guarantee that a printer, file share, or local service is reachable. Check that the target service is running and that other devices on the same network can access it.

no-resolve: Avoid triggering DNS resolution just for this match

The no-resolve option at the end of an address rule avoids triggering DNS resolution solely to try to match that rule. It does not “disable DNS for the whole client” or “ignore all existing address information.” Address rules may still apply when a request already uses an IP address or an address is available during processing. So no-resolve cannot fix every DNS issue, and it is not a switch that forces domain rules to take priority.

This option is commonly added to local-address rules to avoid triggering extra DNS lookups just to check whether each unresolved domain belongs to a local subnet. The actual effect still depends on what information is available when the request reaches the rules. If a domain never matches the local-address rule, check the resolution result and request log. Do not simply remove the option and treat an incidental change as a definitive fix.

GEOIP: Address database classification, not service ownership

GEOIP,CN,DIRECT selects DIRECT based on the region classification in the address database. CN is a rule parameter; it does not mean “Chinese-language websites” or “all services aimed at a region.” A single host may use multiple addresses, and a content delivery network may return different addresses depending on the network used. Those addresses may have different classifications, and database records can lag behind real-world network changes. Treat GEOIP as a broad condition, not an exact way to identify a service.

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

In this snippet, the domain rule determines how example.com is handled first. Even if its resolved address falls under the CN classification, the later GEOIP rule cannot change the result to DIRECT. Only requests that have not matched a domain rule may reach GEOIP. For a service that needs a fixed policy, use a clear domain rule for known hosts, then let GEOIP handle remaining requests. The result will be easier to explain and maintain.

Check IPv6 separately; IPv4 rules do not cover it

IPv4 and IPv6 are different address families. An IP-CIDR rule alone does not cover IPv6; use IP-CIDR6 to specify an IPv6 prefix. When a domain returns both types of address, the address the app uses also depends on the system and network. A successful connection only confirms that the route used this time worked; it does not prove the other address family works too. Record the actual destination address, then check the relevant rule and network connectivity for each family.

A rule condition determines whether a request matches; the policy determines what happens next. PROXY, DIRECT, and REJECT are different handling outcomes, not service quality levels or protocol names. Shadowsocks, VMess, VLESS, Trojan, Hysteria2, and WireGuard describe connection methods. Using one of these protocols does not give PROXY extra priority in a rule. Check conditions, policies, and connection endpoints separately rather than changing protocols to mask a rule problem.

PROXY, DIRECT, and REJECT

PROXY sends a request through the handling path associated with the current proxy selection. Whether the connection succeeds also depends on your existing server details, authentication settings, and server availability. DIRECT connects to the destination directly; it does not bypass every system network restriction or guarantee that DNS behaves exactly as it would with the client off. REJECT blocks matching requests. Use it only for targets you intend to block; rejecting a host an app needs can cause loading failures, repeated retries, or missing content.

Config, Proxy, and Direct in Global Routing set the overall mode. PROXY, DIRECT, and REJECT in rule lines are policies within the configuration; read their capitalization and meanings separately. To check whether a Rule works, start with Config. If switching to Proxy restores access, that only suggests the issue may involve configured routing or the direct path; it does not prove a particular rule is invalid. Restore the original mode after testing so later checks use the same conditions.

USER-AGENT depends on a visible request header

USER-AGENT rules match available User-Agent content, not an app icon, app name, or system process name. Apps can use different request headers or change them in an update, and multiple programs may use the same header. Treating a string as a permanent identifier for an app is unreliable. Use this type of rule only after observing the actual request header and confirming the client can read it for the relevant request.

[Rule]
USER-AGENT,ExampleClient*,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,PROXY

ExampleClient here is a teaching string, not the name of a real app. The asterisk represents a wildcard. If the request header is not visible, this rule cannot match as expected. HTTP headers in encrypted connections are generally not readable through ordinary forwarding. Seeing a User-Agent in browser developer tools does not prove the client can see it during rule evaluation. Do not expand certificate trust or enable unnecessary traffic decryption just to test a USER-AGENT rule.

A matching policy does not guarantee a successful connection

If the request log shows PROXY, that confirms the routing choice; it does not mean the remote end has completed authentication, resolution, or connection to the destination. Next, check the server address, port, authentication method, and transport settings against your existing service details. If the log shows DIRECT, that confirms a direct route was selected; changing a rule name will not fix a local network that cannot reach the destination. If it shows REJECT, first find which rule blocked the request rather than testing the server.

When only part of a page loads, inspect failed and successful resources separately. An app may make multiple requests handled by DIRECT, PROXY, and REJECT. “The app opens” is not a complete test, and “the app does not open” does not prove that one particular rule is at fault. Compare each actual hostname, matching rule, and policy to identify whether you need to change the condition scope, rule order, or connection settings.

For routine maintenance, prefer domain or address conditions to express stable network boundaries. Reserve USER-AGENT for limited cases you can verify. Rules that depend on request details need more retesting when reused across apps and platforms. If an existing configuration contains an unfamiliar custom policy name, find where it is defined and used first. Do not rename it to PROXY and assume the configuration is equivalent, or assume that every name is a built-in client policy.

Rule checks conditions from top to bottom, and the first match determines the handling policy. The client does not collect every matching result and then choose whichever rule looks most specific. Exact domains, suffixes, keywords, and address ranges have no fixed priority that overrides line order. If a rule appears not to work, do not start by adding another copy of the same condition. First look above it for a rule that already matches the request.

Put explicit exceptions before broader conditions

Suppose example.com and its subdomains should use PROXY, but api.example.com should use DIRECT. Put the specific exception first, followed by the suffix rule. In the reverse order, api.example.com matches the suffix rule before the DOMAIN rule can change the result. The same principle applies to REJECT: place necessary exceptions before broad blocking rules, and make sure those exceptions do not cover more hosts than intended.

[Rule]
DOMAIN,api.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

Step through the rules one line at a time: api.example.com is handled by the first line; blocked.example.com is rejected by the second; other example.com subdomains use PROXY under the third. If the destination is a private address and no earlier domain rule matched, the fourth line may select DIRECT. Remaining requests continue to GEOIP, and only those that still do not match reach FINAL. Use the actual request conditions when tracing the rules, not just the line you hope will match.

FINAL is a fallback, not a patch

FINAL,PROXY has no additional match condition. It handles requests that did not match earlier rules, so it belongs at the end of Rule. Moving FINAL up intercepts all remaining requests partway through the list, leaving later ordinary rules with no chance to match. Choose the FINAL policy deliberately: PROXY and DIRECT represent different default routes. Another configuration's last line does not tell you which is right for your network.

For easier maintenance, keep one clearly defined FINAL in a Rule section. A common merge mistake is pasting the first configuration—including its FINAL—before the second, so most of the second configuration's rules can never match. After merging, find every FINAL, move a single fallback to the end, then check for duplicate rules and conflicting scopes. File length and rule count alone do not show whether the merge worked.

Duplicate rules, conflicting rules, and misleading order

When the same condition appears more than once, the first rule usually determines the result. A later rule with a different policy does not become a “fallback policy.” For example, two identical DOMAIN rules—DIRECT followed by PROXY—do not mean that a failed direct connection will retry through the proxy. Rule matching is not a retry mechanism. To change the policy, edit the rule that actually matches first rather than appending a different result below it.

Sorting rules alphabetically can change their meaning. A tidy-looking sort may move exceptions below broader conditions; grouping by rule type carries the same risk. A practical order is to put specific exceptions first, then domain groups, then address ranges and region classifications, and finally the fallback. This is an organizational aid, not a mandatory template that every configuration must copy.

Use a match table instead of guessing

Before making changes, list three to five test destinations: a host that should connect directly, one that should use a proxy, one that should be rejected, and one that should fall through to FINAL. Write down the expected matching line for each, then verify with new connections. If actual results differ, first check whether the hostname and address match your expectations, then trace the conditions line by line. This can reveal order problems as well as redirects, changed resource hosts, or address-family differences.

If the configuration references external rules, consider where those references are evaluated and what their current contents are. The same reference name does not guarantee that its contents stay the same; an update may expand its scope and catch requests that previously reached FINAL. Review more than the lines visible in the local file. For a fuller ordering example, see the guide to rule priority and FINAL. Then check the actual order in the active configuration.

General contains options that apply across the configuration; it is not a place to write all rules in another format. DNS, network behavior, and platform-specific parameters may be configured here, but client interfaces and platform implementations vary. Do not copy every field from another configuration. Even if an unknown key does not produce an obvious error, that does not prove it is active. Start with settings the current client confirms it supports, then add only options you actually need.

DNS answers the question: “What address does this hostname resolve to?”

DNS resolution converts a hostname to an address; rules determine how a request is handled; the connection stage attempts to reach the destination. These steps are related but distinct. Getting a DNS result does not mean the destination is reachable, and matching PROXY does not guarantee that DNS used the same route. To troubleshoot, ask whether an address was resolved, which policy was selected, and where the connection failed. This is usually more effective than replacing the entire configuration.

[General]
dns-server = system

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

dns-server = system is a starting example that uses system DNS; it is not suitable for every network. It provides a simple baseline: keep the system's DNS behavior and check only whether rules work as expected. If your existing configuration uses another supported DNS setting, note its exact parameters and previous results before temporarily switching to the baseline. Do not clear General without understanding why its current settings are there.

Resolution results can change the input to address rules

The same domain may resolve to multiple addresses, or return different results depending on network location and cache state. If a domain rule matches the hostname, changes to its address usually do not affect that domain condition. GEOIP and IP-CIDR, however, depend directly on address information, so changed results may affect whether they match. If the address changed between tests, do not attribute every policy change to a rule you just moved. Record the destination address each time.

Browsers, apps, the system, and the client may each keep their own cache or connection state. Refreshing a page immediately after changing DNS may not create a fresh lookup or connection. Try ending the target app's current activity, then make a new request and check the client log for a new timestamp and destination. Do not repeatedly clear all data instead of observing what happened. If you cannot tell where a cache is stored, preserve the current state and troubleshoot the smallest possible scope first.

Do not confuse local DNS resolution with resolution on the server side

Some connection methods can pass a hostname to a remote server for handling; others may resolve the address locally first. The behavior depends on the protocol, configuration, and request type. Seeing PROXY does not prove that every lookup happens on the server side, and seeing a local DNS record does not prove that business traffic bypassed the proxy. Check DNS requests separately from the subsequent destination connection, and do not treat two requests with different purposes as the same traffic.

The server address in your existing server details may itself be a hostname. If it cannot be resolved, the client may not be able to connect to the proxy endpoint at all; accurate rules for the destination domain cannot fix that. Troubleshoot in order: resolve the server address, check the port and authentication, then check the destination site. Logging the server hostname separately from the service hostname helps avoid repeatedly changing the wrong domain rule.

Bypass options and DIRECT operate at different levels

Some network exclusion or bypass options in General may keep certain traffic out of the usual Rule evaluation path. DIRECT is a policy result for traffic that does reach rule evaluation. If a request does not appear in the expected logs at all, check system network capture and related bypass settings instead of just adding DIRECT to Rule. Check the current client documentation for supported fields; platform-specific options are not universal requirements.

When maintaining General, record the purpose of each setting—for example, “use system DNS as a baseline” or “preserve existing LAN behavior.” Keep the original value of options you cannot explain and test them individually in a copy instead of filling in every field from a longer configuration. More fields do not mean broader support. A configuration that is understandable, testable, and reversible is easier to keep working. If you have not established a basic connection, return to the getting started guide to check your server and connection before changing DNS behavior.

Host and URL Rewrite often appear together in configuration files, but they act on different things. Host changes the address mapping for a specified hostname. URL Rewrite applies an action to visible request URLs that match an expression. Neither means that changing a domain will make the same service accessible. The destination server still needs to accept the hostname, the certificate must match, and the app must follow redirects as expected.

Host: Use static mappings only for a clear purpose

[Host]
example.com = 192.0.2.10
api.example.com = 192.0.2.20

This example maps two hostnames to documentation-only addresses to show the key-value format. It is not for real-world access. Static Host mappings can be useful in a test environment you control. Do not enter an address found online just to “speed things up” without confirming its purpose. A domain may be served by multiple backends; pinning it to a single address can bypass normal routing or keep pointing at an unavailable destination after the address changes.

A Host mapping generally does not replace the hostname in a request with an address string. The request may still carry its original hostname, and TLS validation still needs to match the relevant domain. Mapping a hostname to an arbitrary server will not make that server provide the original service. If a certificate mismatch occurs, check the address and service configuration rather than disabling certificate validation to hide a mapping error.

Host does not replace Rule-based routing

A static mapping for a domain does not automatically make it DIRECT. The request policy still depends on the current mode and the available hostname and address rules. If you want a test host you control to use a fixed address and connect directly, express those as separate intentions: Host supplies the address, and Rule specifies DIRECT. Keeping the mapping and policy separate also lets you remove each one after testing, without leaving an unnoticed static address behind.

URL Rewrite: Understand the regex before choosing an action

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

This example exactly matches a visible, unencrypted HTTP URL and uses a 302 action to redirect an old path to a new one. The dot in the regular expression must be escaped; otherwise it matches any character. The caret at the start and dollar sign at the end limit the match to the entire URL. This expression only covers the example's old path; it does not automatically cover URLs with query parameters or other trailing content. The broader the match, the more likely it is to affect requests you did not intend to rewrite.

A 302 is a redirect, not a direct edit to a file on the destination server or a permanent data migration. After receiving the redirect, the client makes another request. That request may be routed again and is affected by caching, the app's redirect behavior, and the destination service. If an app ignores redirects or accepts only certain responses, a successful browser test may not mean the app's own request will work.

Do not overlook the limits of HTTPS

HTTPS paths and HTTP headers are generally encrypted, so ordinary proxy forwarding cannot directly inspect the full URL. Do not assume the HTTP example above will work simply by changing it to HTTPS. Handling encrypted traffic involves additional configuration and trust boundaries. It is not a prerequisite for basic routing, and expanding certificate trust is not a recommended first step for fixing ordinary rule problems. If you only need domain-based routing, use domain rules.

Rewrites can also create loops. For example, a new URL may be changed back to the old one by another expression, or an overly broad expression may match its own replacement. During testing, watch the URL changes and successive responses to confirm that the redirect stops after one hop. Avoid enabling multiple rewrite sources that target the same URL. If you cannot explain what each rule does, test one at a time in a copy and restore them individually after confirming the result.

When reverting, check all three states

After removing a Host mapping, cached DNS results or existing connections may temporarily retain the old address. After removing URL Rewrite, an app may also retain a redirect result. A complete rollback means restoring the configuration, making a new request, and checking the actual address and path. If the issue persists, determine whether you are seeing an old connection or new behavior before adding more rules. For production use, test on a host you control before applying changes to your everyday configuration.

When combining the sections above, the goal is not to create the largest possible rule list. It is to create a configuration that explains how each important request is handled. Start by identifying the necessary exceptions, then choose a default policy. Change DNS or Host only for a specific reason, and test URL Rewrite separately. Before you begin, confirm that at least one server in your existing subscription works, so a server problem does not get confused with a routing issue.

A combined example you can verify line by line

[General]
dns-server = system

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

This snippet shows how to organize exact exceptions, blocked destinations, suffix matching, local addresses, region classification, and a final fallback. It contains no proxy endpoint and is not connection information that can replace a subscription. Before using it, map every condition to a destination you actually need to handle. Remove example rules that do not apply. In particular, add REJECT to a production configuration only after confirming that the target should be blocked.

Confirm the file first, then the mode

1. In Config, confirm which file is selected, check that your rule changes are in that file, and look for parse errors.
2. Set Global Routing to Config and note the currently selected server. Do not switch servers during the same rule test.
3. End the target app's old connections, make a new request, and record the actual hostname, destination address, matching condition, and handling policy.
4. Compare the actual match with the expected line number. If they differ, look above for a condition that matched first. If they agree, check the connection, resolution, and destination service.

If every destination uses the same policy, first check the global mode and where FINAL appears. If only one host is affected, check the exact hostname, any hostname change after a redirect, and address changes. If the entire proxy route fails, first check the selected server details and network state. Different scopes of problems require different checks; adding DOMAIN-SUFFIX is not a universal fix.

Choose the next step based on what you observe

Connectivity Test can help determine whether an endpoint responds, but it does not replace testing the complete request path to a website. A successful test does not prevent a service request from failing because of DNS, rules, authentication details, or destination restrictions. Conversely, an unexpected test result does not prove that all service connections are unavailable. Record the test target and method separately from what happens in the actual app.

Rollback, updates, and reuse across devices

After each change, test at least one destination expected to match and one control destination that should be unaffected. If something regresses, return to the last working configuration and confirm that the change caused the issue. Then restore one change at a time. Repeat these checks after remote configuration updates, especially for new broad rules, FINAL placement, and DNS settings. The filename staying the same does not mean its behavior has stayed the same.

When reusing a configuration across devices, carry over the intent of the rules first, then check field support and the network environment. Address ranges may differ between mobile, home, and desktop networks, and system network capture can vary by platform. Identical text does not guarantee identical results on every device. Treat the rules as a reference and recheck platform-specific settings. Find platform options on the download page, basic connection steps in the getting started guide, and common issues in FAQ.

Keep the details needed to describe an issue

A reproducible report should include the current mode, selected configuration, relevant redacted rules, actual hostname or address, expected and actual policies, and what changed. Do not share a full subscription URL, authentication fields, or logs containing private data. If you need to show configuration text, include only the relevant sections and remove credentials. Someone can assess whether the issue involves order, settings, or connectivity only if they can trace the request line by line.

The final check comes down to three questions: Which configuration handled the request? What was the first matching condition? Where did the connection fail after the match? The first two questions concern configuration behavior; the last concerns network and endpoint verification. Keeping evidence in this order helps avoid blaming every issue on “broken rules” and lets the next round of maintenance build on what you have already established instead of replacing the whole file.