Shadowrocket Settings Guide

01 / Scope

Settings Scope, Defaults, and a Baseline for Changes

Distinguish Settings, Config, and Server Fields

Shadowrocket settings are not a single set of options that all take effect in the same way. App-level options in Settings, configuration files in Config, and connection parameters on a server's edit screen each serve a different purpose. DNS, for example, may involve both a configuration file and an in-app option, while a server address is a connection endpoint. Before troubleshooting, identify which layer you are editing. Otherwise, a saved change may not affect the part of the app that handles the request.

Home shows the current connection and server selection, Config manages and selects configuration files, and Settings contains app options. This guide keeps these interface labels in English; the exact layout and available options depend on the device. When you find a setting, check its description, current value, and available choices before changing it. Do not rely on a screenshot from another device to locate a switch. Do not invent configuration keys that are absent from the file.

“Default value” can refer to at least three different things: the initial contents of a new configuration, the app's options on first launch, or values imported with a subscription or configuration file. These are not interchangeable. After restoring a device, options may carry over from the previous device; selecting a different Config may activate another file. Record the actual effective values before making changes. This is a more useful rollback reference than an unchecked assumption about defaults, and it helps show whether a change caused the problem.

Create a Reversible Baseline

Before you start, record the current Global Routing mode, selected server, active configuration file, and whether the issue occurs on Wi-Fi or cellular data. Keep server names recognizable in your private notes; there is no need to share them. Save a copy of the configuration you plan to edit and note the purpose of the change, such as “check whether this domain follows the expected policy.” These notes are not app logs. They are a record of test conditions that helps you avoid losing track of the original state after several troubleshooting rounds.

Change one variable per round. If you change DNS, the server, routing mode, and test method at the same time, even a restored connection will not tell you which change helped. The next similar issue will require starting over. A complete round includes a test before the change, one change, reconnecting, testing the same target again, reviewing the results, and keeping or reverting the change. For configuration files, also confirm that the saved file is selected as the active Config.

Recommended values depend on the situation. If a device is working, the usual recommendation is to keep settings that have already been verified. If it is failing, return to the simplest configuration you can explain, then restore features one at a time. Higher numbers, longer timeouts, and more enabled options are not automatically more reliable. Settings can change how the client handles requests, but they cannot replace server availability, valid credentials, or the access conditions of the current network.

In the configuration examples, example.com is an illustrative domain, not a reachable service. PROXY and DIRECT are policy keywords; distinguish them in syntax and scope from Proxy and Direct in Global Routing. Reserved addresses in examples illustrate matching logic and should not be copied blindly. If your configuration uses custom policies, check how they are defined before referencing them to avoid using a policy name the file cannot parse.

If you have not completed a first connection, follow the full Getting Started Guide instead of jumping into advanced settings. If there is a specific error, use the FAQ to narrow down the cause. The sections that follow cover DNS, routing, triggers, testing, logs, sync, and recovery in turn. This order helps move from settings that look right to requests that have actually been verified.

02 / DNS

DNS Settings and Domain Resolution

What DNS Does—and Doesn't Do

DNS resolves domain names to addresses, but a successful lookup does not mean the connection will succeed. A request may resolve an address and then fail while connecting to the server, establishing an encrypted session, or retrieving content. Conversely, if the proxy server address is a domain name, it may need to resolve before the app can connect to the proxy. First distinguish a failed lookup for the destination from a failed lookup for the proxy server address. They occur at different stages, so changing one setting may not fix both.

In Config, check the active file's [General] section for dns-server. In the example below, system means to use the system-provided resolution settings. It is a starting point for understanding the syntax, not a line every file will include automatically. The result depends on current network conditions. If the app also has DNS-related options, record those too; one line in a file does not prove that every request uses the same resolution path.

[General]
bypass-system = true
dns-server = system

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

This snippet shows app-level handling, the source of name resolution, and rule matching, but these lines do different things. bypass-system is a separate configuration option, not a general DNS fix. dns-server specifies DNS settings, while [Rule] determines the policy for matching requests. Before copying a line, check its placement in the original file and look for duplicate fields or conflicting rules. Keep the other required sections intact.

How to Choose Defaults and Recommended Values

Check the current file and app interface to find the initial DNS settings. This guide does not specify a public resolver for every network or recommend a particular DNS service as a universal choice. If there is no DNS issue, keep settings that have been verified. If a problem occurs only on one network, compare the results with another network first. Change the resolution source only when the evidence points to the DNS stage, then repeat the test with the same domain.

If your configuration uses encrypted DNS, check whether the DNS endpoint is reachable, whether its domain needs to be resolved first, and how it connects under the current routing mode. Switching to another protocol does not automatically remove dependencies that must be met first. When troubleshooting, confirm the basic path under simple, observable conditions before restoring the original DNS design. Do not keep adding endpoints; that makes it harder to identify which one is involved when requests fail.

Domain and address rules can also affect what you observe. DOMAIN-SUFFIX matches a domain suffix, while IP-CIDR matches an address range; some address-based checks may involve DNS resolution. If a domain resolves to different addresses on different networks, subsequent address rules may match differently. To find out why a rule matched, check the request domain, resolution result, and rule order—not just the final policy shown.

Cache and Local Network Names: What to Know

DNS results may be cached in the app, the system, or upstream. After changing DNS, old results may not disappear immediately, and a webpage may reuse an existing connection. To verify a change, save the configuration, reconnect, and make a new request. If you need to test for a cache issue, use repeatable steps rather than clearing all data indiscriminately. The more you clear, the more likely you are to lose login state or other useful evidence.

Local device names, internal domains, and public domains may depend on different DNS conditions. Switching to an external resolver may prevent internal names from resolving as before. If the issue affects only devices on a home or office network, first check that network's DNS requirements, address ranges, and direct-connection rules. Access to public websites does not prove that internal name resolution is configured correctly. Do not change routing for every request just to fix one internal name.

After making a change, test at least one destination that worked before, one that failed, and any local network destination you actually need. Record whether each resolved to an address, established a connection, and returned content. If DNS succeeds but content still fails, investigate routing, server parameters, or the destination service instead of cycling through DNS settings. These stage-by-stage results also give you useful context for reviewing logs.

03 / Routing & Proxy

Global Routing, Rules, and Proxy Ports

Three Modes, Not Three Sets of Server Parameters

Global Routing determines the overall handling mode for requests. Config uses the active configuration's rules; Proxy sends requests normally handled by this routing setting through the proxy path; Direct connects directly. System traffic, exclusions, and the specific configuration can still set limits. Do not treat any mode as an absolute description of all network activity on the device.

Under Config, a matching result of DIRECT may be exactly what the configuration specifies; it does not mean the server has failed. If switching to Proxy restores access, that shows that changing the request path affected the result, but it does not by itself prove a rule is wrong. Return to Config and check which rule matched, whether a broader rule came first, and which policy it points to before changing anything.

The right mode for everyday use depends on the purpose of your configuration. Use Config when you have verified rules for split routing. Switch to Proxy temporarily to compare the proxy path, or to Direct temporarily to check direct access. Restore the original mode and reconnect after testing. Do not leave a temporary test mode in place to hide a faulty rule; it may also change access to local network devices and other destinations.

Rule Order and Policy Behavior

Rules are usually checked from top to bottom, with specific rules placed before the fallback. The example handles an illustrative domain and private addresses first, then uses FINAL for requests that did not match. FINAL,PROXY deliberately uses the proxy as a fallback; it is not a default everyone should copy. Changing it to FINAL,DIRECT changes the path for every unmatched request, a much broader effect than changing one domain.

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

Do not try to “raise priority” by adding the same rule again. If an earlier rule already matches, a later rule for the same target may never be evaluated. Check the match record first, then move or narrow the rule, save, and test again. REJECT blocks matching requests; it does not fix them. See REJECT Rule Order and Limitations for details on matching scope.

Distinguish the Remote Server Port from the Local Listening Port

The port on a server's edit screen is where the remote service accepts connections, and it must match the server details you already have. If Settings offers a local Proxy port, that is the listening port for a local proxy entry on the device. Even if both happen to show the same number, they are not interchangeable. Entering a local port as the remote server port—or using the remote service port as a local listening port—changes the connection target fundamentally.

Check the current value, protocol, and activation requirements for a local port in the actual interface; this guide does not specify a fixed port number. A valid port number is only the first requirement. Also check whether a service is listening, which proxy protocol the requesting client uses, whether listening is limited to the local device, and whether the network allows access. For ordinary iPhone or iPad use with a system VPN configuration, do not change the local listening port just to “improve speed.”

If you need to use a local Proxy, keep the original settings first. Clarify whether requests come from the device itself or another device on the local network, then choose a method the app actually supports. Do not mix up HTTP and SOCKS5 client settings, and do not enter a webpage path in a port field. If the test fails, check that listening is enabled and the protocols match before investigating the destination request. Matching port numbers alone do not prove the setup is complete.

After changing routing or ports, test ordinary network requests and any specific local entry separately. This prevents mixing up two different results. If changing a port has no effect on a regular connection, that may be because the connection did not use the local entry in the first place. Base changes on the actual request path: who initiates it, where it connects, which protocol it uses, and which policy it matches. Only then consider changing a value.

04 / On Demand

On Demand: Triggers and How to Stop Them

On Demand Does Not Fix Server Issues

On Demand triggers a VPN connection when specified conditions are met. It controls when a connection is attempted; it does not replace server verification, subscription updates, or routing configuration. Set up automatic triggers only after a manual connection is stable and the active Config and server are clear. Otherwise, the same failing path may be triggered repeatedly, which can look like the app is changing settings when the condition is simply still true.

Open the actual On Demand options and check whether the feature is enabled, what conditions are configured, and whether the system VPN configuration is still present. Use the value shown on the current device as the reference: restored data, reinstalling the app, or granting permissions again can change the state from first use. If the system and app show different states, return to manual connection testing and confirm that the basic setup works before troubleshooting automatic triggers.

The recommended approach is not to enable everything, but to keep only conditions you can explain. If the app offers options based on network type or identifier, set each one according to your needs rather than copying someone else's network name. If you do not need automatic connections, manual control is easier to monitor. If your device often changes networks, verify the trigger on each network you use regularly; testing only the current Wi-Fi is not enough.

Test Automatic Connections Step by Step

First, stay on the same network, connect manually, visit a known test destination, and check the actual policy. Second, disconnect and confirm that it stops normally. Third, configure On Demand if needed, then observe what happens when the network state genuinely changes. Do not switch servers, update a subscription, or change Config during the test; otherwise, you cannot tell whether the trigger condition caused the connection change.

When observing results, distinguish four stages: whether the condition is met, whether the system starts a connection, whether the connection is established, and whether requests work afterward. If the trigger fires but the connection fails, investigate the server and network. If no connection attempt starts, check the trigger conditions and system configuration. A VPN icon in the status bar indicates a connection state; it does not prove that content will load as expected.

When switching networks, the device may obtain a new address, encounter different DNS conditions, and lose existing connections. A brief reconnect is not the same as a continuing failure loop. Record the networks used before and after the switch, the trigger sequence, and the stage where the failure occurs; this is more useful than repeatedly toggling the setting. If a network requires web authentication, complete that network's sign-in first. On Demand cannot replace the network's authentication process.

Why Does It Reconnect After Disconnecting?

When an On Demand condition remains true, manually disconnecting once may not disable automatic triggers. To stop automatic connections reliably, first turn off On Demand in the relevant settings, then disconnect and check the system state. Do not immediately delete every configuration; that makes it harder to tell whether the issue involves trigger rules, system permissions, or server parameters. After confirming that the connection stays stopped, restore any settings you still need based on your notes.

If the device has other VPN configurations or network restrictions managed by an organization, check which connection methods the system allows. Avoid repeatedly creating similarly named configurations; that makes it hard to tell which one the app is using. On managed devices, follow the applicable device-management requirements; this general guide does not replace them. On a personal device, check the actual system prompt instead of attributing every connection failure to an app setting.

Also verify On Demand during normal use once the device is locked, but do not treat background behavior alone as proof of battery drain or performance. Network activity, system policies, and other apps can all affect what happens. Restore the original settings after a temporary test. If you keep On Demand enabled, review it again after changes to the configuration or network conditions to ensure it still serves a clear purpose.

05 / Ping & Connectivity Test

Ping, Connectivity Test, and Interpreting Results

First, Identify What the Test Measures

In everyday use, Ping often means a latency test, but tests may work in different ways. Network probes, transport connections, and requests to a destination through a proxy cover different parts of the path. Before testing, check the method and target. Do not assume the button label means the entire proxy path is being tested. Results from different methods should not be ranked or compared directly, even when they use the same target.

If the interface offers ICMP, TCP, or request-based tests, understand what each can tell you. An ICMP probe does not verify proxy protocol authentication. A TCP connection does not necessarily test encryption or an application request. A request-based test is closer to accessing a specific destination, but still depends on DNS and the destination service. Use only methods and fields available in the current interface; do not look for a switch just because it is mentioned here.

Connectivity Test shows whether the selected test process can connect. It does not guarantee access to every website, every protocol, or continued service over time. A successful test proves only that the conditions at that moment produced a successful result. A failed test may mean the test destination is unreachable, not that the server is entirely unavailable. Start with a test method that has already been verified and specify the target and path. Change the method or target only when troubleshooting requires it.

Test Targets, Timeouts, and Defaults

Check the current Settings screen for the test target's initial value, timeout, and other parameters. This guide does not prescribe one timeout for everyone or recommend continually increasing it. A timeout that is too short may record temporary variation as failure; one that is too long delays the result when a target is truly unreachable. Choose values that help compare consistent conditions, and record the results before and after a change. The goal is not to make every test show a number.

If a test lets you specify a target, choose an address you are allowed to access and can use reliably, and make sure its format matches the field. A domain field, full URL field, and server address field are not interchangeable. Do not share a target containing login state or private parameters in public troubleshooting materials. If the target redirects, requires authentication, or restricts access, those conditions are part of the result; it cannot be interpreted as the proxy server's transport latency alone.

Batch tests can introduce another variable: simultaneous probes share network resources and may be affected by how destinations respond. Results in a list are not fixed properties of the servers. Repeat tests for an unusual result separately and compare them with actual requests. Do not attribute test differences to the server while transferring a large file, or treat a single ranking as a substitute for checking routing and protocol parameters.

Assess Latency, Bandwidth, and Stability Separately

A faster response does not mean a higher sustained transfer rate, and it does not guarantee a stable long-lived connection. Response time reflects the wait for one interaction; sustained transfers are also affected by bandwidth, congestion, the destination's content service, and protocol behavior. For video stuttering or interrupted file transfers, record when and how long the issue occurs and check the relevant request logs. Repeated Ping tests cannot fully explain these problems.

If the test fails but access works, first check whether the test target has unusual response requirements, and keep the successful access as a comparison. If the test succeeds but actual access fails, check the service's DNS, matched rule, connection stage, and response. In either case, do not immediately delete the subscription. Separate “test process failed” from “service request failed” before deciding whether to change the test settings or the actual connection configuration.

For connections such as Hysteria2 that rely on specific transport conditions, a TCP probe cannot replace a test using the actual transport. See Hysteria2 and QUIC Basics for protocol requirements, and UUID, Encryption, and Transport Settings for checking VMess and VLESS fields. Test options cannot compensate for incorrect protocol fields.

Keep the tests that answer a specific question, not the largest number of tests. Once the issue is understood, restore temporary targets and timeout changes to values verified for everyday use, and note why you kept a particular method. If the same issue occurs again, reproduce the same conditions first. This avoids starting each investigation from a different test setup.

06 / Log & Data

Logs, Data, and Layered Troubleshooting

Observe One Request at a Time

Log helps you inspect requests and connection activity; Data shows traffic and other records provided by the app. Check the actual interface for available details, retention, and access. An increase in traffic counters does not mean a destination page loaded correctly, and a connection entry does not mean content was returned successfully. Logs are useful for identifying the stage where a failure occurred, not for judging whether the app is “working normally” from the number of entries.

Before troubleshooting, record the sequence of conditions: current network, Global Routing mode, active Config, selected server, and destination to test. Then make just one request, or a small number of requests that are easy to identify. Do not repeatedly refresh several apps at once; the logs may contain system activity, background requests, and retries. The most recent entry may be unrelated to the request you are investigating.

If the app offers options for log detail or retention, use the current device's displayed values as your reference. Start with the least detail needed to see the issue and increase it temporarily only if necessary. Restore your everyday setting after troubleshooting. More detailed logs typically contain more information to handle and may use more storage or processing resources. Keeping the most detailed logging enabled long-term is not a way to improve connection quality.

Read Logs by Request Stage

First check whether the request target is correct, then whether it resolved, which rule and policy matched, which server it connected to, and what happened next. Log formats may not show every field, but you can follow the same order when reading them. If a stage is not visible, acknowledge that the evidence is incomplete and run an appropriate test. Do not infer the entire connection path from a generic error message.

For example, a “connection timed out” error can refer to different endpoints. Check whether the timeout was for the proxy server, a DNS endpoint, or the destination service. For an “authentication failed” error, first check the authentication fields in the server details you have and confirm that the expected server is selected. For certificate warnings, verify the address, name, and server configuration. Do not weaken verification blindly just to hide an error; suppressing a warning is not the same as fixing the connection.

Interpret DIRECT, PROXY, and REJECT in logs alongside the matched rule. If you see DIRECT, first check whether it matches your intended routing. If you see REJECT, look for an overly broad preceding rule. Do not change every unexpected request to PROXY; the cause could instead be an incorrect domain, the destination service, or the app's own authentication process.

Data Counters and Privacy

First check the scope and time range of statistics in Data. Connection duration, cumulative traffic, and the time taken by a single request are different metrics. After reconnecting, clearing data, or changing screens, check how the numbers are reported again. A counter in the app is not the same as a carrier bill, and increased upload traffic alone does not prove anything is wrong. First distinguish normal background communication, retries, and tests in progress.

Logs may contain domains, addresses, server identifiers, and request details. Exported files may include additional context. Before sharing, remove passwords, subscription links, tokens, personal addresses, and information that could identify you. A UUID may look like random text, but it can still be a connection credential; do not post it publicly. A small excerpt with the error type, sequence, and redacted fields is usually more useful for discussion than a complete data dump.

Before clearing logs, save a few entries directly related to the issue, especially a before-and-after comparison. Do not erase everything after each failure and then rely on memory to describe it. To collect a fresh sample, mark a clear starting point and reproduce the issue once. If the problem is hard to reproduce, recording the trigger conditions and the last known-good conditions is more useful than accumulating unlabelled logs.

If the records show that the basic connection succeeded but one service fails, investigate that service's rules and response conditions. If the log stops before the server connection, return to DNS and network checks. Summarize the “conditions, action, symptom, evidence, and rollback result” to connect your findings to the sections above and continue narrowing down the issue with the troubleshooting categories in the FAQ.

07 / Widget & iCloud

Widgets, iCloud Sync, and Configuration Backups

A Widget Is a Shortcut, Not a Separate Connection Setup

Widgets provide convenient shortcuts or status displays. The available types, interactions, and content depend on what the app and system currently support. A Widget is not a separate set of server parameters and is not conclusive proof that a background connection succeeded. If its display differs from Home, open the app to check the connection, then see whether the system has refreshed the Widget. Do not change DNS or the server port based on the Widget display alone.

Before adding a Widget, make sure the app can connect and disconnect normally. Then use the system's add and edit flow to select an option provided by Shadowrocket. If there is a choice of content, select what you need; you do not have to add every available option. Use the items currently shown in the interface as your reference. This guide does not specify Widget sizes, layouts, or button counts, since system differences should not be mistaken for missing configuration.

After starting an action from a Widget, check the status in Home or through an actual request. Device lock state, system refreshes, and app state can all affect when the display updates. A card that has not changed and a connection that was not established are separate things to verify. If in-app controls work but the Widget does not update, check the Widget and system display conditions first. If the app also fails, investigate the network and logs as described above.

iCloud Sync Is Not a Standalone Backup

iCloud sync can sync data supported by the app when account and system requirements are met, but do not infer what is included from the feature's name. Check the actual settings to see which items are involved and whether sync is enabled, and confirm that both devices use an eligible iCloud account. The account used for App Store purchases and the iCloud account in system settings are different account roles; being able to get the app again does not prove that configuration data has synced.

First confirm the baseline on the device with the complete data, then set up the other device. Avoid making extensive edits to the same configuration on both devices at once; it becomes difficult to tell which one provided the final version. Check results again when an offline device reconnects. Confirm sync by checking file contents, server details, and actual connectivity—not just by seeing that a sync option is enabled.

Sync propagates changes, so it is not an unchanging historical copy. An accidental deletion or edit may affect other devices through sync. Before making major rule changes, save a separate copy of the current configuration and label its purpose somewhere you control. Give backup files recognizable names, but do not put passwords or complete subscription links in the filenames. Treat the files themselves as sensitive configuration and do not upload them publicly.

Exported content and verification after migration

When exporting a configuration file, open the copy and check which sections it actually contains. Do not assume one file includes every Setting, server, and system permission. Subscription content, manually added servers, and local rules may be stored separately; check what the app's export actually includes. Before switching devices, keep the original subscription details, necessary server parameters, and copies of local rules, and note what each item is for.

After restoring data, first check that the file is complete, then confirm the active Config, Global Routing mode, and selected server. System VPN authorization is a system-level process; follow the prompts on the new device rather than relying on a text configuration. Next, test a manual connection before checking On Demand and Widgets. This order separates data recovery issues from automatic trigger issues, instead of leaving you with one vague failure after restoring everything at once.

If the old device works and the new one does not, leave the old device unchanged as a point of comparison. Compare the networks, active configurations, authentication fields, and sync results one by one. Find the difference before changing the new device. Do not clear the old device to “force sync”; that removes the most valuable working baseline. For account issues when getting the app, see Restore a Previous App Store Purchase and handle them separately from configuration migration.

For more on preparing files and migration steps, see iCloud Sync, Configuration Export, and Device Migration. For checking the account used to restore a purchase, see Restoring Previous Purchases After Switching iPhones. Keeping these processes separate prevents a sync issue from being mistaken for a purchase issue and avoids unnecessary repeat edits.

08 / Verification & Recovery

Settings Verification, Troubleshooting Paths, and Rollback

Choose a Starting Point Based on Scope

When something goes wrong, first ask: “Do all destinations fail, or only some?” If all destinations fail, check basic device connectivity, the system VPN configuration, the selected server, and authentication. If only some fail, check DNS resolution, matched rules, and the response from the affected destinations. This distinction matters more than choosing whether to change DNS or a port first; it tells you what evidence to collect next.

Next, determine whether the issue happened on first use, after a change, or after switching networks. For a first connection failure, check the server details you have and the protocol fields. If the failure started after a change, undo the most recent change first. If it began after switching networks, leave the configuration alone and check access and DNS conditions on the new network. Do not put all three situations through the same series of random adjustments; that can erase clear clues about the cause.

If a connection worked before and an issue started after changing Settings, the most useful step is often to return to the recorded baseline rather than add more changes. First disable temporary On Demand conditions, restore the original Global Routing mode, select the original active Config, and connect manually to the original server. Record the result after each step. If you restore everything at once, you may know it works again without learning what caused the failure.

Using Configuration Snippets Safely for Comparison

This example shows how a readable partial configuration can be organized: [General] contains relevant general options and [Rule] contains ordered rules. It is not a recommendation to overwrite an existing file, and it does not include all the details needed to connect to a server. When editing, locate the relevant sections in a copy of your file. Avoid creating duplicate fields with the same name, and do not remove required policies or other settings when pasting a snippet.

[General]
dns-server = system

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

To verify a rule, make a request that should match the new rule, then check the match result. The example domain only illustrates syntax; its content cannot tell you whether your own service is available. If the new rule does not match, check the active file and preceding rules. If it matches but the connection fails, investigate the connection path for that policy. Correct syntax, a matched policy, and successful content delivery are three separate results to verify.

Criteria for Minimal Recovery and Long-Term Settings

Minimal recovery means restoring a manual connection path that you can explain and reproduce—not deleting all your data. Keep server details that already work, use a clearly defined routing mode and active file, and temporarily reduce automatic triggers and unnecessary test options. If the connection still fails, use logs to find the stage. If it works, restore one feature at a time and test the same destination after each change.

For every setting you plan to keep long-term, be able to answer three questions: What specific need does it address? How can you confirm it works? How can you undo it if it fails? If you cannot answer, keeping the original value is usually better than making another change. DNS endpoints, local Proxy listeners, and automatic connection conditions add more requirements to maintain; do not add them to your device just because someone else uses them.

Getting the app again should not be the first step in recovery. The app is available through the App Store, and reinstalling involves several separate concerns, including purchase recovery, configuration data, and system authorization. It may also remove evidence needed for troubleshooting. Consider reinstalling only when you know what problem it should solve, have saved the necessary information, and understand the recovery steps. The genuine app's developer is Shadow Launch Technology Limited, and its app ID is 932747118. See How to Verify the Genuine App.

If you need to prepare a summary for further troubleshooting, record the network, Global Routing mode and active Config, the action taken, what happened, the log stage where it stopped, and whether reverting the change restored service. Do not share real subscription details or authentication fields. This helps distinguish app settings from your existing server conditions and the destination service, and is more useful than saying “I tried everything and it still doesn't work.”

After troubleshooting, remove temporary test targets, restore your usual log detail, check that On Demand and Widgets behave as needed, and keep a copy of the final configuration. If you update an existing subscription or switch networks later, retest only the affected parts. To repeat the full connection setup, return to the Getting Started Guide. To look up steps for a specific symptom, visit the FAQ; you do not need to change every setting on this page again.