The Complete Shadowrocket User Guide Initial Setup and Routine Maintenance

Verify the app before confirming your purchase

Get Shadowrocket through the designated product page linked from the App Store verification guide. Do not identify the app by its name in search results alone. Check that the product name is Shadowrocket, the developer is Shadow Launch Technology Limited, the icon is official, and the app ID is 932747118. You can identify the app ID in the product link ending with id932747118. Similar names do not mean the products are the same. Check these details together rather than relying on a particular color or search ranking.

On the App Store product page, review the price, compatibility, and purchase information before completing the system purchase process. Shadowrocket is primarily for iPhone and iPad; check the compatibility section on the same product page for Mac, Apple TV, and Apple Vision. System requirements and purchase availability are as stated on the App Store page. Being able to open a product page on a device does not necessarily mean that the device meets the current system requirements. Check the result shown by the store for your device.

What Does a One-Time Purchase Include?

A one-time purchase covers the app itself; it does not provide ongoing connection services. The US storefront price is about $2.99, but check the App Store page for the current price. Other storefronts display prices in local currency. Before paying, check the Apple Account being used for the purchase and the amount shown on the page. After purchase, the app still requires your own subscription or server details. The purchase record does not replace that information or show whether a server is currently available. Keep the two types of fees and records separate to make future device transfers and troubleshooting easier.

Server details typically include an address, port, protocol, and authentication parameters. A subscription is an address used to retrieve a server list. A configuration file contains rules, some connection settings, and references to policies. These serve different purposes from your App Store purchase record: the purchase record lets you redownload the app, a subscription maintains the server list, and a configuration file determines how connections are handled. Restoring the app alone does not guarantee that the original subscription, manually entered details, or local changes will be fully restored to a new device. Before transferring, check where your data came from and make sure you have a backup.

First-Time Purchase and Restore: The Right Order

After your first purchase, wait for the App Store to finish downloading the app, then open it from the device Home Screen. If the store already shows a purchase or redownload option, first check that it is associated with the right account; do not buy the app again straight away. To restore it on a new device or redownload it, use the original purchase account and look for the app in the App Store account's purchased items. The name of this option may vary by system interface. If you cannot find the app, check your purchase history, hidden items, and current App Store account before considering storefront region or purchase availability. Check the App Store information and the actual account status to see whether Family Sharing applies.

The account used for cloud syncing may differ from the one used for App Store purchases. When troubleshooting, check the App Store account, not just the name shown at the top of system settings. Account details are personal information; do not post them in public reviews or troubleshooting screenshots. Keep only enough information to identify the purchase for your own records, and never record your account password. For payment or account restrictions, follow the account support process provided by the App Store. Changing Shadowrocket rules, protocols, or DNS will not change your purchase status.

What to Check After Downloading

After opening the app, make sure you can access the main pages, including Home, Config, Data, and Settings. Do not change advanced options yet. An empty server list does not mean the purchase failed; you may simply not have imported your own details. Next, follow this guide to set up initial permissions, then add your service details. App updates are managed through the App Store; check its product page for update information and system requirements. For details on restoring a purchase on a new device, see How to Redownload Shadowrocket from Purchased Apps.

Why Does the System Show a Permission Prompt?

Shadowrocket uses the networking extension provided by the system to handle connections. The first time you enable a related connection feature, the system may ask to add a VPN configuration and require confirmation with your device passcode or another supported authentication method. This allows the app to create the corresponding network configuration in the system. It does not purchase a new service or submit payment to a subscription address. Read the app name and instructions in the prompt, confirm that you initiated the action, and then decide whether to proceed. Do not assume every system prompt is the same and confirm them all without checking.

Permission is only one part of getting ready to connect. Even after the system allows the configuration to be added, an incorrect server address, mismatched authentication details, or an unavailable service can still prevent access. Likewise, importing a server list correctly does not bypass the system's configuration permission. For a first-time setup, check these four stages separately: “details imported,” “configuration approved,” “connection started,” and “target accessible.” This is more reliable than judging the whole process by a single switch.

What to Do If You Denied Permission

If you dismissed the prompt, return to the app, check the connection status, and manually start a new connection. Watch for the system prompt to appear again. Avoid rapidly tapping the switch several times, as this can cause the permission, startup, and stop processes to overlap. If the system does not show the prompt again, look for VPN-related configurations in device settings and check whether there is an entry for Shadowrocket. System menu names may change between versions; focus on which app the entry belongs to and its status rather than memorizing a specific menu path.

If you see multiple network configurations, first check what each one is for. Other VPN connections or managed network settings may affect the current connection. Stop other connections you control, then test Shadowrocket on its own. Devices managed by a workplace or school may have additional restrictions; ask the device administrator about them instead of deleting managed content at random. Removing the system configuration for this app should not be your first step. Consider recreating it only after understanding the impact and saving any necessary information, then complete authorization again.

Prepare Your Network Before Connecting

For testing, use a clearly defined network, such as Wi-Fi that has completed its sign-in process. Some public networks require authentication through the system or a browser. If basic network access is not available, a correctly configured client still cannot establish a remote connection. Temporarily disconnect the client and check that the device can access the internet normally, then return to the app. During your first test, do not switch between Wi-Fi, mobile data, and multiple servers at the same time. Otherwise, it will be difficult to tell which change caused the failure.

Check the device's date and time too. Connections using TLS validate certificate expiry dates, and a significantly incorrect device clock can make a valid certificate appear invalid. Correct the system time first rather than lowering verification requirements to mask the issue. If the system prompts you about a certificate, device management, or an additional profile, do not assume you must accept it just because you are setting up the client. Importing a regular server or configuring rules does not mean you should accept system-level changes from an unknown source.

How to Record Permission Issues

Permission issues typically occur before or during connection startup. Signs include incomplete authorization, failure to create a configuration, or a switch that does not stay in the expected state. Record what you did, whether the system displayed a prompt, and what the app showed after you confirmed it. Avoid vague notes such as “it doesn't work.” If the switch starts but access fails for only one target, continue troubleshooting in the connection and rules chapters instead of repeatedly rebuilding permissions. A timeline of events makes it easier to distinguish system-level problems from service-level ones.

Hold off on setting up On Demand at this stage. First, use the manual switch to complete a repeatable connect-and-disconnect cycle. Then add automatic connection conditions so you can tell whether a later reconnection was caused by a manual action or an automatic condition. If the connection starts again every time you disconnect, check whether an automatic behavior is enabled before assuming the switch is faulty. Once permissions are confirmed, continue to the next chapter to add a server or subscription. If you do not have service details yet, you can read about the interface without entering random parameters just to proceed.

Identify the Details You Have

Before importing, determine whether your service provider gave you a subscription URL, a single server share, or a complete configuration file. A subscription URL usually retrieves a list of server details. A single share describes one connection. A configuration file may also include rules and other settings. They may all appear as text or a URL, but they do not belong in the same import field. Read the description provided with the details, then choose the appropriate add option in Home or configuration management in Config. This helps prevent cases where the import succeeds but does not produce the expected content.

Server details and subscription URLs may contain authentication information, so protect them like passwords. When copying, preserve the full content without adding explanatory text, spaces, line breaks, or non-ASCII punctuation. If you import using Scan QR Code, make sure the code comes from a source you trust. A QR code is not automatically proof that a configuration is trustworthy. Do not upload it to a public forum for help, or paste a full subscription URL into an unfamiliar website to inspect it. When troubleshooting, describe only the type of details, the error, and the steps that led to it.

How to Check a Manually Added Server

In Add Server, first select the type that matches your service details, then enter the address, port, and authentication fields. The protocol determines what the other parameters mean. Passwords, identifiers, encryption methods, and transport options are not interchangeable across types. The address field generally takes a server address; do not add a web page path yourself. Use the port number provided in your details. Before saving, compare every field with the original information, paying particular attention to capitalization, trailing characters, and digits. Do not rely on details that merely “look close enough.”

If your details also include TLS, a server name, a path, or other transport parameters, enter them in the corresponding fields. The server name is not necessarily the same as the connection address, and a path is not extra descriptive text you can add at will. If you are unsure about a field, check the source of your service details instead of trying every switch. Manual entry works well when you have a small number of complete parameter sets. Importing a standard share can reduce typing errors, but you should still check the type and key fields after import.

Importing and Updating a Subscription for the First Time

To add a subscription, enter the complete URL in the appropriate Subscribe type field, save it, and run an update. Check whether a server list appears. You can use a name to identify the source, but it is not a connection parameter. If the list is empty, first determine whether saving the URL failed, the request failed, or the returned content could not be parsed. Each case needs a different response. Seeing a web page in a browser does not mean the URL returns subscription content the client can use; it may actually be an account sign-in page or an error message.

After importing a subscription, select one of its servers and continue to the connection tests. Do not immediately edit subscription-generated entries one by one, as an update may overwrite those changes. If you need to make independent changes, first understand where the entries came from and how updates affect them. Keep the original subscription and give your own copies clear names. Updating a subscription refreshes server details; it does not automatically replace the rules file in the current Config. Managing the server list and managing routing rules are separate tasks.

Keep Existing Details If an Import Fails

If an update fails, you do not need to delete the existing subscription right away. Keep the current list while checking that the URL is complete, your service account is still active, and the current network can retrieve the subscription content. If it worked before but suddenly fails, note the last successful update and any recent changes, then check for service status information from your provider. Repeatedly retrying usually does not fix a formatting problem and may lead to access restrictions. Follow the checklist for a subscription that fails to parse or returns an empty list to narrow down the cause before deciding whether to replace the URL.

Check the Mode Before Interpreting Rules

Config, Proxy, and Direct in Global Routing determine the main routing method. Config routes traffic according to the rules in the active configuration file. Proxy sends connections handled by the client through the selected server. Direct handles them as direct connections. “All” describes the routing mode; it is not an absolute description of every system behavior on the device. System behavior, existing connections, and other network settings may affect what you observe. When troubleshooting, test a new request rather than relying only on a page that was already open.

Config is an interface term used for both the bottom configuration management tab and an option in Global Routing, but these serve different purposes. The first manages files; the second selects whether rules are used for routing. Importing a file does not mean the current mode is Config, and selecting Config does not mean a newly downloaded file is active. Check both states before editing rules. Many cases where “rules have no effect” are actually caused by the mode still being Proxy or by a different file being active than the one you edited.

What Does a Rule Contain?

A typical rule consists of a type, a match value, and a policy, separated by English commas. DOMAIN matches a full domain name. DOMAIN-SUFFIX matches a domain suffix and its subdomains. DOMAIN-KEYWORD matches a keyword in the domain. IP-CIDR and IP-CIDR6 specify the corresponding address ranges, while GEOIP checks an IP geolocation database. PROXY, DIRECT, and REJECT mean proxy, direct connection, and reject, respectively. Policy names must match the configuration's actual meaning; do not replace rule keywords with explanatory text.

[General]
bypass-system = true

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

These minimal rule snippets are for learning to read rules, not complete configurations for every network. Example domains illustrate the syntax; they are not test servers. A direct rule for a local network address demonstrates address-range matching. GEOIP relies on a database and cannot replace checking a specific target. Before using a rule, confirm which services, local network resources, and fallback policy you need. Keep a copy of the original configuration and make changes one at a time in a separate copy. Do not overwrite your only working file.

Rules Are Checked from Top to Bottom; the First Match Wins

Rules are checked in order from top to bottom. Once a rule matches, its policy is applied and the search stops; the system does not continue looking for a supposedly more specific rule. Put exceptions for individual domains before broader rules that might match them. FINAL is the fallback when no earlier rule matches and typically belongs at the end. Placing FINAL earlier can prevent later rules from being checked as intended. DOMAIN-KEYWORD may also match more broadly than expected. Consider possible false matches before using it; when a specific suffix will do, avoid broadening the condition unnecessarily.

Domain rules and address rules use different information. A target first appears as a domain name and is later resolved to an address; some rule matching may involve DNS. The fact that a connection ultimately uses a particular address does not prove that an address rule matched first. Analyze actual request records, rule order, and resolution results together rather than checking address ownership once. In an IPv6 network, account for relevant address rules too. Adding only an IPv4 range does not cover all similar connections.

What to Include in a Complete Test

After importing your details, select one of your own servers in Home, check the Global Routing mode, start the connection, and complete any required authorization. Once the status is stable, make a new request to a real target. A complete test should check at least four things: the switch is in the expected state, the correct server is selected, the target returns content, and the request follows the expected policy. A system VPN indicator can show that the corresponding network configuration is active, but it does not prove that server authentication succeeded or that every website or app is accessible.

For your first test, choose a target you know well and can assess reliably. Do not open lots of pages at once. Test one ordinary request, then one that should use the proxy. If you need to access local network resources, test those separately. Different targets may follow different policies, so one successful result does not prove that all rules are correct. Record the network, server, and mode used for the test; repeat it under the same conditions to make the results comparable. Do not update subscriptions or replace configurations midway through testing, as this can change the test conditions without you noticing.

How to Interpret Connectivity Test

Connectivity Test can help determine whether a server or test target is reachable, but results depend on the test method, test address, and network conditions at the time. A successful test does not mean every real-world service is working, and a failed test does not necessarily mean every connection is unavailable. Treat it as one piece of evidence and compare it with actual access results. If the test method is configurable, check which method is in use before comparing results. Times from different test methods are not directly comparable, and a single number cannot establish long-term reliability.

If a test passes but a webpage fails, first check whether the failure affects only one domain, request type, or app. The target service, DNS, TLS, rule matching, and restrictions on remote access may all play a role. If all targets fail, check the server address, port, authentication details, and basic network access. If only one app behaves unexpectedly, fully close its existing connections and try again. This helps rule out an old session or cached result from the previous mode. Do not reset all device settings just to clear one app's connections.

Narrow Down the Problem by Layer

Layer one is basic network access: can the device connect normally with the client disconnected, and has public Wi-Fi authentication been completed? Layer two is the server connection: under controlled conditions, use Proxy to check whether the selected server can handle a real request. Layer three is configuration-based routing: if Proxy works but Config does not, focus on the active file, rule order, and related resolution settings. Layer four is the target itself: if only one target continues to fail while similar requests work, check the target service and the specific error instead of blaming every problem on the client.

Switching modes temporarily is a diagnostic tool, not a permanent fix. After testing, return to the mode you need for everyday use and verify it again. Different results between Proxy and Config may point to different rule paths or involve DNS or existing connections. This comparison alone does not prove that a rule is wrong. Compare with Direct only using a target that should allow a direct connection. Change one factor at a time and record results before and after to narrow down the cause. If you change the server, mode, and network all at once and get a successful result, you will not know which change fixed the problem.

Distinguish Timeouts, Resolution Failures, and Certificate Errors

A timeout means no required response arrived within the expected time, but it does not identify which part failed to respond. Check basic network access, the port, and the target range. A resolution failure points first to the domain resolution path; it is not a reason to immediately change your authentication password. For a certificate error, check the device time, server name, and server-side certificate. Turning off verification changes the connection's trust requirements and is not a routine troubleshooting step. Check your details and ask your service provider about server requirements before changing several advanced options at once.

If the problem occurs only after switching networks, record which networks you switched between and whether reconnecting restores access. If it happens only after the device wakes from sleep, compare the first request after wake-up with later requests. Find a repeatable trigger before changing related settings. Do not start by rebuilding system settings, subscription formats, and rules all at once. If you are still unsure about the first-connection steps, return to the quick-start guide and repeat the minimal setup. Advanced troubleshooting should build on a basic configuration you can test consistently.

Which Layer of Traffic Do the Statistics Show?

Data displays traffic and connection information available to the client. The specific details shown depend on the current app interface. Before interpreting them, check the measurement range: is it for the current session, an accumulated period, or a particular server? These ranges are not directly comparable. Data observed by the client, system mobile data statistics, service provider usage records, and the size of a downloaded file all use different measures. If the numbers differ, check their scope and units first rather than assuming one of them is wrong.

A single webpage visit can involve text, images, scripts, fonts, and background requests. One URL in the address bar does not tell you how many connections are involved. Uploads and downloads also happen at the same time: even when you are mainly reading, the device still sends requests and protocol data. Page refreshes, preloading, and background app sync can all add to the statistics. To measure the effect of one action, note the counter before you start, perform one specific action, then check the change. Do not try to guess the source by watching a total that keeps increasing.

Client Statistics Are Not the Provider's Billing Records

A provider may measure usage according to its own billing rules, accounting period, and traffic definitions. Client records depend on the connections it can observe. Transfer overhead, retries, and differences in measurement boundaries can all affect the numbers. Data is useful for local observation and troubleshooting, but should not replace your service account's billing records. An app purchase does not include connection services, and the app's traffic records do not add usage to your service allowance. Check limits, expiry dates, and account restrictions in your own service details.

Use One Test to Check a Rule

To check a rule, first note the current mode, configuration file, and test time, then open just one target. If the interface provides request or connection details, look for the corresponding records around that time and check the domain, address, and policy information. A single page may request resources from multiple domains, so do not stop after finding the first record. If the main page loads but some resources fail, different domains may have matched different policies. Match the failed resource with its rule rather than adding an overly broad exception for the entire page.

Interpret missing expected content in a record with care too. The app may have reused an existing connection, the target may have loaded from cache, or the current view may not include that type of record. Make one identifiable new request, then check the filter and record range. Repeatedly refreshing a page can create noise by adding many duplicate entries. To compare results before and after a rule change, note both times, repeat the same action, and make sure the new configuration has been applied. This ensures you are comparing the same variable.

Background Activity and Privacy

It is not unusual for traffic to continue changing after you stop browsing. System sync, message delivery, media preloading, and background app tasks can all use the network. Pause downloads and sync that you control, then see whether the activity decreases. Do not assume a rising counter means something is wrong. If an app repeatedly fails and retries, traffic may continue to increase. In that case, use the error records to address the cause instead of just clearing the statistics. Clearing them only resets the observation point; it does not fix the connection or reset the provider's records.

Request records may expose visited domains, times, network addresses, and content containing authentication details. Before exporting or taking a screenshot, check for subscription parameters, full URLs, and personal data. Keep only the details needed to explain the problem. After troubleshooting, delete records you no longer need according to your privacy preferences. Do not enable HTTPS decryption just to collect more information. For basic rule checks, start with metadata such as the target, time, and policy. For the different bottom-tab functions, see the guide to the Home, Config, Data, and Settings interface terms.

Start with a Stable Baseline

Settings change how the app behaves; turning everything on will not improve every connection. For first-time use, keep a verified baseline: a specific server, a fixed mode, a configuration file you can identify, and a repeatable test target. After that, change one type of setting at a time and note its original value and why you changed it. The app interface may vary by version, so refer to the options currently shown. If you do not see an option mentioned in a guide, do not substitute a similarly named one or use an unknown configuration to force it into place.

Some settings affect the next connection, some affect current requests, and others only change display or update behavior. After saving a change, check whether you need to reconnect, then verify the result with a new request. A changed switch on the screen alone does not prove that the network is using the new settings. Configuration-related settings may also come from the file itself. When troubleshooting, check both the active file and app settings so you do not change one place only to be affected by an existing setting elsewhere.

Define the Trigger Conditions Before Using On Demand

On Demand automatically starts a connection when specified conditions are met. Before using it, be clear about what you want, such as which network conditions should start a connection and when it should stay disconnected, then configure the conditions actually provided by the app. It does not keep a server available and cannot fix authentication failures. If manual connections have not been verified, do not enable automatic behavior yet. Otherwise, retries and network changes can make it hard to tell whether the problem is with the conditions or the server.

After enabling it, test scenarios that meet and do not meet the conditions separately, and check whether the results match your expectations. If the connection starts again after you disconnect manually, an automatic condition may still be met; that does not necessarily mean the disconnect action failed. If you need to stop it temporarily, check the automatic connection settings too. Test leaving and returning to a network, and waking the device from sleep as separate scenarios. If a condition uses the network name, remember that the same name can refer to different environments. Do not treat the name alone as proof that a network is trusted.

What Subscription Update Settings Do and Do Not Do

If the current interface offers an option to update subscriptions when opening the app, decide whether to enable it based on how often you use the app. It can refresh the server list, but updating still depends on network access and a valid subscription URL. An update failure on opening the app does not mean every cached server is immediately unusable. Test list updates and existing connections separately. Automatic updates do not continuously monitor provider changes or guarantee that the latest details will always be retrieved at the best time.

Before changing update behavior, understand what happens to entries generated by the subscription. If you have changed names, order, or connection fields, check whether those changes will survive the next update. Keep a separate record of important changes rather than relying on entries that may be overwritten. If an update fails, preserve the current working state before investigating. “Automatic” does not mean you can ignore an error. See How to Update a Subscription Manually or Automatically on App Launch for details. The exact interface path depends on the app.

Do Not Change DNS and Connection Options All at Once

DNS translates domain names into addresses. Its request path and results may affect later rule matching and connections to targets. Before changing DNS settings, first confirm that the issue is actually related to resolution, such as repeated failures to resolve the same domain after basic network access and server connectivity have been verified. Do not add a set of DNS addresses just because you saw it online. If you do not understand their source, reachability, or configuration meaning, adding them only creates more variables. Keep the original settings and compare results using the same target.

Adjust options related to TLS, transport, IPv6, or connection reuse only when required by your service. A feature requires corresponding support from both the network and server; more enabled options do not mean a more complete setup. If a connection fails, check the service parameters first, then consider advanced settings. Do not turn off certificate verification just to get an apparent connection. Use detailed logs only when needed: gather enough information to troubleshoot, then return to settings appropriate for everyday use and handle exported records carefully.

Manage Three Types of Updates Separately

Routine maintenance includes at least three separate tasks: updating the app through the App Store, updating the server list in a subscription, and updating the configuration file in Config. An app update changes client features and behavior; a subscription update changes service details; a configuration update changes rules and related settings. Do not perform all three while troubleshooting the same issue. If something goes wrong after an update, knowing which layer changed lets you compare before and after and check with the right source of information.

Before updating, check whether the current connection is handling something important, save local changes, and note the configuration name in use. After updating, check the server list and active file, then test an actual connection before changing other settings. Updates from a configuration source may overwrite existing content, and subscription updates may change entries. Keep reliable copies of important exception rules and manually entered parameters. App update information is listed on the App Store page; do not guess whether you need an update based on version numbers circulating online.

Back Up the Content and Record Its Source

When making a backup, save the file and note where it came from, what environment it is for, and which parts you changed. Use clear names to distinguish the original configuration, a test copy, and the one used day to day. Keep a private note describing the differences. After exporting a file, check whether it contains a subscription URL, server authentication fields, or other sensitive information before choosing where to store it. Do not share backups publicly as if they were ordinary documents. Even if most of a file contains rules, a single address with authentication details can expose your information.

A backup is useful only if you can restore it, not just because an export completed. Before transferring devices, make sure the file is readable, the source URL is still accessible, and manually entered details are complete. Save everything in a secure location you control and keep a clear restore order: get the app, complete permissions, restore service details and configuration, then test the connection. If you use sync, check exactly what it covers. Seeing the same filename does not prove that all settings, records, and authentication details match.

A Minimal Restore Process for a New Device

On the new device, use the original purchase account to get the app from the App Store. System requirements and purchase availability are as stated on the App Store page. After opening the app, do not immediately copy every advanced option. First restore one working server or your own subscription, select a clear mode, and complete system authorization. Once the basic process works, add your everyday rules and automatic connection conditions. If a problem occurs, you can then identify the most recently restored item rather than facing an unknown state created by transferring everything at once.

A successful connection on the old device does not guarantee the same result on a different network with the new device. Check local network addresses, network authentication, device time, and automatic connection conditions again. Once the new device is stable, remove sensitive details from the old device that you no longer need. Do not delete the only copy before confirming the transfer. For purchase restoration help, see the Restore Purchases section. For common questions about pricing and one-time purchases, see Pricing and One-Time Purchases. Changing client rules will not resolve account issues.

When Something Goes Wrong, Roll Back the Most Recent Change First

When troubleshooting maintenance issues, first ask, “What were the conditions the last time it worked?” Then ask, “What changed afterward?” If you only changed the configuration file, switch back to the backup. If you only updated a subscription, check its parameters and which entry is selected. If you just enabled On Demand, pause automatic behavior and test manually. Rolling back restores a baseline for comparison; it does not mean you have to keep using old settings. Once you have identified the difference, address the specific item instead of deleting all configurations and starting over every time something goes wrong.

Keep a short private maintenance log with the reason for each change, what you changed, and the test result. Do not record passwords or full subscription URLs. If a problem cannot be reproduced consistently, note that the conditions are still unclear instead of adding rules one after another just to reach a conclusion. For more details, browse the blog guides by topic: rules, subscriptions, or purchases. To repeat the initial connection process, return to the user guide. This manual is designed to make every action evidence-based and every result explainable, not to have you configure every available option.