Shadowrocket Settings Guide

01 / Scope

Settings scope and checking current values

Separate Settings, Config and system authorization

Settings are not the only source of connection behavior. Check three layers: the app stores test methods, logs and some general preferences; Config contains rules and related parameters; the system controls VPN configuration authorization, network access and iCloud availability. Server entries also have their own address, port and protocol fields. When troubleshooting, identify the relevant layer before looking for the right setting. Changing Settings will not fix a typo in a server address, and switching Config does not replace the system authorization prompt.

A setting may appear unchanged while the request takes a different path. For example, choosing another server on Home, switching Global Routing from Config to Proxy, or moving from Wi-Fi to cellular changes the test conditions. Before consulting a section, note the current network, selected server, Global Routing mode and Config name. These four details provide a baseline for comparing results. Without them, “it worked yesterday” does little to distinguish a settings change from a network or remote-service change.

Default, current and recommended values are different

The default is the initial setting for a particular installation before changes are made. The current value is what the interface displays or the configuration file stores. The effective value is the behavior used for an actual request. After a backup or sync restore, the current value may come from an older device rather than match the original default. For settings that can vary, start by keeping a value that already works; do not reset the entire app just to match a guide. If a field shows automatic, blank or inherited, do not assume that means disabled—check whether it delegates control to Config or the system.

Keep a record you can roll back

Before making a change, save a copy of the current configuration. In a private note, record the setting, old and new values, reason for the change and test result. A configuration copy may contain server credentials, so do not put it in a public note. Change one variable at a time—for example, adjust the test method without changing DNS at the same time. Save the change, then, if needed, disconnect and reconnect when an interruption is acceptable. Repeat the same request to the same destination. If there is no improvement, restore the previous value rather than piling on more changes. This keeps the cause-and-effect trail clear.

Distinguish between a saved setting and one that has taken effect. Returning to the previous screen only confirms that the edit was accepted; it does not mean an existing connection was rebuilt. A page that loads successfully may also have come from cache. For an important change, make a fresh request and check the corresponding time in Log. For system authorization, check the VPN status in system settings rather than relying only on the app toggle. There is no need to delete the app to check a default: doing so may affect local configurations and records without restoring a working combination.

If only one destination has a problem, check its rules first. If all destinations fail, check the server, network and DNS. To confirm the purchase page and app identity, start with the three checks for the genuine App Store listing. This settings guide does not change what a purchase covers or validate your server details. The FAQ has quick answers to common symptoms; use it to identify the issue, then return here for a closer look.

02 / DNS

DNS resolution and rules

Separate the destination domain from the server domain

DNS translates domain names into addresses used for connections. A proxy request may involve at least two lookups: the device first needs an address for the server domain, and the destination domain must then be resolved along the relevant request path. If the first lookup fails, the proxy connection may never be established. If the second fails, a server test may respond even though a particular site will not open. Changing DNS is not a universal fix for connection errors. First identify which domain failed and whether resolution happens before or after the connection is established.

Review DNS-related options in Settings alongside the active Config. If the configuration specifies DNS or related behavior, one screen alone may not reveal how resolution ultimately works. The default depends on the current interface and active configuration; this guide does not prescribe a public DNS address for every network. Start with the existing working settings and keep any explicit configuration. Troubleshoot a specific DNS setting only when Log shows a resolution error, an unexpected address or a resolution path that does not match expectations.

Check the expected format; do not mix addresses and protocols

A DNS field may accept an address, a list of servers or a specific supported format. Check the field description and available options. A plain address and a DNS address with a protocol prefix are not interchangeable strings. Before entering a value, check whether a prefix is required, whether there are extra spaces, whether the separators are correct and whether your current network can reach the resolver. Do not enter a web page URL as a DNS address or assume that an encrypted resolver is reachable just because its transport is encrypted. The resolver itself still needs a network connection.

If the server address is a domain name, consider its DNS dependencies. A resolver that can only be reached through a proxy that has not yet connected may create a startup dependency loop if resolving the server domain also depends on that resolver. To troubleshoot, restore the original DNS settings first. Confirm that the server domain resolves before the connection is established, then test the destination domain's resolution path separately. Do not permanently replace the server entry with an address found during one lookup: remote addresses can change, and some protocols require the correct name for validation.

How DNS resolution relates to rule matching

Domain rules and address rules match different things. DOMAIN-SUFFIX can match a domain suffix directly, while GEOIP and IP-CIDR are based on addresses. Processing an address-based rule may require a DNS result. If you want one specific domain to use a particular policy, place its domain rule before broader address-based checks rather than making several DNS changes first. Rules are processed in order; once an earlier rule matches, later examples do not choose the policy for that same request.

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

This snippet illustrates how rules relate; it is not a complete connection configuration. example.com and example.org are example domains, and PROXY and DIRECT are policy keywords. Before using it, confirm that the active Config accepts those policies and test in the Config mode of Global Routing. No DNS server is specified here, so these lines do not show which path DNS requests will take. For more on matching, see rule syntax and match order.

Verify and roll back DNS changes

On the same network and server, repeat a request to a destination where the problem is reproducible. Note the time, then check Log for a DNS timeout, name resolution failure or subsequent connection error. If resolution succeeds but the connection times out, focus on address reachability. If name resolution fails, check the resolver and network conditions. Changing DNS may not immediately clear old cache entries. Make a new connection when retesting, and do not treat a cached page as evidence of success. If there is no clear improvement, restore the original value, keep the test record and avoid cycling through multiple resolvers.

03 / On Demand

On Demand automatic connection conditions

Automatic triggers do not guarantee a connection

On Demand asks the system to establish a VPN connection when configured conditions are met. It controls when to try connecting—not whether the server is valid, nor whether every app will stay connected indefinitely. Before enabling it, connect manually and confirm that the default server on Home, Global Routing and Config are correct. Then verify with Connectivity Test and by accessing an actual destination. If a manual connection has not succeeded, automatic triggers will simply repeat the same failure, making it seem more frequent without fixing an address or authentication error.

The initial toggle state, available conditions and existing rules depend on the current interface. After restoring from an older device, check carefully for conditions carried over from it. A good starting point is to keep connection control manual until it is stable, then enable On Demand for a specific use case. Read each condition and confirm whether it applies to the network, a request trigger or another configurable scope. Do not assume a condition applies to every network or that a later item in a list overrides an earlier one.

Build a test matrix for network changes

Automatic connections can behave differently when switching between Wi-Fi and cellular, leaving an access point or waking the device. Before testing, define the expected result—for example, keep the current state on a specified network and request a connection on other permitted networks. Change one condition at a time, wait for the system to finish changing networks, then check system VPN status and app records. A brief interruption during a transition does not automatically mean the rule is wrong; consider when it triggered and what happened next. Repeatedly toggling networks combines too many state changes and makes the cause harder to find.

Why does it connect again after I turn it off?

If the system tries to reconnect after a manual disconnect, first check whether On Demand is still enabled and whether its conditions remain true. Manual disconnect and automatic rules are separate controls; the former does not necessarily cancel the latter. To stop automatic behavior temporarily, turn off the relevant automatic connection setting in the app, then disconnect and watch the system status. If it keeps happening, check which VPN configuration is actually active in the system. A different saved configuration may be responsible, not the page you just edited.

A device may have multiple VPN configuration profiles. The selection shown in the app should match the configuration active in system settings. Do not delete every profile without checking its name, source and current status first. System authorization lets the app create the relevant configuration; it does not set up every automatic condition. On managed devices, system policies may also affect network or VPN behavior. An in-app toggle cannot override those requirements, so follow the device's management rules.

Captive portals and recovery

A Wi-Fi network that requires a sign-in page may not yet provide full access. Even if an automatic connection triggers correctly, the device may not be able to reach the server until you complete the network's legitimate sign-in process. Temporarily stop automatic attempts, complete the sign-in using the system's permitted flow, then restore the original conditions and test again. Do not change server protocol parameters to troubleshoot a network that has not finished connecting; the issue occurs before the proxy connection, and protocol changes only add variables.

After setting up automatic rules, test at least three cases: entering the conditions, leaving them and manually pausing. Save the original settings, and check that system status, trigger records and access results tell a consistent story. If the rules are too complex, start with the fewest conditions and add them back one at a time, testing a network change after each addition. For the initial connection steps unrelated to automatic triggers, see choosing a default server and running Connectivity Test. You do not need to repeat the entire import process to troubleshoot On Demand.

04 / Ping

Ping and Connectivity Test

A test result applies only to its test path

Ping settings affect the method, target or wait conditions used for list tests. Available fields depend on the current interface. A response time in the list is not a complete network-quality score or the total time required to load a web page. A request may involve DNS resolution, connection setup, protocol negotiation, remote processing and data transfer. Different test methods cover different stages, so their numbers are not directly comparable. Nor does the lowest number alone show which server is best for every use.

Use the current settings as the reference for test methods and timeouts; sync restores or earlier manual changes may have altered them. Keep the existing parameters at first, establish a baseline with a stable server you already use, then change one setting at a time and compare. If the current interface offers TCP or another connection-based test, it checks whether the relevant connection can be established within the wait period. A test that makes a request to a destination also depends on that destination being available. A failed test may be caused by its target rather than an invalid server entry.

Keep the target, network and time frame consistent

For a fair comparison, keep the test target, current network, test method and server entry the same, and run tests around the same time. Switching from Wi-Fi to cellular changes the conditions; comparing a daytime result with one from a busy period also says little about whether a setting helped. A few repeat tests can show whether results are stable, but there is no need to send requests continuously. Tests generate traffic and connections; excessive testing may disrupt active connections and turn short-term fluctuations into misleading conclusions.

A timeout means the test did not finish within its wait period; it does not prove the address is permanently unreachable. A short timeout may rule out a slow but usable path, while a long one delays results for an unavailable entry. This guide does not prescribe a universal number of seconds. Start with the value shown in the interface and adjust it for the purpose of the test. If several entries time out, check the device network and test target before rewriting server fields. If only one entry is affected, check its address, port, authentication details and service status.

Verify list tests and actual connections separately

A response in the list does not mean that entry is selected as the default server. First select the server you want on Home and check the selection indicator, then check the Global Routing mode. Connect, run Connectivity Test and access a destination where the problem can be reliably reproduced. This separately verifies that the entry can be tested, the correct server is selected and the connection path works. Checking only the first can lead you to mistake an unselected server's test result for the status of the current connection.

Normal response, but actual access fails

When results differ, first check which stages the test covers. If it only tests the server port, authentication fields may still be wrong. If the test destination is reachable, the actual destination may match a different rule. Then check DNS, the policy for the destination domain and the failure stage in Log. Do not keep switching servers based only on response time: that changes the remote exit and connection state at once, and the original problem may disappear under new conditions. A reproducible set of conditions is usually more useful than collecting extra test numbers.

For protocols such as VMess, VLESS, Trojan and Hysteria2, a reachable port does not prove that all protocol parameters match. Some entries also depend on transport, name validation or other server-side requirements. Compare each field with your own server details. For protocol field explanations, see supported protocols and Add Server field overview. This page explains test settings; it does not rate providers or recommend servers based on test results.

05 / Log

Log and troubleshooting

Note the time, then reproduce the request once

Log helps you correlate events and errors during a connection, but not every entry indicates a fault. Before troubleshooting, note the device time, current network, default server, Global Routing mode and active Config. Then perform one clear action, such as connecting and visiting a destination. Look for entries around that time and read them in sequence: DNS resolution, connection setup, protocol handling and destination access. Scanning a log without context can mix errors from an earlier attempt with a successful current request.

Use the current interface to check logging controls, detail level and retention; do not assume every installation saves the same content by default. Keep the current settings for routine diagnostics, and temporarily increase the available detail only when troubleshooting. Restore the original settings when finished. More detailed logs may include additional access metadata and take more storage and effort to review. If the interface does not offer a particular level or export option, there is no need to search for a hidden equivalent—use the features it provides.

Narrow the issue down by failure stage

If a DNS error appears first in the log, check DNS and the relevant domain. If a result resolves but the connection times out, check the address, port and network reachability. If a connection is established but authentication or protocol errors follow, review the server fields. A response error from the destination may point to the destination service itself. This is not a rigid classification for every log; it is a way to avoid unrelated changes. Changing protocol parameters without evidence, or repeatedly replacing DNS after an authentication failure, can lead you away from the actual failure stage.

A disconnect may also result from a network change or manual action. Compare log times with your actions and check whether it occurred after switching from Wi-Fi to cellular, enabling On Demand or changing servers. Similar errors after the same action provide stronger evidence that the issue is reproducible. Keep an isolated record that recovers on its own for reference instead of immediately resetting the configuration. If you cannot reproduce the issue reliably, collect the conditions under which it occurs rather than masking it with unrelated changes.

Check the matched rule; do not confuse a destination with a policy

In Config mode, check any policy or match information in Log to see whether the destination used the expected policy. Put a domain rule before broader rules that could match it first, and place FINAL as the fallback. The displayed domain, actual connection address and policy name are different fields; seeing a familiar domain alone does not prove it used a proxy. If Global Routing is in Proxy or Direct mode, understand what that mode does before concluding that rules are “not working.”

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

In this example, example.com itself matches DOMAIN first and uses DIRECT. Its subdomains may match the DOMAIN-SUFFIX rule that follows. This shows how a specific condition can take priority; two related rules do not necessarily conflict. Change only the rule that needs to behave differently, then test the same destination again. If you swap the lines, the root domain may match the suffix rule first. Checking that a rule exists is not enough—check its position and the actual request name.

Protect sensitive data before saving or sharing

Logs may contain server addresses, destination domains, local network details, subscription URLs or authentication data. Before asking for help publicly, remove full subscription URLs and their query parameters, credentials, personally identifying information and access records that are not needed. Hiding the displayed server name may not be enough; the actual address may appear in a later line. Share the smallest useful reproduction instead: a time range, the failure stage, relevant redacted fields and the actions taken—not a complete history of activity.

Do not delete useful evidence just to tidy up a log. Save necessary excerpts in a private location first, then clear records using the method available in the app. Clearing logs does not clear configuration, and restoring configuration may not restore logs; manage them separately. If the log is empty, check whether logging is enabled, whether you are viewing the right time range and whether the request went through the current connection. An empty log alone does not prove that a request succeeded or failed. For quick guidance on common errors, start with the Troubleshooting section of the FAQ.

06 / Widget

Widget and system status

A quick-access control is not a substitute for the full settings screens

A Widget is a system-provided quick view or control. Its available styles and functions depend on the device's system and what the app currently provides. It can show limited status or trigger supported actions, but it cannot replace a full check in Home, Config and Settings. After importing a configuration, changing the default server or adjusting On Demand, return to the app first to confirm the actual selection. A line of text in a Widget alone does not prove that the configuration, policy and server have all switched correctly.

The system manages whether a Widget appears, where it is placed and which sizes are available. App preferences may affect what information it can read or display. Check these separately. The default display depends on the Widget you added and its settings; there is no layout that suits every device. Start with a current Widget that shows only the information you need. Add other controls only when useful, so similar names are less likely to lead to an accidental tap or a misread status.

Display delays and connection state are not the same

The system schedules Widget updates, so they are not guaranteed to match the app screen second by second. A Widget may retain its previous state after the app disconnects, or may not have refreshed yet after connecting. When they differ, open Shadowrocket to check the current connection and compare it with system VPN status and an actual request. Do not repeatedly tap the Widget to force an update. Repeated connect and disconnect actions can create real interruptions when the original issue was only a stale display.

System power management, a locked device, background scheduling and network changes can all affect when information refreshes. There is no guaranteed refresh interval, and changing system power settings long term just to update Widget text sooner is not recommended. If a Widget remains incorrect, first confirm that the app opens and shows the current state, then check whether the Widget needs a different configuration selection. If the system lets you remove and add it again, record the original layout and try that. This addresses the display only; it should not involve deleting the app or resetting connection settings.

Distinguish the selected server from the connected server

The selection on Home, an established connection and the item shown in a Widget may be at different stages during a switch. Selecting an entry does not prove an existing connection has been rebuilt with it. A displayed name does not prove the item is currently available either. After switching, check the app to see whether it requires a reconnect, then run Connectivity Test. If the test fails, consult the Ping, DNS and Log sections rather than blaming the Widget display settings for everything.

If you have server entries with similar names, use names you can distinguish within your own setup, but never include passwords, full subscription URLs or other sensitive information. A Widget may show item names where others can see them, so consider your privacy when using one on the Lock Screen. A name is for identification only; changing it will not fix protocol parameters or change what the server can do. Tests and configuration checks must still use the actual fields.

Using Widgets with On Demand

If you disconnect through a Widget while On Demand conditions are still met, the system may try to reconnect. Check the source of automatic triggers rather than assuming the Widget button failed. To stop connections temporarily, review the automatic conditions in the app before disconnecting. Before resuming, confirm that the original server and configuration are still correct, then restore the relevant conditions. A Widget is one control; automatic rules are another. Interpret both as part of the same verification process rather than looking only at the last tap.

If tapping a Widget opens the app instead of completing the expected action, follow the interaction the current system allows. Some actions may require unlocking the device, opening the app or confirming a system prompt. Do not assume that every action runs silently in the background. Confirm first-time VPN authorization explicitly in the system prompt. Widgets are best for routine use after a connection has been verified. Set up and troubleshoot connections in the full app so you can see the required fields and error details.

Widget placement and availability may differ between iPhone and iPad. For system requirements and compatibility, refer to the App Store listing. To set up a clear connection from the beginning, return to the Getting Started guide. If only the display is delayed, there is no need to reimport an existing subscription or repeatedly change DNS or Proxy ports just to refresh it.

07 / iCloud

iCloud sync and configuration recovery

Handle app purchases, configuration sync and system authorization separately

iCloud sync saves or transfers data within the scope supported by the app. It is not the same as an App Store purchase record. A purchase record answers whether you can redownload the app; sync determines which app data can be restored between devices; system VPN authorization determines whether a device is allowed to create the relevant configuration. These have separate controls and statuses, even if they use the same account ecosystem. Installing the app on a new device does not mean all servers, rules and connection permissions have been restored.

Check the app and system interfaces for sync options, data types and current status. Do not assume that Config, server entries, every Setting, logs and system authorization are all copied together. On the source device, check what is included in sync; on the destination device, verify each item that actually appears. If the interface lets you select data types, enable only what you need instead of turning everything on to make the devices “match.” Check system VPN authorization separately on the destination device.

Before enabling sync, check your account, storage and an independent backup

Before enabling or troubleshooting sync, confirm that you are signed in to iCloud on the system, the app meets the required conditions, and storage and network access are available. The current state depends on the device; enabling sync on an old device does not guarantee the new one uses the same setting. Save an independent copy of any configuration still in use, and protect its credentials. Sync is not a version history and may not recover every accidental change. If an incorrect change syncs to another device, a reliable original copy is still needed for recovery.

Editing the same content on the source and destination devices at the same time may cause duplicates, mismatches or overwrite choices. Pause edits on both devices, choose one with complete working data as the reference, then compare the actual content on the other. Avoid repeatedly deleting and recreating configurations with the same name on both devices; those actions may also sync. If the app shows a conflict or asks you to choose, read what each option will keep and confirm which copy you need before proceeding.

Subscription updates are not iCloud sync

Subscribe refreshes data from a subscription URL you already have; iCloud sync transfers data between devices. The former depends on the URL, authentication and format. The latter depends on the account, system permissions and sync status. Seeing an entry on a new device does not prove its subscription URL can still refresh. A successful refresh on the source device does not guarantee the destination has received the latest list. First identify whether the problem is retrieving remote data or transferring data between devices; do not alternate between the two workflows.

If the destination device has subscription entries but cannot update them, check that the subscription URL is complete, has not expired and is reachable on the current network. Do not keep toggling iCloud. If the source has updated but the destination list has not, check sync scope and status instead. For refresh controls and failure cases, see manual subscription updates and automatic refresh troubleshooting. Treat any subscription URL containing access credentials as private; do not include it in public sync troubleshooting notes.

Verify items individually after restoring; do not assume everything carried over

After recovery, check the Home list, default server selection, Global Routing, active Config and DNS-related settings. Then confirm that On Demand suits the new device's use case. Even with identical data, two devices may use different networks and have different system permissions and routing conditions. Access to a destination on the source device does not prove recovery succeeded on the destination. On the new device, test a manual connection, run Connectivity Test and access a real destination independently.

To redownload the app, use your App Store purchase history or the genuine product page. See how to restore a purchase on a new device. Purchase eligibility, system requirements and sharing options are listed on the App Store page. Restoring an app purchase does not include network services managed by the user or guarantee that credentials remain valid. If data is missing after recovery, keep the current state and check sync scope and your independent copy before reinstalling repeatedly.

Before signing out, disabling sync or clearing cloud data, check whether the action affects this device, the cloud or other devices, and save anything you need to keep. “Stop syncing” does not necessarily mean “delete every copy,” and data still on this device does not prove it was backed up to the cloud. Follow the interface prompts and verify the result to reduce the risk of accidental data loss.

08 / Proxy

Proxy ports and final verification

Separate remote server ports from local listening ports

The server port in Add Server comes from your existing server details and connects to the remote service. A local port in Proxy settings is a listening parameter used when the device provides a local proxy entry point. Although both are numbers, they are different fields. Changing the local port does not change the remote server port or fix an incorrect server address. Before troubleshooting, check whether you are on the server editor or the app's local Proxy settings; otherwise, you may keep changing numbers in the wrong place.

The default local listening port, whether it is enabled and its access scope depend on the current interface. If you do not need a local proxy entry point, keep the existing state rather than opening a listener for ordinary connections. If you do need one, record the address, port, protocol type and access scope first, then configure the client that will use it. A port is only one part of a connection entry point: it must be understood with the listening address and protocol. A port number alone cannot explain how to connect or whether another device should have access.

Listening addresses and access boundaries

An address accessible only on the device exposes less than one accessible on the local network. Before broadening the listening scope, confirm the need, whether the network is trusted and whether the app provides access controls. Do not expose the listener to every reachable network just to connect another device. If only local use is needed, choose the narrowest scope the current feature allows. Other devices on a shared network may not be under your control, so manage the local proxy entry for its actual purpose—not merely to make it reachable.

On the client, point the address to the device providing the listener, not the remote server domain. The port must match the local listening port, and the protocol must match too. A device may get a different local network address after changing networks; an old address failing does not necessarily indicate a Shadowrocket issue. First confirm that both devices are on the expected network, the listener is still enabled and its address has not changed. Then check the port and protocol. Do not change DNS, rules or server authentication fields before checking these basics.

Check for port conflicts and connection refusals in order

An immediate refusal, a persistent wait and a protocol failure after connecting are different symptoms. For a refusal, check that the listener is running and that the address and port are correct. For a persistent wait, check network reachability and access scope. If the connection is established but then fails, check the protocol and authentication requirements on the client. A port conflict may prevent the listener from starting, but one timeout alone does not prove a conflict. Check for relevant app messages and consult Log instead of trying large numbers of random ports.

If you need to change the local port, do so when an interruption is acceptable. Save the change and update every client that uses it. Existing connections may not move to the new port automatically, so create a fresh test connection. Before choosing a value, check the field's allowed range and whether another local service is using it. This guide does not prescribe a universal port. If the change does not help, restore the original listener and client settings so the two ends are not left out of sync.

Check routing and configuration for Proxy connections too

A local entry point accepting requests does not guarantee that subsequent routing is correct. Also check Global Routing, the selected server and the active Config. The snippet below is a standalone rule example; it does not include listener settings or server credentials. It cannot replace a complete configuration or override protocol fields in a subscription you already use. Troubleshoot the local port and rules separately to determine whether a request failed to reach the app or reached it but took the wrong path.

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,ads,REJECT
IP-CIDR,192.0.2.0/24,DIRECT
FINAL,PROXY

The domains and address ranges in this example illustrate syntax. DOMAIN-SUFFIX matches a domain suffix, DOMAIN-KEYWORD matches a keyword in a domain, IP-CIDR applies to an address range, and FINAL is the fallback policy. REJECT blocks matching requests, so assess its scope before adding it; avoid broad keywords for important services. Use rule order to understand ordinary routing only when Global Routing is in Config mode. For other modes, verify behavior according to what each mode does.

Close the loop on each change

Final verification has two parts: first confirm that the client can reach the correct local listener, then confirm that the app selects the expected policy and can access the destination. If the listener works but the destination does not, return to the Ping, DNS and Log sections. If the listener is unreachable, start with the address, port and access scope. Record the successful conditions, old and new values, and disable extra logging enabled only for troubleshooting. Restore the intended On Demand state. The goal of a settings guide is not to add more toggles, but to give each change a clear purpose and a result you can verify.