Settings scope and a baseline for changes
Settings, Config, and server parameters
Settings is where you manage app-wide options, typically for testing, logging, automatic connections, and interface features. Config manages configuration files, including rules and related file parameters. The server editor under Home stores the address, port, and protocol fields for an individual connection. All three can affect a request, but their scopes differ. Use the values shown in the current app as your baseline. First identify which layer is involved, then change the relevant setting instead of adjusting every option with a similar name.
Keep global behavior separate from behavior specific to one server. Changing a server's TLS settings usually will not fix another server. Editing rules in the current Config affects request routing when that file is in use. Subscription updates may replace some fields in subscribed items, and remote Config updates may reimport file contents. Before making changes, note the item's name, source, and currently selected Config so you can distinguish what you edited from what is actually in use.
Record Global Routing first
Global Routing sets the overall handling mode: Config uses the current configuration, Proxy routes requests through the proxy path, and Direct connects directly. Config applies the current rules to requests; Proxy sends them through the proxy path; Direct uses a direct connection. Check the app's documentation and actual logs for exceptions. For everyday use, stick with a verified Config. Switch to Proxy or Direct temporarily only for comparison, then restore the original setting so a troubleshooting mode does not become your permanent setup.
| Interface option | Purpose | What to check |
|---|---|---|
| Config | Route according to the current Config | Selected file, rule order, and final policy |
| Proxy | Compare the proxy path | Whether the selected server can complete the request |
| Direct | Compare the direct path | Whether the current network can reach the destination directly |
Establish a repeatable baseline
A baseline is a record of the conditions before a change, not a particular speed score. At a minimum, note whether you are on Wi-Fi or cellular, the server selected in Home, Global Routing, the current Config, the original DNS settings, and the On Demand status. Then choose an accessible destination that is easy to request repeatedly. Note whether the failure occurs during DNS resolution, connection setup, or content loading. Compare before and after under the same network conditions and with the same destination; changing the network, server, and rules all at once makes the cause impossible to isolate.
Change one variable at a time. Copy the Config you plan to edit or record the original value in a secure place, make one change, then reconnect and request the same destination. Some settings do not affect existing connections immediately, and an open page may still show cached results, so verify with a new request. If the issue persists, restore the original value before testing another setting. Stacking several unverified changes turns a local, reversible problem into a combination that is much harder to trace.
System permissions and App Store details
The first time you connect, the system may ask for permission to add a VPN configuration. This authorizes the system to manage the network configuration; it does not verify your server credentials. If you have not granted permission, follow the system prompt before troubleshooting the protocol. Refer to the App Store page for system requirements. This guide primarily covers iPhone and iPad. Check the App Store listing for compatibility and purchase applicability on other Apple devices; do not assume that options appear in the same place across devices.
To verify the app, check its official icon, the developer name Shadow Launch Technology Limited, and app ID 932747118. Purchasing the app grants access to the client; you must provide your own subscription or server details for connections. If you have not installed the app or completed your first connection, return to the setup guide and follow its steps. This guide assumes you can identify your configuration and confirm its source; it does not verify accounts or server parameters.
DNS settings and resolution paths
What DNS does
DNS resolves domain names to addresses. When an app requests a domain, it may first look up an address and then connect to it. Some DNS lookups may also be handled remotely over the proxy path. A domain failing to load does not necessarily indicate a DNS problem, and a successful lookup does not guarantee that the connection will work. Use the values shown in the current app and Config as your baseline. Keep a working resolution path, then investigate a specific failing destination rather than changing DNS servers as the first response to every issue.
Check DNS-related options in Settings alongside DNS parameters in Config. The active source may depend on the current file and enabled features, so looking at just one screen may not be enough. First confirm which Config is in use and record its existing DNS entries. Then review the DNS options in the app. If both locations contain settings, verify them one at a time according to the scope described in the interface. Do not assume a fixed priority based solely on where an entry appears, or add multiple unverified addresses at once.
Standard and encrypted DNS
Standard and encrypted DNS differ mainly in how queries are transmitted. DoH typically uses an HTTPS URL for the resolver endpoint; DoT typically uses a TLS connection to the resolver. Both require the client to reach the endpoint in the first place. Encryption does not determine the routing policy or replace certificate verification. Use a resolver you understand and can reach on your current network, and enter it in the format required by the field. A standard address field and a full URL field are not interchangeable; similar-looking strings do not make them safe to copy between fields.
When an encrypted DNS endpoint is specified by domain name, the client must still resolve that name to reach the endpoint. If basic resolution is unavailable, an endpoint entered only as a domain may prevent the initial connection. Check endpoint reachability, system time, whether the network requires a sign-in, and whether the app's relevant resolution path is working. Compare against your original working DNS settings before investigating further. Do not disable multiple checks at once to bypass an error.
Domain rules and address rules
Domain rules match the domain in a request directly; address rules act on the destination address. When a decision requires address information, the DNS result may affect what happens next. The Config snippet below shows common syntax; it is not a DNS server address and should not be pasted into a DNS field. example.com is included for illustration only, and GEOIP results depend on the data used by the app. When reading logs, keep “what address was resolved” separate from “which rule was selected.”
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYWith an address rule, no-resolve can prevent a DNS lookup from being initiated solely to match that rule; it does not mean the request will never use DNS. Add it only when you understand the matching intent. If a domain expected to connect directly takes the proxy path, check earlier rules and the final policy before assuming DNS is at fault. If the returned address is unexpected, investigate caching, network changes, and the resolver actually in use.
Verification and rollback sequence
To verify DNS, repeat a request to the same domain over the same network and check whether the failure is consistent. Then review any available resolution or connection details in Log. If an address is returned but the connection times out, continue by checking routing and the server. If resolution times out, focus first on resolver reachability and the format of the entry. If only one app fails, also consider its own cache or resolution behavior; one app's result does not establish what happens for all system requests.
After changing DNS, reconnect using the method provided by the app. If you need to clear a cache, use only an option explicitly available in the current interface. Make a new request to the destination and compare the logs. If restoring the original value resolves the issue, the change is likely related. If the failure continues, check the current network, Config, and protocol fields. Keep a verified baseline; adding more DNS entries whenever the network changes can make it impossible to tell which settings are still needed.
On Demand connections
Connection triggers and routing policies
On Demand uses conditions to ask the system to establish or handle a VPN connection. It is not another way to write routing rules: On Demand determines when to connect, while Config determines how requests are handled after connection. Use the status and conditions shown in the current app as your baseline. First verify that manual connections work, then enable only the On Demand conditions you need. If a manual connection fails, automatic triggers will repeat the failure; they cannot supply missing server parameters.
Before setting up On Demand, define the intended outcome: connect on a particular Wi-Fi network, on cellular, or only when a domain-related condition is met. Depending on the condition, the available actions may include connecting, ignoring, or other system behavior; use the actions shown in the interface. “Do not trigger a new connection” does not necessarily mean “disconnect an existing one immediately.” Nor does a brief disconnect after manually switching off the VPN mean the rule is disabled; a later network change may trigger it again.
Wi-Fi and SSID conditions
An SSID is a Wi-Fi network name, not a router's admin address. Enter it exactly as shown, preserving capitalization, spaces, and symbols, and avoid copying an extra line break. Start with one network condition you can test in person: check the system VPN status while connected to that network, then leave it and observe what changes. Multiple access points in a home may use the same SSID, so the name alone does not prove that they share the same network environment or serve as trusted credentials for accessing a service.
If you exclude a particular Wi-Fi network, also check for broader Wi-Fi conditions that may still apply. The order, matching scope, and actions of conditions can all affect the result; follow the order and descriptions shown in the current editor. If the VPN stays connected on an excluded network, first check whether the connection was already established, then whether another condition matched, and finally whether the system configuration was saved. Deleting one condition does not necessarily stop all automatic connections.
Cellular changes and domain triggers
A cellular condition applies when the device uses mobile data; it is not equivalent to a condition for a particular SSID. During testing, make sure the device has actually disconnected from Wi-Fi and that the app has permission to use cellular data. Test both a new connection and an existing connection moving between networks, since the latter may require a session to be re-established. A brief interruption during a network change does not necessarily indicate a bad rule; consider the trigger timing and connection logs.
A domain condition affects trigger decisions related to a particular domain; it does not mean every request to that domain will use a specific proxy policy. System caches, existing connections, and the way an app makes requests can all affect the result. Enter domains in the format accepted by the current field; do not use a full web address with a path as a domain condition unless the interface allows it. Test with a domain you can access and request repeatedly, then check separately whether Config selects the expected policy after connection.
| Condition scope | How to verify | Common misinterpretation |
|---|---|---|
| Wi-Fi / SSID | Join and leave the specified network | Assuming networks with the same name are the same environment |
| Cellular network | Make a new request after confirming the network has changed | The device is still using Wi-Fi |
| Domain condition | Make a new request to the target domain | An existing cache prevented a new check from being triggered |
Automatic reconnection and pausing troubleshooting
If the VPN reconnects after you turn it off manually, first check On Demand and its conditions, then check the corresponding VPN configuration status in the system. To troubleshoot, temporarily turn off On Demand in the app, confirm the change is saved, disconnect manually, and see whether the connection is still re-established. Do not repeatedly delete system configurations, reimport subscriptions, and edit rules at the same time. Those actions destroy the before-and-after comparison and make it difficult to tell a system trigger from a newly installed configuration.
Before re-enabling automatic connections, remove duplicate test conditions, confirm the purpose of each one, and test on Wi-Fi, cellular, and after resuming from the lock screen. Set expectations for background behavior according to what the system actually permits; a single test does not guarantee continuous operation. For detailed scenarios, see how On Demand works with Wi-Fi, cellular, and domain triggers. If you only need manual connections, keep using your verified manual workflow.
Ping and Connectivity Test
What test results tell you
Ping and Connectivity Test show reachability or response time using a particular probe; they do not guarantee that a full service request will work. Depending on the selected method, a test may target the server endpoint or access a test destination through a specified path. Use the method, target, and timeout shown in the current app as your baseline. Read the test description to understand which part of the path it measures before comparing numbers; results from different test methods are not directly comparable.
A reachable endpoint only means the probed address and port responded at that time. Protocol authentication, TLS negotiation, remote DNS resolution, or the destination service may still fail. Conversely, a probe that gets no response does not necessarily mean a normal request cannot succeed, since a server may restrict certain probes. Use the test to narrow down the issue, then make a new request to an accessible destination. Do not treat a single green status or timeout as a definitive result.
Test targets and timeouts
Choose a test target you are allowed to access, with a stable response and a clear purpose. If the app expects a full URL, enter it in that format; if it expects only a host or port, do not paste a full web address. Redirects, sign-in requirements, or request rate limits can make the result unrepresentative of normal use. Verify that the target itself works before comparing servers. If every item times out, do not start changing protocol passwords one by one.
The timeout sets the maximum time to wait for a result; it does not improve network performance. Too short a timeout may mark a slow but usable connection as failed, while a longer one makes batch tests take more time. Keep the original value unless you have confirmed that the network is slow but the request eventually completes. If you change the timeout, record the new value and compare repeated tests on the same item. Extending the wait just to get a “success” makes the test less useful for detecting problems.
Keep conditions consistent when comparing
A meaningful comparison requires, at a minimum, the same network, test method, target, and roughly the same test time. Do not directly compare Wi-Fi with cellular results, or foreground tests with results collected during a network transition. Test the server you actually plan to use, then compare it with other existing entries. Batch tests generate requests at the same time and can be affected by temporary congestion or device state. Do not keep switching automatically just because the sort order changed once; that can cause unnecessary reconnections.
Lower response time does not mean higher throughput or a better app experience. A small probe measures only one stage, such as connection setup or receiving a response. Large transfers, video buffering, and long-lived sessions depend on other factors. To judge everyday usability, check whether real requests complete, whether failures recur, and whether the connection recovers after network changes. Repeat tests enough to rule out one-off results, but do not probe constantly in pursuit of a perfectly stable number.
Locate the failure by stage
If all existing entries fail at the same time, first check the local network, test target, system time, and whether the network requires a sign-in. If only one entry fails, check whether it has expired, whether its address resolves, whether the port is correct, and whether all required protocol fields are present. If the test succeeds but a browser request fails, check Global Routing, Config, DNS, and the destination instead of rerunning the same test and expecting the service request to recover.
Verify protocol fields against your own server details. Shadowsocks uses an encryption method and password; VMess and VLESS have their own identity fields; Trojan requires authentication and TLS details; WireGuard uses its own keys and address ranges. A shared “port” field does not make the protocols interchangeable. Unless the test provides direct evidence about a field, do not guess its value based on response time. Compare each field with the original details and keep a recoverable copy.
After making changes, stop unnecessary batch tests, reconnect, and try the actual destination so probe traffic does not cloud the results. If the issue persists, record the test method, approximate time, network type, and a sanitized error category. Continue with the connection timeout troubleshooting checklist. You do not need to include a full subscription URL, credentials, or an entire Config when sharing diagnostic information; the failure stage is usually enough.
Log and Data diagnostics
What Log and traffic statistics are for
Log helps you review recorded connection events, errors, and request handling. Data shows traffic statistics provided by the app. Neither is a complete network audit, and neither replaces the destination's response. Use the recording status, retention range, and statistics period shown in the current app as your baseline. Review the relevant options before reproducing an issue, enable only the diagnostic detail you need, and note when you start observing so you do not search unrelated historical entries.
Start by checking the scope of a statistic. A page may show data for the current session, a particular server, or a cumulative total; do not add figures from different scopes and treat the result as a carrier bill. Restarts, resets, switching objects, and sync behavior may also change the baseline shown. Compare the same statistics page before and after one controlled request to confirm what it measures. For overall device usage, consult the system's own statistics rather than using one in-app counter to infer all network activity.
Build a timeline from a single reproduction
Keep a useful reproduction as short as possible. Confirm the current network, server, Global Routing, and Config, then open the diagnostic view and note the time. Perform just one operation that reproduces the failure. Return to Log and focus on events around that time, following the stages of resolution, connection, negotiation, and response. Opening several apps, updating subscriptions, and running batch tests at once will add unrelated requests and make it harder to identify the error associated with the issue.
Keep the surrounding context when reading an error. A connection timeout means a stage did not complete within the waiting period; it does not prove the remote service is permanently unavailable. A connection refusal usually calls for checking the destination port and service status. Certificate errors call for checking the time, domain, and TLS settings—not disabling verification outright. The exact wording varies by protocol and request, so use the text actually shown in Log rather than expecting the categories in this guide to appear verbatim.
Use logs to verify rule selection
If the current interface exposes the relevant details, check the request domain, destination address, matched rule, and selected policy. If a request takes an unexpected path, first confirm it used the current Config, then check whether an earlier rule matched. If the log shows an address but no domain, do not assume a domain rule was involved. The app may already have resolved the name, or the connection may use a different method; limit conclusions to what the available evidence shows.
| Observed result | Check first | What you cannot conclude from it alone |
|---|---|---|
| Failure during DNS resolution | DNS format and resolution path | All servers are unavailable |
| Connection to the endpoint timed out | Local network, address, and port | That an authentication field is definitely wrong |
| Unexpected policy matched | Global Routing and rule order | That DNS is necessarily misconfigured |
| Data keeps increasing | Statistics scope and current request | That the destination content loaded successfully |
Sensitive information in logs
Log, subscription URLs, and Config files may contain visited domains, server addresses, user identifiers, and authentication details. Before exporting or sharing a screenshot, review it in a secure location and redact sensitive data, especially URL query parameters and full lines containing credentials. Keep only the necessary lines near the error and hide anything that could identify an account. Preserve the event order and error type; otherwise, redaction may remove the information needed to troubleshoot.
After troubleshooting, use the options provided by the current app to turn off any extra detailed logging you enabled, and clear local records you no longer need if appropriate. Keeping large amounts of history makes it harder to find relevant events and may leave additional traces of access. Turning off Log does not necessarily delete existing records, and clearing Data does not delete subscriptions or servers. Each action affects something different; read the confirmation prompt before proceeding to avoid deleting a configuration by mistake.
A sound conclusion should follow a clear chain of evidence: the network used, the item selected, the request made, the resulting log, and what changed afterward. If you cannot establish that connection, return to the simplest reproducible scenario instead of broadening the logging scope. For issues involving system settings, the current Config, and requests, read this chapter alongside the DNS and Config sections. The troubleshooting FAQ at the end can also help you revisit common error patterns.
Widget, iCloud sync, and saving configurations
What a Widget can and cannot do
A Widget is a system-provided way to display app information or offer quick actions. Its visible content and interactions depend on the device's system and the current app implementation. Use the system and app interfaces to check whether a Widget is available and what it displays. First complete a normal connection in the app, then add a Widget if needed. Seeing the Widget on your Home Screen does not mean the VPN is connected, and a stale display does not by itself mean the server has disconnected.
Use the system's Widget editing flow to find Shadowrocket and choose from the styles currently available. If Settings offers a related display option, adjust it for your needs. The system controls when Widgets refresh, so their display may not update at the same time as the app. After important actions, open Home to check the connection and selected server—especially after changing networks, editing a configuration, or finishing a test. Do not rely on a shortcut display that may not have refreshed as your only source of truth.
How quick actions relate to automatic connections
A Widget action is a shortcut for initiating an action; it does not change the authentication requirements for a server or the basic requirements for Config. If system authorization is incomplete, the selected item lacks required parameters, or On Demand conditions are still active, the result may differ from what you expect. Check these issues in the app first, then test the Widget again. If its status keeps changing after you tap it, check On Demand instead of repeatedly removing and re-adding the Widget to fix connection behavior.
iCloud sync is not a subscription update
iCloud sync applies only to data supported by the current feature. It does not request the latest subscription from your service provider, and it does not guarantee that system permissions or temporary state will be copied to another device. Use the sync options and supported data described in the current app as your guide. First check the accounts, iCloud permissions, and network status on both devices, then confirm which items the app can sync. Installing the app on another device does not mean all connection items are ready to use there.
Subscription updates, remote Config updates, and iCloud sync are different actions. A subscription update may change the server list in that subscription; a Config update may replace rule contents; sync may transfer saved data to another device. If something changes back after editing, first identify which action occurred rather than assuming it was a sync issue. Record where each item came from, and avoid editing the same item on multiple devices at once—especially while a remote update might overwrite a local copy.
Sync conflicts and deletion propagation
A sync conflict occurs when the same data has been changed differently on multiple devices. Which version is kept depends on the app's current behavior; do not assume the version you see most recently is the only correct one. Before resolving a conflict, save any valuable configurations from both devices in a secure location. Decide which copy to keep, then merge or reimport items individually. Do not repeatedly toggle sync or delete items to force a refresh before you understand the sync direction; deletions may also propagate.
Keep server details, subscription sources, and Config files distinct when saving copies; do not combine them into one export that is difficult to identify. Name files by their purpose and note your own changes, but do not include passwords or full subscription URLs in filenames. Store material containing credentials somewhere secure. After importing, check the number of items and key fields. A backup is verified only when you can restore it and confirm that it works—not merely when a file has been created.
Verification steps when changing devices
When moving to a new device, get Shadowrocket from the App Store first. See moving to a new device and restoring a purchase for information about restoring purchases and purchase applicability. Then check the synced or imported data and complete any system authorization required on the device. VPN permissions, Widget layouts, and the current network environment are not automatically identical to those on another device. First connect manually using a server whose parameters you have confirmed are complete; restore On Demand and display options afterward.
Finally, confirm that both devices are using the intended Config and check whether local changes remain after a subscription update. Keep a note of why you changed important rules so you can review them after updates. If only one device has an issue, first compare its permissions, network, and selected items; do not immediately delete a working configuration from the other device. Following the sequence “get the app, restore data, verify manually, then restore automation” makes it easier to preserve a working baseline.
Proxy ports and server protocol settings
Local and remote ports
First distinguish the direction of Proxy-related ports. A local listening port accepts requests explicitly configured to use that entry point; a server port is the endpoint of your own remote service. They are not the same number and cannot be used interchangeably. Use the port, listening scope, and feature status shown in the current app as your baseline. Keep the original value unless you have a specific reason to change it. Change a setting only when you need a local proxy entry and understand how requests reach it.
When changing a local port, check the accepted range and whether the feature is enabled. Avoid conflicts with other listening services. Requests explicitly configured to use the old port will not automatically know the new value, so update their connection settings too. If the interface offers an option such as allowing access from other devices, check the listening scope and access conditions on the network. Allow access only where needed; it is not a speed setting, and minimizing the app does not guarantee that the entry point will remain available.
Do not reuse protocol fields across protocols
Edit remote servers using the complete parameters you already have. Shadowsocks typically requires an encryption method and password; VMess and VLESS use their respective identity fields and transport settings; Trojan usually requires authentication and TLS details; Hysteria2 and WireGuard have their own authentication, key, and address fields. Confirm the protocol type first, then check the required fields shown in the current interface. Do not try a password from one protocol in another protocol's identity field.
Items imported through Subscribe may have missing fields, a format mismatch, or outdated details. Successful import means the app recognized and saved some content; it does not prove remote authentication succeeded. If you edit an item from a subscription, note that a later update may overwrite your changes. Keep the original details for comparison, and verify each field only for configurations you are authorized to use. Do not try to probe the server by randomly changing the protocol type.
| Field | What to check | Do not confuse with |
|---|---|---|
| Address and port | Remote host and service endpoint | Local Proxy listening port |
| Authentication details | Identity or password required by the selected protocol | App Store purchase account |
| TLS / SNI | Certificate domain and server requirements | Any domain that hosts an accessible webpage |
| Transport settings | Existing path, Host, and related configuration | An arbitrary address for the destination webpage |
TLS, SNI, and system time
TLS establishes an encrypted connection subject to certificate verification. SNI usually identifies the relevant server name during the handshake. The address, certificate domain, and corresponding fields in the app may differ; get the correct values from your own server details. Keep certificate verification enabled, and check the domain spelling, device time, and any required intermediate configuration. If you see a certificate error, do not mask it with an unrelated domain or by turning off verification; that changes the assumptions used to validate the connection.
Transport fields also need to be exact. Paths may be case-sensitive, Host may serve a different purpose from the connection address, and extra spaces can make a request fail to match. Copy the original values for reference before editing. After a change, reconnect and see whether the failure progresses from endpoint connection to protocol negotiation or response. If the error is unchanged and there is no clearer evidence, restore the original value. Changing several fields repeatedly can make the original working details hard to recover.
The limits of remote configuration and local settings
Some features require support from the remote server; a local switch alone cannot add that support. A reachable port does not prove the server has enabled the selected protocol, and a successful test does not prove every transport method is available. With WireGuard, the address range and routing intent must match the existing configuration. Other protocols likewise require compatible authentication and transport settings. Treat the server details as a related set of parameters, not values to combine at random.
After checking the server details, verify one server without changing the rules, then return to Config to check the policy for the destination request. If a destination still fails, determine whether it did not use the selected server or whether the server could not complete the request. The local Proxy entry, remote connection, and destination request are connected but distinct stages; each needs its own evidence. If you do not need a local listening feature, there is no need to change its port to troubleshoot remote authentication.
Config rules, verification, and rollback
Rule order and the final policy
Config stores settings used to process requests. Rules are evaluated in order, and the first applicable match determines the policy; FINAL handles requests that did not match an earlier rule. The active rule set is the file currently selected. Understand its intent before adding rules. Editing a file that is not selected will not immediately change current requests. Before testing, return to Config to confirm which file is in use and check that Global Routing is set to Config.
Rule keywords determine what matches; the policy determines what happens after a match. DOMAIN matches an exact domain, DOMAIN-SUFFIX matches a domain suffix, and DOMAIN-KEYWORD matches a domain containing the specified keyword. IP-CIDR and IP-CIDR6 match address ranges; GEOIP uses geographic IP data. PROXY, DIRECT, and REJECT express different policy actions. Do not swap the positions of match keywords and policies. Prefer conditions with a clear scope to avoid broad keywords matching unrelated requests.
[Rule]
DOMAIN,api.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR6,fc00::/7,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYIn this snippet, api.example.com matches the exact rule first. Other domains ending in example.com use the subsequent policy. The address-range rule illustrates a direct-connection intent; local address plans are not necessarily the same on every network. This snippet explains syntax and order and is not a complete configuration for everyone. Add only the rules you need to a backed-up file and test them individually rather than replacing all of your existing content with these lines.
Remote updates and custom changes
A remote Config update may bring in new rule content. Check how the current app handles saving and updates to determine whether local changes will remain. Keep the original remote file separate from a working copy, and note why each rule was added and which destination you tested. Track subscription server lists and Config rule sources separately: updating one does not update the other. If something changes, verify which item was actually updated before attributing it to a change in rule order.
If a request does not match the expected rule, check in this order: is Global Routing set to Config, is the correct file selected, is there a broader earlier rule, is the request still using the original domain, and does FINAL apply before another rule can match? Some apps may make requests using only an address or follow a redirect to another domain, so the first domain you see may not cover the entire request. Use the details available in Log to identify what matched before deciding whether to add a domain or address rule.
Complete a full verification cycle
A complete change includes a pre-change baseline, one change at a time, a new connection, a request to the same destination, and a record of the result. Success means the intended destination works through the intended path without disrupting other necessary requests—not merely that a switch remains enabled. First test on the same network, then check another network you use regularly. If On Demand is enabled, confirm that an automatic connection uses the intended Config too; do not verify only the manual connection.
Roll back the item you just changed; there is no need to reset the entire app immediately. For a rule issue, restore the file. For a DNS issue, restore the DNS setting. For a protocol issue, restore the relevant server fields. Consider a broader rebuild only if you cannot identify the current state and have saved important data. Repeat the same request after restoring the original setting to confirm the baseline is back. If it still fails, the network or remote service may have changed, so establish a new baseline under the current conditions.
Frequently asked troubleshooting questions
Why did changing Settings not affect the page that was already open?
An existing connection, app cache, or current configuration source may still affect the result. Confirm the change was saved and applies to the right scope, then reconnect and make a new request. Do not stack more changes on top of it.
Does an enabled connection switch mean the configuration is correct?
The switch reflects only part of the connection state. Check that the destination request completes, the intended server is in use, and Config applies the expected policy. Review Log if needed.
Why should I recheck local changes after updating a subscription?
A subscription update may reimport server fields. Compare the server parameters before and after the update, and keep notes on personal changes you need to maintain. Do not assume a manual edit will never be replaced.
If you have not completed your first import, follow the step-by-step setup guide. To check rule scope and the placement of FINAL, read custom rules and final policy. Use this page to look up the section for the stage where the failure occurred: preserve the original values, make only a few changes, and verify against the logs rather than enabling every setting at once.