Shadowrocket
Settings Reference

1. What Settings controls and how to check defaults

First, distinguish settings, configs, and servers

In Shadowrocket, Settings controls app behavior, Config contains configuration files and routing rules, and Home is where you select a server, check Global Routing, and control the connection. These areas are related, but they are not interchangeable. Changing DNS won’t fill in a server password, and switching servers won’t fix incorrect rules. Before troubleshooting, define the issue: can’t open one domain, disconnects after a network change, or all requests fail? Each calls for a different settings path.

This guide uses iPhone and iPad menu paths. Shadowrocket is also available for Mac, Windows, Android, and Linux, but system permissions, background behavior, and visible options may differ. If you can’t find an item, first check your platform and current screen; don’t assume it’s in the same place as on another device. Follow the prompts on your device for system-level network permissions. For iPhone and iPad system requirements, check the App Store listing.

Default, current, and recommended values are different

A “default” is the initial behavior when a setting is first created. The “current value” may have changed because of an imported config, restored backup, or sync. The “recommended value” depends on what you’re trying to do. This guide doesn’t present one device’s current state as a universal factory default. Where defaults aren’t consistent, check the current screen or active config. Don’t assume a blank field means a feature is off, and don’t reset everything just to match this guide.

Keep a record you can roll back

Before making changes, note the active Config name, selected server, and Global Routing mode, then record the fields you plan to edit. If you need a backup, save it somewhere you control. Configs may contain authentication details, so don’t post the full contents publicly. Change one related group of settings at a time—for example, leave routing unchanged while adjusting DNS, test the result, then move on to On Demand. If you change several things at once, you won’t know what fixed the connection, making the next occurrence harder to troubleshoot.

After changing a setting, establish a new test connection. Existing browser connections, app caches, or system DNS caches may temporarily retain the old state, so refreshing the same page may not show the effect. Stop any ongoing test, disconnect, reconnect, then open a test destination you know and understand. If there’s no improvement, restore the original value before trying another troubleshooting path. Don’t cycle through every toggle or replace your entire config with one from an unknown source.

The app is a one-time purchase, not a service plan. The iPhone and iPad version costs $2.99 as a one-time App Store purchase. The Mac, Windows, Android, and Linux versions are free. This site does not provide, sell, or recommend nodes or subscriptions; app settings can’t replace valid credentials or a working connection for a service you already have.

To get the app, see the Download guide: get the iPhone and iPad version from the App Store. Mac downloads are available for both Apple Silicon and Intel; packages for other platforms are provided through /dl/shadowrocket/ on this site. If your system blocks the app on first launch, follow the installation and launch instructions, then return here to adjust settings. Keep installation issues separate from DNS and rule issues.

2. DNS resolution and troubleshooting failures

DNS translates domain names into addresses

When you visit a domain, an app usually looks up its address before making a connection. So a successful Connectivity Test alongside a page that won’t load doesn’t prove the remote server is working—or not working. The test may cover only one part of the path, and the page may request other domains. DNS provides lookup results; it doesn’t fix an incorrect password, expired credentials, or an issue with the destination website. Troubleshoot resolution, connectivity, and the app’s response as separate stages rather than blaming every failure on DNS.

Check both the DNS-related options in Settings and the active Config to understand the current behavior. An imported config may specify a resolver or leave resolution to the system. If a field is blank, use its description and the logs to determine what happens; don’t assume it points to a particular public service. When starting out, keep DNS settings that are already working. Adjust the resolution path only when there’s clear evidence of a DNS failure—not to chase a supposed “best setting” for every situation.

First check whether the resolver is reachable

Check in this order: can the current network reach basic services; can the server address itself be resolved; can the resolver be reached over the expected path; and does the returned address connect successfully? If the server address is a domain name, it may need to be resolved before the connection can start. If reaching the resolver depends on a proxy connection that hasn’t been established yet, the configuration may have a dependency loop. Check the config design rather than cycling through more resolvers. Adding multiple addresses doesn’t mean they’ll all work in parallel as expected.

Address families and encrypted DNS: what they do

A domain can return both IPv4 and IPv6 addresses. An IPv6 record doesn’t mean the current network has a working IPv6 route. Likewise, disabling IPv6 isn’t a universal fix. First check which address family the failed connection actually used, then compare it with the other path. If you temporarily change a related setting, note the original state and decide whether to keep the change based on your network after testing. Don’t permanently alter behavior that works on other networks to fix one network.

Encrypted DNS changes how queries are transmitted; it doesn’t automatically change how web traffic is routed or guarantee that the results suit your current connection. Distinguish the resolver address, protocol, and reachability, and enter the value in the format accepted by the current field. Don’t enter an ordinary web URL as a DNS service address. If certificate validation fails, check the system time and the value you entered. Don’t disable validation to hide a problem in the resolution path.

How to verify a DNS change

Choose a domain you can access repeatedly and note what happens before the change. Adjust only one DNS setting, reconnect, then check Log for whether the lookup succeeded, which address was returned, and which policy handled the follow-up request. Browsers may use their own resolution methods, and apps may cache addresses, so use the client’s records rather than relying on a single page refresh. If only one app has a problem, first check whether it uses its own DNS or an existing connection.

Successful resolution doesn’t mean the destination is reachable, and a connection timeout doesn’t mean DNS failed. Identify the failing stage before changing DNS.

To roll back, restore the resolver, address-family settings, and active config—not just the last line you entered. If the problem remains, check whether the network changed or a different Config is now selected. For a worked example, see Troubleshooting DNS resolution failures. If nothing connects, see Common connection issues instead of repeatedly changing DNS.

3. On Demand connection conditions

Connection triggers and routing choices are configured separately

On Demand defines when the system should try to establish or restore the VPN connection. It doesn’t select a server or set routing rules. Even when On Demand connects successfully, whether a request uses PROXY or DIRECT still depends on Global Routing and the active config. This distinction helps avoid two common mistakes: turning on On Demand to make a particular website use a proxy, or repeatedly changing domain rules to restore a connection after a network switch.

Check the actual toggle and saved conditions on the device; the connection button appearing on doesn’t prove On Demand is enabled. Check again after restoring data or changing system VPN settings. First make sure a manual connection works reliably, then configure On Demand. If manual connections already fail repeatedly, automatic retries will repeat the same failure and clutter the logs; they won’t fix a remote address, authentication, or network issue.

Set conditions one at a time

Go to Settings › On Demand and review the condition types shown on the current screen before adding only the ones you need. If you set behavior based on Wi-Fi network names, check the names carefully, including capitalization, spaces, and networks with identical names. A network name is only a matching condition; it doesn’t prove the network is trustworthy. Don’t assume identical names mean identical security, or use them as a reason to widen access to a local proxy port.

Start with one easy-to-test condition, such as distinguishing your current Wi-Fi network from cellular data. Confirm that the system triggers the expected behavior before adding more. Conditions may be evaluated in order or override one another, so arrange them according to the current screen’s guidance. If a condition doesn’t match, check the network interface and name before deleting all conditions. Keep a test record of the network before and after switching, the trigger time, and the connection state; this is more useful than saying it “disconnects sometimes.”

Connection returns after manually disconnecting

If the connection comes back soon after you turn it off, check On Demand and the system’s VPN on-demand settings before assuming the app is at fault. The system may reconnect after a network change or a later network request. To test a disconnected state, first pause the relevant triggers and then check the system status. Repeatedly tapping the connection toggle doesn’t prove automatic triggers are disabled. If the conditions remain saved, the same behavior may return after a restart.

Connection status and uninterrupted app activity aren’t the same thing. Switching from Wi-Fi to cellular changes the underlying address and network path, so downloads, calls, and long-lived connections may need the app to reconnect. On Demand can’t guarantee that every app session stays active or bypass system controls for background activity and network permissions. Test with a new request, and record an interrupted old session separately from a failed new connection.

Recommended order: connect manually and confirm it works → add one On Demand condition → switch networks and test → add other conditions if needed. Keep a rollback record each time you add one.

If a condition looks right but doesn’t trigger, check whether the system VPN configuration still corresponds to Shadowrocket, whether another connection is in use, and whether device management policies apply. Don’t remove every system configuration just to troubleshoot; save any necessary details and change only what’s clearly relevant. For first-run permissions and the Home screen, see First-launch setup. To check how traffic is routed after an automatic connection, see Config › Rule below.

4. Ping and Connectivity Test: what they measure

First identify which part of the path is being tested

Ping is the name of a settings section for test options; available methods depend on the current screen. Each method covers a different part of the path. Some mainly measure network round-trip time, some try to connect to a destination port, and others make an application-layer request. A displayed value doesn’t prove that authentication, DNS resolution, rule matching, and every website are working. Record the test method alongside the result; comparing numbers without knowing the method is rarely useful for diagnosis.

Check the default test method, timeout, and destination under Settings › Ping. Values may be customized on different devices or after restoring data, so this guide doesn’t prescribe one timeout for every network. To start, keep a method that currently works and observe real traffic. To compare servers, keep the network, test method, and destination consistent, and repeat the tests to avoid confusing Wi-Fi fluctuations with differences at the remote end.

Interpret results based on the test method

If the screen offers a TCP-style test, success usually means the relevant port completed a connection attempt; it doesn’t prove that application-level authentication will succeed. An HTTP-style test may also depend on the response, redirects, certificates, and DNS resolution. Network equipment may rate-limit or filter some probes, so it’s possible for a test to fail while real traffic works. Check what the test measures before deciding whether its result relates to your issue.

Choosing a test destination and timeout

If you can choose a test destination, use one with a clear purpose that responds reliably, and keep it the same throughout a comparison. Don’t use a page that requires sign-in, redirects often, or restricts automated requests as a measure of connection quality. If the destination itself has an issue, every server may appear to fail. A successful result after changing destinations doesn’t prove the connection was fixed. Record whether the destination changed and whether the failure happened during DNS resolution, the handshake, or the response.

A timeout that’s too short can treat a brief network fluctuation as a failure; one that’s too long can leave you waiting on an unreachable test. Start with the current behavior and adjust only if there’s evidence the network needs more time. Don’t set an excessively long timeout to hide persistent failures. Concurrent tests also use network and device resources, and can affect results on weak signals or when many background tasks are running. For a fair comparison, stop unnecessary high-bandwidth activity and keep test conditions similar.

Compare test results with real traffic

After running Connectivity Test on Home, verify a specific failing request. Record the domain, Global Routing mode, and selected server, then check the new request in Log. If the test succeeds but the page doesn’t load, check whether the page uses a different policy, requests additional domains, or encounters a certificate or authentication error. Don’t switch servers back and forth based only on their order in the list; that order doesn’t reflect the needs of each app.

Record three things for each test: method, destination, and real-world result. Latency isn’t bandwidth, and one successful test doesn’t guarantee a stable connection.

If every test fails, check the device’s basic network and permissions first. If only one server fails, check its address, port, and protocol settings. Supported protocols include Shadowsocks, VMess, VLESS, Trojan, Hysteria2, and WireGuard, each with different required fields. Don’t switch protocols at random because a test failed. Match the settings to your existing server details. For setup steps, see Add Server instructions; test settings can’t make up for missing authentication details.

5. Log coverage and collecting useful evidence

Start with one reproducible action

Log helps you inspect connection handling; it doesn’t automatically identify the cause of every error. The same “timeout” can happen at the resolver, server port, or final destination, so check the surrounding context. First narrow the issue down to one action, such as connecting and opening a specific domain, then inspect the nearby records. Opening several apps, updating a subscription, and running multiple tests at the same time mixes events together and makes their sequence hard to follow.

Check the visible options under Settings › Log for whether logging is enabled, its detail level, and what can be saved. Don’t assume every platform offers the same levels. Existing settings may have changed the default. For everyday use, keep enough detail for basic troubleshooting and increase it temporarily only when reproducing a problem. Detailed logging over time can add storage and processing overhead and collect more domain, address, and connection data. Restore the original level when you’re done.

Follow the connection stages, not just error keywords

Find the domain or address involved, check the matched policy, then follow connection setup and the response. If the request doesn’t appear, the app may still be using an existing connection, the request may not have used the current route, or the log may not cover that event. Its absence doesn’t prove that no request was made. If you see REJECT, check the rules first. If the connection target is always the server itself, verify the protocol and authentication before changing rules for the final website.

Create a minimal reproduction record

Before testing, note the device’s local time and current network. Keep any useful existing log excerpts, then use the available controls to clear the log or mark a starting point. Perform one action, record the result, and stop other tests. Keep the continuous log excerpt from before and after the failure instead of capturing just one error word. The previous line may show the destination address; the next may show a retry. Without this context, it’s hard to tell which stage the message belongs to.

If the issue occurs only after switching Wi-Fi networks, compare the logs before and after the switch to see whether the new connection took a different route. If it happens only with a particular Config, keep the server the same and compare the active file and matched rules. Change one variable at a time to narrow down the cause. Repeated errors don’t mean you should immediately enable every debug option; first check whether they’re automatic retries or another On Demand trigger.

Remove private information before sharing

Logs may contain visited domains, server addresses, account fields, subscription URLs, or other identifying information. Before sharing, remove authentication parameters, passwords, and personal details from subscription links. If you replace an address, use the same stand-in for every occurrence so the connection sequence stays clear. Don’t upload your entire config in place of a problem description or post screenshots containing credentials in a public discussion. Treat links with authentication parameters as sensitive even if no password is shown directly.

Use logs to collect evidence, not to prove a connection is “definitely working.” Keep the stages, policy, and result; remove credentials and personal information; then describe how to reproduce the issue.

After troubleshooting, restore the log level, remove local exported copies if needed, and check that no temporary DNS or routing changes remain. If you need to continue, classify the issue as DNS resolution, authentication, rules, or system permissions, then see Connection troubleshooting FAQ. More log data alone won’t make the cause clearer; reproducible conditions and a continuous record are what help with the next diagnosis.

6. Widget display, shortcuts, and status checks

A shortcut isn’t a full settings screen

Widget displays information or provides supported shortcuts in areas made available by the system. Its appearance, size, and actions depend on the system and the current Shadowrocket interface; one device’s layout isn’t universal across platforms. A widget can save a few steps, but it can’t replace editing a Config, checking protocol settings, or reviewing logs. If its status looks wrong, check Home and the system VPN status rather than relying only on the widget’s text.

Check Settings › Widget and the system’s add-widget screen to see what’s displayed by default. Not adding a widget to your Home Screen doesn’t disable the app’s connection features. First test connecting and disconnecting in the app, then add the widgets you actually need. If the system doesn’t offer a widget type, use the available controls; don’t change DNS or reimport a server just to find a matching layout. Widget availability is usually a system display or permissions issue, not a domain-rule issue.

Check the linked item after adding a widget

Choose Shadowrocket in the system’s widget picker, then place and configure it using the available options. The first time, open the app and confirm that the information you want displayed is saved, then return to the widget. If it lets you choose an item, make sure it’s linked to the one you use now, not an old entry. After deleting or renaming a server or changing a config, check that the shortcut still points to a valid item. Don’t assume the link is unchanged just because its label is the same.

Refresh, background activity, and network changes

The system may limit how often widgets refresh, so what they show may not match the app at every moment. Treat a widget as a convenient shortcut and status reference, not a continuous network monitor. The lock screen, low battery, background scheduling, and network changes can all affect when it updates. If it shows an old status, check the app and wait for the system to refresh; don’t keep deleting configs or switching servers to chase a display that hasn’t updated yet.

If a shortcut turns off the connection but it comes back soon after, check On Demand before assuming the widget failed. The action may have worked, then the system reconnected based on a condition. Conversely, a widget showing an active connection doesn’t prove the request used the right policy; DIRECT or REJECT rules in Config may still apply. Test with a new request and check its route in Log. The icon or toggle appearance doesn’t prove where traffic went.

Displayed information and privacy

People nearby may see server labels, config names, or connection status when a widget is on the Home Screen or another visible system area. Use short labels that don’t include account details, email addresses, or authentication information. If you often use screen mirroring, give presentations, or share your screen, check what the widget displays beforehand. Renaming a label shouldn’t change connection settings. Don’t use a subscription link or password as a label; keep names separate from credentials.

Recommended approach: show only what you need day to day and keep only shortcuts whose purpose you understand. If the displayed status and a real request disagree, check the app, system VPN status, and a new request together.

If the widget remains unavailable, first check that the app opens, the system allows the widget, and the linked item still exists. Then remove and re-add it using the system’s instructions. Don’t uninstall the app without a backup just to fix a display issue; you could lose local config data. If the app itself also can’t connect, the issue is beyond Widget settings. Return to the Settings overview to define what changed, then troubleshoot DNS, permissions, or server settings.

7. iCloud sync, device migration, and overwrite risks

Keep data sync, purchase history, and system permissions separate

iCloud features handle app data in supported environments. They don’t replace App Store purchase records or guarantee that system VPN permissions transfer to a new device. Seeing a config on a new device doesn’t mean you’ve completed the initial network permission prompt. Getting the app with the same purchase account also doesn’t guarantee that all settings from another device will appear. Check the store account, system cloud account, and the client’s actual sync scope separately; they’re not one setting.

Check Settings › iCloud and the relevant system settings to see whether sync is enabled and which items are included. This guide doesn’t assume that every field syncs or that other platforms use the same cloud service. Before enabling sync for the first time, save a local copy you can restore and review the scope shown on screen. If you only need to move one Config, use a clearly defined export and import process instead of enabling every sync option.

Decide which data to keep first

If the two devices already have different configs, choose which one to keep and note important differences on the other device separately. Don’t rename, delete, and add many items on both devices at once and expect the system to decide which version you intended to keep. Sync transfers state; it doesn’t understand your intent. If a conflict appears, read the current prompt. If it offers to replace or overwrite data, stop and check your backup before confirming.

Test the connection even after sync completes

Open the app on the destination device. First check that all entries are present, then verify the active Config, Global Routing mode, and selected server. Matching names aren’t enough; ports, protocols, and additional settings can all affect the connection. Establish a manual connection and handle any permission prompts, then test a real destination. Configure On Demand and Widget last so you can distinguish data migration issues from automatic connection or display issues.

Subscription sync and subscription updates are different actions. Sync may make existing entries available on another device. An update accesses a subscription URL you already have and processes the returned content. If the new device has a different number of entries or different names, first check whether the update succeeded, whether it used the same URL, and whether there are local edits. Don’t immediately delete the old data and retry the update; you could lose both a working local copy and a useful basis for comparison.

Accounts and sensitive data

Before enabling sync, remember that configs may contain server addresses, passwords, authentication fields, and subscription details. Who controls the device and account affects who may be able to access this data. Be cautious about keeping full configs on shared devices. When selling, handing over, or retiring a device, use the system and app options to manage personal data. Removing a widget from the Home Screen doesn’t delete a config, and turning off one sync option doesn’t necessarily remove every saved copy.

Sync isn’t a standalone backup. Deletions and accidental edits may sync too. Before important changes, keep a restorable copy that doesn’t depend on live sync.

If sync hasn’t updated, check your cloud account, available storage, network, and app permissions, then review the app’s messages. Don’t switch every setting back and forth between devices to force a sync; this can increase differences between them. If you need to restore data, stop editing, keep the current state on both devices, restore one from a verified copy, and test it. For redownloading a purchased app, see Moving to a new device and reinstalling. Restoring data doesn’t replace the app purchase or download process.

8. Proxy local ports and access scope

A local listening port isn’t a remote server port

Proxy settings may include local HTTP or SOCKS ports that apps on the same device can connect to. Check the current screen for the available options. These ports are local entry points provided by the client; they’re different from the remote server port entered under Add Server. Changing a local port won’t change the remote settings from your service provider or automatically make other apps use a proxy. An app must support the relevant proxy type and be configured with the local address and port.

Check the current port and listening address rather than guessing a fixed number from an online example. If you don’t need a local proxy, keep the existing settings instead of opening a listener for a supposed “optimization.” If you do need one, note its port, protocol, and access scope. If the screen lets you choose a bind address, limit a local-only entry point to the device. Exposing it to your local network changes who can connect; consider network trust, access controls, and the system firewall.

The address, port, and protocol must match

The loopback address 127.0.0.1 means the current device, not another device on the same Wi-Fi network. If you enter it on a computer, you’ll connect to the computer itself, not Shadowrocket on your phone. To allow access from another device, you need the actual reachable address of the device providing the proxy and an appropriate listening scope. That requires additional network administration; an enabled port doesn’t guarantee other devices can connect.

Distinguishing a port conflict from a connection failure

If another process is using the port, the client may not be able to start the listener. Check the prompt and logs to identify which local entry point failed instead of changing the server password. If you need a different port, choose one that isn’t in use and is allowed by the interface, then update the settings in any apps that use the proxy. Changing the client without updating those apps creates a mismatch. Record the new value after testing so you don’t restore an outdated setting later.

If an app can connect to the local entry point but its request fails, check the client connection, Global Routing, and active rules. The app may have successfully handed the request to the local proxy, with a later failure during remote authentication or connection to the destination. If the app reports that the local connection was refused, check that the client is running, the relevant entry point is enabled, and the address and port are correct. Distinguishing these cases helps avoid blaming every issue on the remote connection.

System tunnels and explicit proxy settings are different

A system VPN tunnel and a proxy explicitly configured in an app are two different ways to route traffic. Not every app follows the system’s explicit proxy settings, and opening a local port doesn’t cover every app. Don’t stack proxy layers without understanding the route; this can create loops, process traffic twice, or make logs harder to interpret. Verify one connection method first, then decide whether you really need the other. A more complicated route doesn’t necessarily add useful functionality.

Recommended approach: keep local-only use on the device, and define clear access boundaries before allowing access from other devices. Don’t expose a local proxy port to a network you can’t control or treat it as a public connection service.

When you finish testing, restore Shadowrocket’s port and listening settings and remove any temporary proxy address entered in other apps. Otherwise, those apps may keep trying to reach an inactive local entry point after the client stops, making it look like the whole device has lost internet access. If you changed the system proxy on a desktop, restore that too. Confirm that the regular network works, then enable only the settings you need. If routing doesn’t match expectations, check Config in the next section instead of changing the local port again.

9. Global Routing, rules, and related settings

First check the current Global Routing mode

The Global Routing modes Config, Proxy, and Direct correspond to Config, Proxy, and Direct. Config routes requests according to the active config; Proxy uses the proxy mode; Direct uses the direct mode. Before troubleshooting rules, make sure Config is selected. Otherwise, even correctly written rules may not be used as expected. Check the current mode on Home instead of assuming a setting shown in a tutorial is the permanent default on every device.

Rule order and where to put FINAL

Rules are matched from top to bottom, and the first match determines the policy. Put more specific conditions before broader ones. DOMAIN matches a specific domain, DOMAIN-SUFFIX matches a domain suffix, and DOMAIN-KEYWORD matches a keyword. IP-CIDR and IP-CIDR6 apply to address ranges, while GEOIP uses IP geolocation data. Rules rely on different information; having a domain name doesn’t mean an IP rule can be evaluated without resolving it.

FINAL is the fallback when no earlier rule matches and usually belongs at the end of the rule list. If you put it before rules that need to run, those rules won’t get a chance to match. The following minimal .conf snippet is for understanding the syntax, not a complete config or a universal rule recommendation. The example domain and local network range illustrate rule order only; check whether they suit your existing setup before importing.

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,example,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY

In this snippet, example.com and its subdomains match DOMAIN-SUFFIX first and won’t reach the keyword rule below. PROXY, DIRECT, and REJECT mean proxy, direct, and reject policies. Don’t confuse them with the capitalized Global Routing modes in the interface. You can use REJECT to block a destination, but first consider the scope: a page may use several domains, and rejecting one resource can affect how the page works rather than simply disabling one visible button.

Use comparisons to isolate the effect of settings

If a request fails in Config but works in Proxy, check the matched policy, active file, and DNS path before changing servers. If both modes fail, check the remote settings and basic connectivity. A result in Direct shows only how the current direct route performs; it doesn’t prove that other routes are faulty. After switching modes, test with a new request. An existing connection may keep its old route and make the results seem contradictory.

Manage subscription updates, config file updates, and manual edits separately. A subscription handles server details you already have; Config controls the corresponding configuration. Updating one doesn’t mean the other changed too. Before editing, make sure you’re working on the active file. Save important custom rules before an update. After importing an external config, check whether it overwrote local changes; a matching file name doesn’t mean the contents are unchanged.

For everyday use, select a Config you’ve checked. For troubleshooting, briefly compare Proxy and Direct. When finished, restore the original mode and recheck DNS, On Demand, and the active rules so no temporary state is left behind.

Use Log to verify how rules and DNS work together: find the destination, check the first matching rule, then inspect the connection that follows. To learn more about rule priority, see Custom rule priority and FINAL. For import steps, return to Subscribe instructions. Linking a config change to one request and its log is more useful for reliable maintenance than adding more rules.