Shadowrocket
Settings Guide
Use the setting’s scope, connection path, and test results as your guide. Check the current value first, then change one variable at a time. If a default cannot be reliably confirmed, use the value shown in the app.
- What settings mean
- Checking default values
- Recommended values
- Troubleshooting rules
This page is the settings reference section of the Shadowrocket User Guide. If you have not completed your first connection, start with the quick-start guide to import your existing server or subscription, select a server, and verify the connection. Then return here to look up specific settings. If you can connect but are having trouble with DNS, automatic connections, tests, or sync, go straight to the relevant section.
This guide assumes you already have your own subscription or server details. A one-time client purchase is not a service plan. This site does not provide, sell, or recommend nodes or subscriptions. Shadowrocket is a closed-source commercial app, available exclusively through the App Store. For purchase details, compatibility, and system requirements, see the App Store purchase and access guide; refer to the App Store listing for system requirements.
Names of app sections such as Settings, Home, and Config are kept in English. Some options vary with the active configuration, device, and app state. The suggestions here are starting points for troubleshooting, not fixed settings for every environment. Before making changes, save the Config you are using and note Global Routing, the selected server, and relevant toggles so you can distinguish existing behavior from the effects of your changes.
Global Routing and setting scope
Global Routing determines the overall handling mode for connections. Check it before reviewing Settings. In the interface, Config, Proxy, and Direct are the three available modes. They are separate from the connection toggle at the top: the toggle indicates whether the client connection is running, while Global Routing determines how connections are handled when it is running. A VPN status indicator in the system does not, by itself, prove that a particular destination is using the selected server.
Distinguish the overall mode from individual rules
Config uses rules in the active configuration to choose a policy, which is useful when connection paths need to vary by destination. Proxy primarily routes traffic through a proxy and can help test whether an existing server handles a particular request. Direct primarily connects directly and is useful for comparison. Check the active configuration and app documentation for details about what each mode preserves; do not assume a mode name guarantees identical handling for every type of system traffic.
| Interface value | What it means | Suggested use |
|---|---|---|
| Config | Uses rules in the active Config to choose a policy | Everyday rule-based routing and rule-match checks |
| Proxy | Primarily handles connections through a proxy | Set rules aside to test the server path |
| Direct | Primarily handles connections directly | Compare local network access with destination reachability |
If switching to Proxy restores access, that only shows a correlation between the change in overall route and the result; it does not prove that a rule is wrong. Check whether the server also changed, whether an existing connection was reused, and whether the domain was resolved again. Likewise, opening a destination in Direct mode does not prove that the proxy settings work. For a valid comparison, keep the destination, network, and server fixed, change only the mode, and start a new connection for each test.
Check the boundaries between Settings, Config, and server settings
The same issue can involve three layers: app-level options in Settings, rules and DNS settings in Config, and protocol parameters on the server edit screen. A value appearing in one place does not mean it overrides a setting with the same name elsewhere. First confirm which Config is active, then check it for related entries. After importing a file, verify through actual behavior and Log whether your app-level selections still apply; do not infer that from the file’s presence alone.
Check default values by layer, too. Values seen on first install may differ from those after restoring data or importing a configuration. For items whose defaults cannot be reliably confirmed, this guide uses “use the value shown in the app.” Record the setting name, where it appears, its value before changes, and the expected effect—for example, “compare DNS methods only; do not change servers.” This is more useful for restoring settings than a partial screenshot without context.
Establish a repeatable baseline
When troubleshooting, start with a known-working server that you maintain yourself. Check its selection indicator in Home, then note Global Routing and the active Config. Pause automatic subscription updates and any conditions that may trigger reconnections, and keep the environment stable during testing. Restore your usual settings afterward. Use a test destination whose status you can verify; do not compare results from unrelated websites.
Record the steps for each test: disconnect, change one setting, reconnect, make a new request, and check the relevant records. If the result is unexpected, restore the previous state and test again to see whether the issue is reproducible. Browser caches, ongoing downloads, and persistent background connections can all reuse existing results, so refreshing a page does not always create a new connection. If needed, close the page and reopen it; there is no need to clear all app data after a single failure.
DNS: resolution methods and connection paths
DNS translates domain names into addresses that can be used for connections. If a domain will not open but entering an address gives a different result, check DNS—but do not immediately change every DNS option. Whether a DNS request succeeds, whether the returned address works on the current network, and which policy handles the subsequent connection are three separate questions. A successful DNS response only means an answer was returned; it does not confirm that the destination port, TLS handshake, or page content is accessible.
System DNS, custom DNS, and encrypted DNS
System DNS uses the resolution setup provided by the current system and network, making it a useful baseline. Custom DNS specifies a different resolver, allowing you to control where queries go; that resolver must be reachable in your current environment. DNS over HTTPS sends DNS queries over HTTPS, adding dependencies on the resolver address, certificate, and connection path. Choosing this method does not mean all subsequent traffic follows the same policy; check DNS and traffic routing separately.
Start with the DNS method that currently works. If you need to change it, record the existing entries and their order, replace just one resolver, reconnect, and test the same domain. Avoid adding multiple resolvers in an attempt to improve the odds: differences in returned results, response timing, and caching can make the problem harder to reproduce. If the resolver’s own address requires DNS lookup, consider whether that address can be resolved during initial connection; otherwise, the settings may depend on each other.
| Method | What to check | Recommended values |
|---|---|---|
| System DNS | Whether DNS provided by the current network is working | Use as an initial comparison, not as a fixed resolver address |
| Custom DNS | Address format, reachability, and resolution results | Use a resolver you have confirmed is available |
| DNS over HTTPS | Full endpoint, certificate, and access path | Change only when needed, and keep the original value for rollback |
Check for overrides, cached results, and address types
Config may contain DNS-related entries, so checking Settings alone may not be enough. If the behavior does not change after an edit, first check the active file for related settings, then confirm that the test request did not use a cached result. Different layers may cache answers independently, and reopening a webpage does not necessarily trigger a fresh lookup. A new DNS entry in Log is more useful than repeatedly refreshing the page; do not mistake a cache hit for a new DNS response.
A domain may return both IPv4 and IPv6 addresses. If one network path is unreachable, the result may be a long wait followed by success or failures affecting only some requests. Check the returned address type and connection errors rather than assuming the resolver is at fault. Whether to enable a related option depends on the current network, server capabilities, and destination; use the value shown in the app as the default. After changing it, verify that destinations that worked before still work.
Choose the next step based on where the failure occurs
If DNS returns no answer, check the resolver endpoint’s format, network reachability, and where the setting takes effect. If an address is returned but the connection times out, check routing policy and server settings. For certificate errors after a connection is established, check the requested domain, device time, and relevant server parameters; do not try to fix a certificate issue by repeatedly changing DNS. If a website returns an application-level error page, the network connection may already be working, so changing DNS is unlikely to help.
For local device names and LAN services, consider the scope of name resolution. Public resolvers may not know names used on a home or office network. Sending all DNS requests to the same external resolver can disrupt local access that previously worked. Keep the original configuration and test one local destination alongside one ordinary domain. The goal is to make DNS behave as needed, not to add more protocol names to the configuration.
On Demand: triggers and automatic connections
On Demand uses configured conditions to trigger connections. It does not repair servers or update subscriptions. When a condition is met, the system may attempt to connect as configured; success still depends on the current server, configuration, and network. If a connection returns after you manually turn it off, first check whether an active condition is still enabled rather than assuming the top toggle is faulty or the app is displaying the wrong state.
Decide what you want to automate first
Before configuring On Demand, define the goal—for example, connecting only on certain networks or keeping the connection active across network changes. Then check the condition types and matching behavior actually available in the app; do not copy field names from another interface. If you want to match a Wi-Fi network by name, check the exact spelling, including spaces and similar-looking characters. Networks with the same name can exist in different places, so the name alone does not verify network identity.
Use the values shown in the app for the default toggle and initial conditions. If you are still troubleshooting your first connection, pause On Demand and confirm that a single server works manually before adding automatic conditions. Otherwise, connection failures and repeated triggers can overlap, producing similar entries in Log that are difficult to associate with a specific action. When re-enabling automation, add one clearly purposeful condition at a time.
System permission and network changes
When you first connect, the system may ask permission to add a VPN configuration. Check the app name and follow the system prompts. Granting permission does not mean every automatic condition is enabled, and enabling a condition does not guarantee that system authorization is complete. If the app shows a condition as enabled but the system cannot establish a connection, check authorization and connection errors separately. For system requirements and device compatibility, refer to the App Store listing rather than inferring current support from older devices.
Switching between Wi-Fi and cellular can change network reachability and interrupt existing connections. To test On Demand, keep the network fixed and check whether the condition triggers; then make one deliberate network change and record the status before and after. Do not also change servers or Config, or a restored connection will not confirm that the automatic condition is correct. If the network requires a sign-in page, complete that network’s access steps before testing the proxy connection.
| What you see | Check first | Next step |
|---|---|---|
| Reconnects after being turned off | Whether an automatic trigger is still active | Pause the condition and repeat the manual disconnect |
| Does not connect after switching networks | Whether the condition matches the new network | Manually test server reachability on the new network |
| Repeated connection attempts | Server errors and network access status | Pause automation and reproduce the connection failure on its own |
Troubleshooting differences between automatic and manual behavior
If a manual connection works but an automatic connection does not behave as expected, check the trigger conditions before changing protocol settings. Confirm that the conditions were saved, that the current network actually matches them, that no other condition triggers a different action, and that system authorization is still valid. If manual connections fail too, return to troubleshooting the server and DNS. Separating these cases can prevent you from rebuilding all your existing data to fix one automation issue.
Another common issue is assuming that a connection has stopped when the app leaves the foreground, even though the system connection remains active. Whether the app is in the foreground and whether the system network extension is running are separate states. Check the system connection status and the display when you reopen the app; do not treat the background app list as a connection toggle. To stop automatic connections, first disable any active On Demand conditions, then disconnect and confirm the result so a condition does not immediately reconnect.
Before relying on On Demand, verify at least three cases: it connects when a condition is met, behaves as expected when the condition is not met, and reports errors when the server is unreachable. Automatic connections should reduce repetitive steps, not hide failures. If the device is managed by an organization, system restrictions may apply; follow the prompts shown on the device. Repeatedly removing and adding configurations is not a substitute for checking conditions and authorization.
Ping and Connectivity Test: what results can tell you
Ping and Connectivity Test help you observe connection status, but different test methods measure different things. A response from the server address does not mean proxy authentication succeeded; a proxy reaching a test destination does not mean every service will work. Before interpreting a result or error, check the test method, destination, and server being tested. Do not turn a result from one part of the path into a conclusion about the entire network.
Distinguish network reachability from proxy availability
Ping-related settings may affect how the server list tests connections. The available options and defaults are those shown in the app. A network-layer response mainly indicates whether the address path responds; a port connection test mainly checks whether the port accepts connections; a test that accesses a destination through the proxy also depends on the protocol, authentication, DNS, and destination service. The more layers a test involves, the more possible causes of failure it has. A single failure indicator cannot identify which layer is at fault.
For example, a server address may be reachable even if the password or TLS name is wrong, so a basic reachability test can disagree with an actual request. Conversely, some networks do not return a particular probe response even though real requests work. If results differ, keep both results and check real connection records instead of changing server settings just to make every item in the list show success. Server parameters should match the details you already have; a test result is not a substitute for configuration facts.
Choose a stable, well-understood test destination
Use a destination whose purpose and status you can verify. If the setting accepts a URL, check that the scheme, domain, and path are complete. Redirects, sign-in requirements, or temporary access restrictions can affect the result. Do not rely on a frequently changing service page as your only benchmark. When changing the test destination, change only that value—not the timeout or server—so you can identify what caused the result to change.
A timeout that is too short can mark a valid but slow connection as failed; one that is too long increases wait time and can make batch results harder to interpret. Use the value shown in the app as the default. Keep the current value unless repeated tests under the same conditions consistently approach the timeout limit. A longer timeout will not fix incorrect credentials, a wrong port, or an invalid certificate, nor can it make an unreachable destination accessible. Check the error type first.
| Observed result | What it indicates | What still needs checking |
|---|---|---|
| Address or port is reachable | One part of the path responded | Protocol, authentication, and actual destination |
| Connectivity Test succeeds | The destination was reachable under these test conditions | Real requests and rule-based routing |
| Test timed out | The test did not complete within the wait period | DNS, connection, authentication, and destination status |
Make comparisons meaningful
Test the currently selected server on its own first, then compare other existing servers using the same destination. Keep the network, Global Routing, and Config fixed, and avoid refreshing subscriptions during the test. Batch tests may generate several requests at once, so their load conditions differ from a single request. Use them for screening, then retest unusual results individually; do not repeatedly change your configuration based on one batch ranking.
To verify a first connection, also make a real request: confirm the selected server in Home, turn on the connection, visit the destination, and check Log. A server-list test may target a particular entry, while real traffic uses the currently selected server; make sure the two correspond. For a fuller walkthrough, see First connection and Connectivity Test verification. If a test succeeds but a page fails, compare the destination and rules before changing test settings.
When recording results, note the test method, destination, network type, selected server, and error text. There is no need to share a full subscription. Repeated tests over a short period only describe conditions during that period; test again after network conditions change. Use tests to answer a specific question, such as “Can this port accept a connection?” rather than chasing a lower number without context.
Log and Data: trace the failure stage
Log helps reconstruct what happened during a connection, while Data shows traffic-related information. Interpret both within a defined time window. An increase in total traffic only means that data passed through the measured range; it does not prove a page loaded successfully. A connection entry does not prove that the full request completed. Start by identifying the destination and time of the operation, then look for the corresponding DNS response, policy selection, connection, and failure stage.
Narrow the log scope before reproducing the issue
Use the values shown in the app for Log controls, detail level, and retention. Keep only enough detail to identify the problem during reproduction, then restore your usual settings. The more detailed the records, the easier it is to include background apps, embedded page resources, and repeat connections. Without narrowing the scope first, more data can make diagnosis harder. Before you start, pause unrelated tests and subscription updates, note the current state, and perform the target action once.
If the interface lets you clear records, first save anything you need to keep, then clear the records for this observation. Otherwise, note the starting point or operation time. Reconnect to the destination so the browser does not reuse an old connection without generating a matching entry. Do not visit several unrelated pages during one reproduction; it becomes difficult to separate the page’s main request from other resources. The most recent error is not automatically related to the target you are investigating.
Distinguish DNS, connection, authentication, and service responses
If DNS returns no result, check DNS settings. If an address is returned but the connection times out, check the network, port, and selected route. For authentication or handshake errors, check that the server fields match your existing details. For TLS errors, also check the name, certificate requirements, and device time. If the destination service returns a rejection or application-level response, several earlier network stages may already have succeeded; focus on the response itself.
When troubleshooting rules, the key question is not whether a domain appears in Log, but which rule it matched, which policy was selected, and where the connection was sent. A page often uses multiple domains, so a working main domain does not rule out other resources being handled differently. Identify the request that actually failed, then inspect its match result. If Log does not show enough detail, do not guess at missing information; test the hypothesis with a single-rule comparison and repeatable tests.
| Failure stage | Check first | Avoid this misdiagnosis |
|---|---|---|
| DNS resolution | DNS source and resolver reachability | Blaming the server password immediately |
| Connection establishment | Address, port, network, and policy | Assuming a timeout means the rule syntax is wrong |
| Authentication or handshake | Protocol fields, TLS name, and device time | Trying to fix mismatched fields by extending the timeout |
| Service response | Destination service and actual request | Treating every error page as a connection failure |
Traffic statistics and privacy
Interpret the measurement range, counting start time, and display units in Data according to the current interface. Other apps may also generate traffic while connected, and cached pages may add very little data, so the total cannot tell you the exact size of a particular request. To compare results, keep the observation window fixed, perform one clearly defined action, and record the change. If statistics were reset or the device reconnected, note that the measurement range changed.
Logs may contain destination domains, addresses, server names, and other details that reveal how you use the app. Before sharing, remove subscription URLs, credentials, personal identifiers, and unrelated connection records; keep only the minimum needed to diagnose the issue. Even an ordinary-looking URL may contain access credentials. Do not post a complete export publicly. In examples, you can replace real domains with example.com while preserving the error type and field structure.
After troubleshooting, restore changed settings or save them as a clearly documented baseline, and turn off detailed logging if it is no longer needed. If the issue remains unexplained, organize the details as: expected behavior, actual behavior, fixed conditions, the single change made, and the corresponding error. This avoids repeating tests while preserving useful context. “It won’t connect” or a cropped error screenshot is usually not enough to identify which setting needs attention.
Widget, iCloud sync, and managing existing subscriptions
Widget provides a shortcut or status display, while iCloud options save or sync app data within their supported scope. Neither controls the connection route. A stale display does not, by itself, indicate a system connection problem. Seeing a configuration on another device does not mean that device has selected the same server or uses the same Global Routing mode. Verify convenience features separately from the actual connection state.
Widget display and actual connection status
Widget formats, displayed fields, and default behavior depend on the current system and app. The system schedules widget refreshes, so displayed information may differ from the app’s live status. If they disagree, open Shadowrocket to check the connection toggle, selected server, and active Config, then compare with the system connection status. Do not repeatedly toggle the connection because the widget may be showing old information; that can make the state harder to track.
After adding or changing a Widget, test whether it opens the app, displays status, or performs an action, then use it accordingly. If an option is missing, first check system support on the device and the in-app documentation rather than looking for a similarly named configuration field. For system requirements, refer to the App Store listing. A widget can save a step, but it is not evidence that a particular domain is routed through a proxy.
Sync scope, conflicts, and recovery order
Use the values shown in the app for the default iCloud sync toggle and its scope. Before enabling sync, check your system account and the app’s iCloud permissions, and keep a copy of a working configuration. Sync is not the same as a full backup; do not assume it transfers every server, history item, system authorization, and connection state. Check the sync items actually offered in the app, and verify Config files, server lists, and related options separately.
When multiple devices edit the same content, it may be hard to tell which change came first. Make edits on one device, wait for the other to receive them, and then continue. If old content reappears, pause further edits, save anything you need from both devices, compare the actual differences, and decide which copy to keep. Do not immediately erase data on one device to “force sync”; the sync may propagate the deletion or overwrite.
| Action | What it does | Do not assume |
|---|---|---|
| iCloud sync | Transfers app data within its supported scope | System permissions and connection states all match |
| Subscription refresh | Fetches content from a subscription you already have | The same item is automatically enabled on another device |
| Manual Config import | Adds or updates a configuration file | The imported file is now the active Config |
Subscription updates are not app data sync
A subscription saved in Subscribe must be refreshed according to its update method. Seeing a subscription entry in iCloud does not prove that its URL is currently valid or that its content has refreshed. For the differences between manual updates, automatic updates on launch, and updating items individually, see How subscription updates work. During troubleshooting, update one item first and check what changed; avoid batch operations that could hide an issue with a specific item.
After an update succeeds, check whether the item count and selection match your expectations rather than relying on the completion message. The previously selected server may have been replaced by new content; similar names do not guarantee identical settings. If the list is empty or parsing fails, preserve any content that still works, then check the URL, source status, and returned content. See What to check when a subscription fails to parse or the list is empty. Do not repeatedly remove and re-add the same URL.
When restoring on a new device, first get the app and complete system authorization, then check synced data and the current selection, and finally test a real connection. Restoring an App Store purchase and syncing iCloud data are separate processes; a purchase record does not confirm that in-app settings have been restored. For purchase steps, see Restore a previous purchase. Set up automatic updates and On Demand after recovery to reduce confusion from multiple background actions happening at once.
Proxy ports and server settings: local versus remote
First identify where a Proxy port is configured. A port in Add Server belongs to an existing remote server and must match that service. If Settings offers a local proxy listener, that port is an entry point on the device. They serve different purposes and are not interchangeable, even if the numbers match. Before editing, note the setting’s location, address, and user. First ask, “Who connects to this port?” Then decide which value to change.
Local listener address, port, and exposure
Whether a local HTTP or SOCKS5 endpoint is available or enabled, and its default port, depends on what the app shows; do not assume a fixed number. If only programs on the device need access, limit the listener to the smallest necessary scope. Allowing LAN access changes who can reach it, so consider authentication, network trust, and the intended use. Do not enable an additional listener to troubleshoot an unrelated webpage; that adds another variable.
A port conflict and an incorrect port are different problems. If a listener will not start, check whether another feature is using the port and whether the option took effect. For a failed remote connection, check the server address, remote port, and network path. Changing the remote port to match a local listener will not fix server-side settings. The local address that can be reached may change when the network changes, so an address that worked on the previous network does not confirm that the endpoint is still available.
Protocol fields must match your existing server details
In Add Server, first confirm the protocol type, then check the fields it actually requires. Shadowsocks encryption method and password, VMess or VLESS identity and transport settings, and Trojan password and TLS fields all mean different things. Similar field names in the interface are not interchangeable. Enter each value using your existing server details; do not randomly change protocols or copy settings from another entry to try to connect.
The server address, the name used for TLS, and Host in some transport methods may be separate fields. The address determines where the initial connection goes; name-related fields are used in the relevant handshake or request and should match the existing server configuration. Do not routinely recommend disabling certificate verification when a certificate error occurs. First check that the name matches, the device time is correct, and the configuration source is complete; then check the server certificate. Do not use weaker checks to hide a field mismatch.
| Field location | What it means | Where to get the value |
|---|---|---|
| Local Proxy port | Proxy entry point on the device | Current app settings and local requirements |
| Add Server port | Remote service entry point | Your existing server details |
| TLS name fields | Details needed for the handshake and name matching | Actual settings for the corresponding server |
| Transport path and Host | Request parameters used by a particular transport | Existing parameters for that transport |
Troubleshoot based on transport capabilities
If TCP requests work but another type of request fails, check whether the protocol, server, and network support that transport. A webpage loading does not prove that all UDP or real-time traffic works. Protocols such as WireGuard and Hysteria2 also have specific address, authentication, and transport requirements; check the actual fields against your server details. This section explains how to check settings. It does not provide connection credentials or assume that a server supports a particular capability.
Importing a subscription can save manual entry, but you should still check that parsed fields match the original details. Before editing an entry generated by a subscription, check whether a later refresh will overwrite local changes. For testing, keep the original entry and clearly label a separate test copy so you do not mistake an overwritten change for an app that failed to save. For the step-by-step manual setup, see the Add Server tutorial; for importing an existing subscription, see the Subscribe tutorial.
A useful verification order is address and port, protocol and authentication, TLS and transport fields, then access to an actual destination. After checking each layer, reconnect and check whether the failure stage in Log has changed. A change from timeout to authentication failure means the observed stage has changed, but it does not mean the issue is fixed. Use an entry as the baseline for rule troubleshooting only when its settings match your existing details and a real request completes.
Config rules and a step-by-step troubleshooting process
Config groups rules and related settings. Importing a file, selecting it as the active file, and ensuring new connections use it are separate steps to verify. Before troubleshooting, check the active item in Config, then return to Home and confirm that Global Routing is set to Config. If the current mode is Proxy or Direct, the overall handling has changed, so you cannot use the policies expected from the rules to explain every result. Check the conditions consistently before examining individual rules.
Rules are evaluated from top to bottom; the first match wins
Rule order affects the result. A broad rule near the top can prevent a more specific rule below it from being matched. DOMAIN targets a specific domain; DOMAIN-SUFFIX matches a domain suffix and its scope; DOMAIN-KEYWORD matches a keyword in a domain. IP-CIDR and IP-CIDR6 describe address ranges, GEOIP uses address-location data, and FINAL handles connections that did not match earlier rules. Before choosing a rule type, decide whether you need to match a domain or an address.
| Keyword | Matches | What to check |
|---|---|---|
| DOMAIN | A specific domain | Whether the domain spelling matches the actual request |
| DOMAIN-SUFFIX | A domain suffix and its scope | Whether the scope is too broad and whether an earlier rule takes precedence |
| DOMAIN-KEYWORD | A keyword in the domain | Whether it unintentionally matches other destinations |
| IP-CIDR / IP-CIDR6 | A specific address range | Address type, network range, and DNS result |
| GEOIP | Address-location category | The data source and actual address |
| FINAL | Connections not matched by earlier rules | Whether it is at the end of the rules and uses the right policy |
Verify policies with a minimal snippet
The following is a rule syntax example, not a complete configuration for every environment. example.com is an example domain; PROXY, DIRECT, and REJECT are policy keywords, not server protocols. Before testing, copy your current working Config and make changes in a separate copy. Do not replace a configuration that contains other required content with this snippet, and do not treat GEOIP in the example as a required routing strategy.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXYRead each line in this order: match type, match value, then policy. DIRECT connects to the destination directly, PROXY sends it through the corresponding proxy route, and REJECT blocks matching connections. To test a policy for a domain, place a narrowly scoped test rule before any broad rule that could match first, then start a new connection and check the match result. Restore the original order afterward so a temporary rule does not continue to change other traffic.
GEOIP and address-range rules apply to destination addresses; domain rules depend on domain information in the request. Request types and the stage at which DNS resolution occurs can affect what information is available to match, so the same website may not produce identical records every time. If an address rule matches, interpret it alongside the DNS response. If a keyword rule matches too broadly, narrow it to DOMAIN or an appropriate suffix instead of adding more broad exceptions.
Turn setting changes into verifiable conclusions
Start troubleshooting with a clear description of the issue: identify the failed destination, current network, selected server, Global Routing mode, and active Config. Then determine whether the failure is at the DNS, connection, authentication, or rules stage, and change only the one setting best supported by evidence. Reconnect, make a new request, and see whether the result changes consistently. If not, restore the original value and check whether the setting took effect instead of layering on more unrelated changes.
After a successful test, check one destination that already worked and one local access scenario to make sure the fix has not widened the impact. Record the final settings and reasons in your own configuration notes, remove sensitive information from test copies, and restore any subscription updates or On Demand settings you still need. If the issue returns, compare the current setup with this baseline instead of starting over with every item in Settings. Record app updates separately from subscription updates.
Use this page to revisit common issues: check DNS for resolution problems, On Demand for automatic connection issues, Ping when test results differ from real access, Log for evidence of connection state, sync for inconsistent data, server settings for handshake failures, and rule order for policy mismatches. For purchase and restore questions, see pricing and one-time purchase details and restore a previous purchase. Do not use network configuration changes to troubleshoot an App Store purchase.