Shadowrocket
Rules & Config Reference

01 / File Structure

Config File Structure: Four Sections, Four Roles

Shadowrocket config files organize settings in sections. Section names in square brackets define each section's purpose; the contents can include parameters, rules, or mappings. When reading a file, locate [General], [Rule], [Host], and [URL Rewrite] first, then review what each section contains. A config file is not another name for a server list: servers establish connections, while configs determine how requests are handled. Both need to be understood in the context of the current runtime state.

Section names determine how their contents are interpreted

[General] contains config-level parameters, usually as key-value pairs. [Rule] contains routing conditions checked in order. [Host] maps specified hostnames to local addresses. [URL Rewrite] handles request URLs that match an expression. Putting a valid rule in the wrong section does not make it a working routing rule. When troubleshooting, check which section the entry belongs in before assessing whether the rule is precise.

# Section layout example; not a complete connection config
[General]
dns-server = system

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

[Host]
test.example.com = 192.0.2.10

[URL Rewrite]
^http://example\.com/ https://example.com/ 302

These four sections show different syntax; they do not mean every config needs all four. You can omit Host entries if you do not need local mappings, and URL Rewrite entries if you have no specific URL rewriting goal. A minimal config is easier to explain: every setting should serve a real need, not just make the file look complete.

Manage configs, server details, and subscriptions separately

Your server details typically include an address, port, protocol, and authentication parameters. A subscription lets you import or update these entries in one place; a config separately describes how traffic is routed. A successful import only confirms that some content was added to the app. It does not confirm that a server can connect, that the config is selected, or that its rules behave as expected. Check each of these separately; “subscription updated” does not mean “the correct config is active.”

In the app's Config, check the active config's name and contents, then return to Home to review Global Routing. Saving a local file does not make it the active config. Remote configs and local copies can have similar names, so confirm which one you are editing. If a config comes from a source you manage, check whether future updates will overwrite local changes. To preserve an experiment, save a clearly named copy first.

Create a rollback point before editing

Before maintaining a long config for the first time, note which destinations work, which server is selected, and the current Global Routing mode, then save the original file. Don't change DNS, reorder every rule, and add URL rewrites in the same experiment. When results change, making one change at a time helps identify the cause. When commenting a config, explain why an exception is needed rather than restating the rule. For example, note that an internal host must use the local network.

Check syntax too: use English commas, spell section names correctly, and watch for unexpected line breaks or full-width characters introduced during copying. Put comments on their own lines so they are not mistaken for fields. Add rule snippets in batches, check the app's response after saving, then start a new connection for testing. For a quick overview of each section, see What Each Config Section Does. The rest of this guide explains matching behavior and validation.

02 / Runtime Conditions

General: Runtime Parameters and DNS

General provides config-level runtime conditions; it does not replace Rule when deciding how to route each destination. To investigate why the same rule behaves differently, check domain resolution, the target address, the current network, and the active config together. This is especially important for IP-CIDR and GEOIP rules, which depend on having a target address. Looking at a rule without considering how the address was resolved rarely explains the full result.

Start by reviewing only the parameters you need

Parameters in General use key-value pairs. Don't paste a long list of settings from elsewhere into an existing file: some options change name resolution, network handling, or address processing. When reviewing an unfamiliar parameter, check its description in the app and confirm that it is relevant to the issue. Leave settings unchanged if you have no clear reason to modify them; don't change several runtime conditions at once in the name of “optimization.”

[General]
# Use the system DNS settings
dns-server = system

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

This snippet only shows that DNS settings and the Rule section are separate. dns-server = system uses the system's DNS settings; it does not mean every domain will resolve to the same address or that resolution will be identical across networks. Network changes, DNS caches, and a destination's own address selection can all affect the response. When investigating a request, use information that can be verified for that specific request.

Domain rules and IP rules require different information

DOMAIN rules need an identifiable hostname; IP-CIDR and GEOIP rules need address information. A request made to a domain may match a domain rule first, or address resolution may become relevant during further checks. You cannot assume that a domain “belongs to a region” and must therefore match a GEOIP rule: GEOIP checks an address against a database, not a website's name or registration details.

The DNS resolution path and the path used for the subsequent connection are separate questions. Seeing a DNS request does not prove that the following web connection uses the same route; seeing a request match PROXY does not mean all DNS queries use the same server. When troubleshooting, record address resolution and the destination connection as separate stages to identify where the failure occurs. Don't attribute every timeout to a rule.

Check IPv4, IPv6, and caches separately

An IPv4 subnet rule does not automatically cover IPv6 destinations. If a connection uses IPv6, check IP-CIDR6 and its associated policy instead of broadening the IPv4 range. The same domain may use different address families for different requests. You don't need to disable an address family to verify a config: first record the actual destination address, then check which rule applies to it.

Caches and existing connections can delay the visible effect of a change. The app, browser, and network layer may each retain information, and an existing long-lived connection may not restart when you save a config. After a change, confirm the config is still selected, then close the test destination's old session or make a new request. Whether you need to reconnect depends on the setting and the app's prompt; repeatedly toggling the connection is not the only way to troubleshoot.

Network conditions are separate from the rules

A captive login page on the local network, a Wi-Fi network that cannot reach a destination, or a server hostname that fails to resolve can make a syntactically valid config appear unusable. Adding more DOMAIN-SUFFIX rules will not fix an underlying connection issue. First confirm the device is on a working network, then check whether your server is reachable and its authentication details are correct, and finally test traffic routing for the destination. This sequence helps separate rule issues from network issues.

When maintaining General, note the network type, DNS settings, and test destinations before and after each change; do not record real authentication details. If an issue occurs on only one network, keep the other network as a comparison and check one variable at a time. See Getting Started for permissions and first-run steps, and Routing Modes for Global Routing options. Don't use runtime parameters to compensate for unverified server or permission issues.

03 / Hostname Matching

DOMAIN, DOMAIN-SUFFIX, and DOMAIN-KEYWORD

Domain rules express which policy should apply to a host or group of hosts. The three common types differ in scope, not in sophistication. Use DOMAIN for a precise exception, consider DOMAIN-SUFFIX to include a root domain and its subdomains, and use DOMAIN-KEYWORD only when you need a broad match on part of a hostname. The broader the scope, the more carefully you should check for unintended matches.

DOMAIN: Create an exception for one host

DOMAIN,api.example.com,PROXY matches the full hostname; it does not automatically cover other hosts just because their names contain example. Enter only the hostname in the rule field—no protocol, path, query string, or port. Pasting https://api.example.com/login into DOMAIN does not mean “proxy only the login page.” Path handling is a separate concern; first decide whether URL rewriting is actually needed.

[Rule]
# Exact exception for one host
DOMAIN,api.example.com,PROXY
DOMAIN,intranet.example.com,DIRECT
FINAL,DIRECT

This is a good way to start with a small test. Once the policy for one host is correct, decide whether to extend it to other domains used by the same service. A page may load resources from separate hosts for APIs, images, and authentication, so a match for the main page does not mean every related request matches too. If only part of a page loads, check the actual hostname of the failed resource rather than immediately applying the same policy to an entire domain group.

DOMAIN-SUFFIX: Match a domain and its subdomains

DOMAIN-SUFFIX,example.com,PROXY matches example.com and its subdomains, such as api.example.com. It matches domain suffixes, not arbitrary strings ending in the same text: notexample.com is not a subdomain of example.com. You usually do not need to add an asterisk to the field. Understanding this distinction helps avoid confusing wildcard syntax with the rule's own matching behavior.

A suffix rule has broad coverage, so check whether the domain includes internal services that must connect directly. For example, if an internal admin host and a public API share a root domain, put the exact DIRECT exception first, followed by the root-domain PROXY suffix rule. If the order is reversed, the internal host matches the earlier suffix rule and the exact exception never gets a chance to change the result.

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

DOMAIN-KEYWORD: Scope depends on the text fragment

DOMAIN-KEYWORD,ads,REJECT matches a keyword in the hostname. It does not understand the word's meaning or determine whether a request is actually an ad. Any hostname containing that fragment may match, so short keywords are more likely to block legitimate services. This example explains the syntax; it is not a blocking recommendation for every network. For real configs, prefer exact hostnames or suffixes that you have verified.

If you need to keep a legitimate host containing a keyword, put an exact exception before the keyword rule. If you keep adding exceptions, reconsider whether the keyword rule is too broad instead of patching it indefinitely. The goal is to align conditions with requirements, not make an overbroad rule usable through a growing list of exceptions. Readability and ease of validation matter too.

If the hostname isn't visible, don't guess at new rules

A request may not expose the hostname you expect. When a destination is accessed by address, another layer handles the request, or connection details are incomplete, a domain condition may not match as expected. First check the destination information visible in the app, then decide whether an IP rule is needed. Seeing a hostname in the browser address bar does not prove that every connection made by the page includes that hostname for matching.

Use English commas to separate fields in domain rules and code examples. Put each host in its own rule rather than combining several in one field. For internationalized domains or differences in hostname formatting, test against the form you can verify in the actual request. For brief definitions of terms such as DOMAIN and FINAL, see the Glossary. This section focuses on scope and exceptions.

04 / IP and Request Attributes

IP-CIDR, GEOIP, and USER-AGENT

When a requirement targets a destination address, subnet, or request attribute, a domain rule may not be the right tool. IP-CIDR describes a set of IPv4 addresses; IP-CIDR6 describes IPv6 addresses; GEOIP classifies an address using a geolocation database. USER-AGENT depends on available request header information. Each rule type requires different input, so these are not simply alternative spellings of domain rules.

IP-CIDR: Define an address range with a prefix

192.168.0.0/16 represents an IPv4 subnet; the number after the slash is the network prefix length, not a port. A longer prefix covers a smaller range. Use /32 for a single IPv4 address. Before writing a rule, confirm which address the destination actually uses. In particular, don't confuse the server address or the device's own address with the destination address: standard destination-routing rules check the request's target.

[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

This snippet illustrates how to write a private address range; it does not guarantee that every local service will be reachable. The device's network routes, the server's listening address, firewalls, and bypass settings in the app can all affect the result. Some traffic excluded before rule processing will not reach these entries at all. When troubleshooting a local service, also confirm that the device can reach that address.

no-resolve: Don't trigger a lookup for this rule

The no-resolve option at the end of an address rule prevents the rule from triggering a DNS lookup just to check for a match. It does not disable DNS for the entire config, and it does not discard address information that is already available. If a request has only a hostname and no usable address, an address rule with this option may not match; later rules will handle the request, so suitable domain rules and a FINAL are still important.

A common reason to use it on local subnet rules is to avoid triggering extra lookups for large numbers of ordinary domains just to check for private subnet matches. Whether it fits your config depends on the request details and resolution behavior. If an internal domain must connect directly, consider adding an explicit DOMAIN rule and confirming that the name resolves correctly on the current network rather than relying on an address rule to happen to receive the information it needs.

GEOIP: Database location is not service identity

GEOIP,CN,DIRECT selects a policy based on the destination address's location in a database. It does not check the webpage's language, domain suffix, or the user's location, and it cannot verify which organization operates the destination. Geolocation data can be outdated or differ at boundaries, and a service may use addresses in multiple regions. GEOIP is better suited to broad categorization than identity verification.

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

This ordering sends the explicitly named host through PROXY first, then checks GEOIP for other requests. If a broad address classification comes first, a matching request may stop there, preventing a later domain exception from taking effect. When you need to reliably route a particular service, describe it by a verifiable hostname first and use GEOIP as a supplement. This is usually easier to explain and maintain.

USER-AGENT: Confirm the information is available

USER-AGENT matches visible request header content, for example USER-AGENT,ExampleClient*,DIRECT. ExampleClient is just a sample client identifier, not a statement about a real app. This is not the same as routing by app name; having an app installed on a device does not mean all its traffic will match the same request header pattern.

HTTPS encrypts request contents, so the rule processing path may not be able to read the User-Agent. Some requests do not include this field, and it may vary by app. Don't add decryption-related steps just to test ordinary routing. If you can describe the destination with a known hostname, use a domain rule first. If you need USER-AGENT, confirm that the relevant information is visible in the app and keep an explicit fallback for unmatched requests.

05 / Traffic Routing

PROXY, DIRECT, REJECT, and Global Routing

A policy in a rule determines what happens after a match; Global Routing determines the overall routing mode currently in use. These are separate layers. If a Rule does not appear to work, first check whether Global Routing is set to Config. If the current mode is Proxy or Direct, the usual order of rules in Config cannot explain the same request's result. Confirm the mode before investigating the policy.

What the three basic policies do

PROXY sends destinations that meet the routing conditions through the proxy path. Whether they connect still depends on the availability of your own server and related settings. DIRECT uses a direct path without the selected proxy server, but does not guarantee that the destination is reachable. REJECT blocks matching requests; it does not automatically switch to another path if the request fails. Each policy should serve a specific purpose.

The basic policies in config files use uppercase names to distinguish them from the Config, Proxy, and Direct options in the app. If your config uses custom policy names, check that each name is defined and what server or selection logic it points to. The minimal examples in this guide use only the three basic policies; they do not assume you have custom groups or need to create a complex setup for basic routing.

Config, Proxy, and Direct Compared

Config in Global Routing routes traffic according to the selected config's rules. Proxy routes traffic covered by the app through the proxy path; Direct uses a direct connection. “Global” does not mean that the app bypasses all system restrictions or handles every kind of traffic on the device. Actual behavior still depends on the system, the traffic the app handles, and related settings. This is a routing choice in the app, not a guarantee of a successful connection.

If you need direct access to internal services and proxy routing for specific destinations, Config is better suited to express those differences. Temporarily switching to Proxy can help check whether the proxy path works; switching to Direct can provide a direct-connection comparison. These are diagnostic steps, not fixes for a rule. Restore the intended mode after testing so subsequent results reflect the config's design.

FINAL handles requests that don't match earlier rules

FINAL,PROXY sends requests that did not match earlier rules through PROXY; FINAL,DIRECT uses DIRECT instead. FINAL has no domain or subnet field, so it should not be written as a regular three-field condition. Put FINAL at the end of the rules: any request that reaches it gets a fallback policy, and later conditions cannot affect that request.

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

This snippet sends destinations not listed explicitly through DIRECT; that does not mean this fallback is right for everyone. Before choosing FINAL, decide how the config should handle traffic by default, then add exceptions. Changing the fallback can affect many destinations, so validate more than you would for a single DOMAIN change. Testing just one explicitly matched hostname does not validate a new FINAL.

Check connection status, policy matches, and request success separately

A connected status only confirms the corresponding connection state; it does not mean every destination is accessible. A request matching PROXY only confirms that the proxy path was selected; authentication failures, timeouts, or destination rejections can still occur. Connectivity Test can help assess connectivity, but it does not replace checking the rules for a specific request. Track these three layers separately rather than treating one test as proof of another.

To get the app, check the developer and app ID on the App Store authenticity page first. Shadowrocket is a paid Apple-platform app, and the App Store is the only place to get it. See the App Store listing for system requirements. Buying the app and having your own server are separate things; a one-time client purchase is not a service plan. For a closer look at the modes, see Global Routing: How the Three Modes Differ.

06 / Priority

Rule Order: The First Match Determines the Result

Rules are checked in order, and typically the first matching rule determines the policy. Don't assume DOMAIN automatically takes priority over DOMAIN-SUFFIX, or that a more specific subnet overrides a broader condition above it. Specificity helps you organize the list; it is not a priority system independent of file order. To predict a result, work through the rules from the top, one line at a time.

Put exact exceptions before broader rules

Suppose example.com and its subdomains should use PROXY, but intranet.example.com must use DIRECT. Don't just add both rules; put the exact condition for the internal host first. intranet.example.com is also a subdomain of example.com, so if the suffix rule comes first, it matches and the later exact condition cannot change the result—even if it is written correctly.

# Exception first
[Rule]
DOMAIN,intranet.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT

Reversing the order changes the behavior even though only two lines have moved. This is why searching for “whether a rule exists” is not enough when troubleshooting: a rule can be present without ever being reached. After locating the target entry, check all earlier conditions that could match, including keywords, domain suffixes, address classifications, and an earlier FINAL. Any match above it can prevent the target rule from running.

Rules of different types still follow the same order

Domain rules and IP rules are not separate lists. Within the same Rule section, read entries in their actual order; the different types simply require different information. If an earlier domain rule matches, a later GEOIP rule will not change the result. An earlier IP rule can likewise prevent a later domain exception from being reached. When resolution is involved, also consider the address-information limits discussed in section 2.

“Specific to broad” is a useful way to organize rules: exact host exceptions, domain groups, necessary address ranges, broad classifications, and FINAL at the end. But it is not a template you must follow. For example, if a verified host must be rejected, its exact REJECT rule may need to come before a domain suffix rule that would otherwise allow it. Order depends on the priority of your requirements, not the policy's color.

How to handle duplicate and conflicting entries

If the same condition appears twice with the same policy, the later entry usually just makes the config harder to read. If the policies differ, the earlier matching entry still determines the result. First identify where duplicates came from, then decide which one to keep; don't simply delete the line that looks older. Some entries may come from updated content, so if you don't address their source, they may return in the next update.

Overlapping scopes are not necessarily wrong. An exact exception can intentionally overlap a suffix rule, as long as the priority is clear. Overlap with no clear purpose often means a config has been assembled from several sources. Group rules by purpose and note why exceptions exist. Don't sort by domain name alone; that can silently change behavior that depends on order.

Use a test matrix to check each path

For the example above, test at least three kinds of destinations: the exact exception host, a regular host under the same domain, and a host unrelated to that domain. These test the DIRECT exception, the PROXY scope, and FINAL, respectively. Add a hostname that looks similar but is not under the suffix to check that you understand the match boundary. Example hostnames do not need to resolve to a real service; for connectivity testing, use destinations you have confirmed exist.

For each test, record the destination, expected matching condition, expected policy, observed result, and stage of failure. If the expected rule does not match, check the earlier conditions that may override it. If the rule matches but the request fails, check the route and destination service. After changing the order, start a new test connection to avoid interference from an old session. These notes make issues easier to reproduce than adding more similar rules, and make it easier to recheck the config after updates.

07 / Mapping and Rewriting

Host and URL Rewrite: Not Substitutes for Routing Rules

Host changes the address associated with a specified name; URL Rewrite handles request URLs that match an expression; Rule determines the policy to use. All three can appear in one file, but they are not interchangeable. If a host needs DIRECT, express that in a routing condition. Don't map the host to a fixed address just to make it connect directly, or rewrite it to an unrelated service.

Host mappings set a fixed name-to-address relationship

For example, test.example.com = 192.0.2.10 shows a static mapping from a hostname to an address. The address is for documentation examples and is not a real, reachable service. Host entries do not include PROXY, DIRECT, or REJECT fields. The policy for a later connection still depends on Rule and the actual request details. Treating a successful address mapping as a successful routing result can hide the real issue.

[Host]
test.example.com = 192.0.2.10

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

Static mappings are for limited cases, such as a test environment you manage. Public services may use dynamic addresses, load balancing, or failover; a fixed address can break connections over time or bypass routing that should adapt to network changes. Add a mapping only when you can verify who manages the address, what it is for, and who will maintain it, and note when to remove it. Don't permanently add an address just because it worked once.

A mapping does not remove certificate or service identity checks

Mapping a hostname to another address does not give the service at that address the original hostname's identity. HTTPS still checks details such as the certificate and request hostname. If the destination service is not configured for that hostname, the result may be a certificate mismatch or a rejected request. Don't ignore identity checks to “prove the mapping works”; instead, confirm that the address, hostname, and service configuration match.

If behavior differs from what you expect, also check whether the app is using this resolution information, whether an existing connection still has the old address, and whether another mechanism resolved the destination. Remove the mapping for a comparison, then restore it and start a new connection. Only investigate its interaction with IP rules after confirming that Host caused the difference. Otherwise, changing both the mapping and routing rules at once makes the results hard to explain.

The three parts of a URL Rewrite

A common redirect format has a matching expression, a replacement destination, and a status code, separated according to the relevant syntax. The example below replaces the HTTP prefix for a specific host with HTTPS and uses a 302 redirect. The dots in the expression are escaped with backslashes so they are not treated as wildcards. The leading ^ anchors the match at the start of the request URL and helps avoid unintended matches.

[URL Rewrite]
^http://example\.com/ https://example.com/ 302

This snippet explains the syntax; it does not replace a website's correctly configured HTTPS. The match includes the slash, so inputs without a trailing path slash, with a different port, or with a different hostname may not be equivalent. Test the homepage, a request with a path, and one with query parameters to confirm that the replacement destination is correct. The broader the expression, the more important it is to test inputs that should not match.

Avoid loops and rewrites beyond what you can observe

If a rewritten URL matches another rewrite, it may redirect repeatedly or loop between two addresses. Before adding a rule, write down the original URL, the first replacement, and any conditions that could match afterward. Browsers may cache redirects, so account for that when debugging; a cached redirect does not prove the current config is still active. After removing a rule, test a new request again.

Encrypted request paths are not automatically visible to rule processing, and URL Rewrite does not guarantee that arbitrary HTTPS content can be changed. This guide does not require extra decryption capabilities for ordinary routing. To change a traffic route, use Rule; to understand which address a name resolves to, check Host; use URL Rewrite only when you need to manage URL transformations. Keeping these boundaries clear makes it easier to identify the cause of a problem.

08 / Maintenance Loop

Config Validation: From Minimal Examples to Reversible Changes

The goal of config validation is not just to see a page load once. It is to confirm that the expected rule produces an explainable result under the expected conditions. A complete process means saving the original config, confirming the active routing mode, changing one item, starting a new request, checking the rule match and connection result, and keeping a rollback option. Separate each stage to reduce misdiagnosis and make it easier to retest after a subscription or config update.

Step 1: Confirm what is actually active

On Home, check the connection status, selected server, and Global Routing mode. Then go to Config and confirm which file is in use. If filenames are identical or similar, inspect the contents rather than relying on the name. Keep your server parameters consistent with your own source. In particular, don't change the protocol, port, or authentication fields while validating rules; otherwise, you won't know what caused a change in the connection result.

If you have not made a successful connection yet, start with Getting Started instead of importing a config full of rules and rewrites. For app acquisition or restoring a purchase, see Restore a Purchase, not Rule. The developer listed for the App Store app is Shadow Launch Technology Limited, and the app ID is 932747118. See the App Store listing for system requirements.

Step 2: Reduce the config to an explainable example

When something goes wrong, keep the original file and work on a copy containing only the conditions relevant to your test destination and an explicit FINAL. First test an exact DOMAIN rule, then gradually restore suffix rules, address classifications, Host, and rewrites. Don't delete your only working config or overwrite a remote source with a test copy. Minimizing the config helps rule out interference; it does not mean you should always use only two or three rules.

[Rule]
# Replace example.com with a test host you have verified exists
DOMAIN,example.com,PROXY
FINAL,DIRECT

For this test structure, choose one destination that should match DOMAIN and another that should not, to check FINAL. If neither result matches expectations, first confirm that Global Routing is set to Config and that the copy is selected. If only the PROXY destination fails, check the proxy path. If the DIRECT destination fails, check whether the current network can reach it directly. One failure does not disprove the entire config syntax.

Step 3: Distinguish four common failure types

Connection records or logs available in the app can help verify the destination, policy, and failure stage. Their presentation depends on the current app interface. If a record shows only an address, don't assume a hostname; if it shows only a hostname, don't claim it necessarily belongs to a particular subnet. Connectivity Test can help assess connectivity, but test a specific webpage or API separately.

Step 4: Check update overwrites and rule regressions

Check subscription updates and config updates separately. Updating existing server entries does not necessarily change the active Rule; updating a remote config may reorder or replace local changes. After each update, retest at least three kinds of destinations: an exact exception, a common scope, and FINAL. If you use Host or URL Rewrite, also test mapped destinations and redirect boundaries. Don't finish maintenance after confirming that only the main page loads.

A maintenance log can record the reason for a change, the old and new rules, and expected and observed results. Do not include full subscription URLs, authentication details, or other sensitive information. Before sharing a problem, replace real hostnames and credentials while preserving rule order, field structure, and relevant error details. Removing only a password while keeping a subscription URL with authentication parameters may still expose access to your own service.

Keep a verified config you can roll back to, and remove test entries shown to be unnecessary. More rules do not mean more reliable results. Long-term maintenance is easier when you can explain the purpose, order, and validation method for every condition. To review the first connection process, see Selecting a Default Server and Testing with Connectivity Test. For quick definitions, look up terms in the Glossary.