Proxy Modes and Essential Settings

Global Routing is on Home and determines the overall way connections are handled. Config uses the configuration, Proxy routes through a proxy, and Direct connects directly. Selecting a mode does not provide server details or turn on the connection. After choosing a mode, check the selected server and actual connection status on Home.

For everyday routing based on destination, select and enable the appropriate configuration in Config, then set Global Routing to Config. Traffic is then handled according to the configuration's rules rather than using the same policy for every destination. Importing a file without enabling it, or having a different file selected than expected, can produce results that do not match the rules you're reviewing.

Proxy is useful for brief troubleshooting. If the same destination works in Proxy but fails in Config, check the matching rule and policy next rather than immediately re-entering all server details. Direct can help determine whether the issue also occurs with a direct connection, but failure to reach a destination directly does not by itself prove that the proxy configuration is right or wrong.

After comparing modes, switch back to the one you need. Proxy and Direct in Global Routing are interface options; PROXY and DIRECT in rules are policy keywords. They operate at different levels and are not the same switch, despite the similar names.

Rules in Config specify which policy to use for which destinations. Open the current configuration's edit or rule view, confirm the file is enabled, then check the [Rule] section. Regular rules are matched from top to bottom: the first match determines how traffic is handled, and later rules are not considered as alternatives for that match.

DOMAIN matches an exact domain, DOMAIN-SUFFIX matches a domain and its subdomains, and DOMAIN-KEYWORD matches a keyword in the domain. IP-CIDR and IP-CIDR6 specify ranges of the two IP address types, while GEOIP relies on IP geolocation data. Domain and IP rules use different information, so rule order and DNS resolution results can both affect matching.

A policy specifies what happens when a rule matches: PROXY routes traffic through a proxy, DIRECT connects directly to the destination, and REJECT blocks the connection. If the configuration uses custom policy groups, check that the group exists and its selection is correct. A correctly written rule does not guarantee that its referenced group is available.

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

This is an example of how to read a text configuration, not a complete file to replace your current configuration. Put specific rules before broader ones in most cases. Place FINAL at the end to handle connections not matched by earlier rules. If a broad rule comes first, later, more specific rules may never be reached, even if they are correct.

Keep a recoverable copy before making changes. Change one rule at a time and test it with the same destination. If something goes wrong, note the domain, the active Global Routing mode, and the matching policy, then review the logs. A page loading or failing to load alone does not confirm which rule matched. For rule keyword definitions, see the glossary.

A server entry stores the protocol, address, port, and authentication details needed to connect. A subscription uses one URL to update a group of entries. Both are managed mainly from Home. If you already have a subscription, go to Add Server, select Subscribe under Type, enter the URL provided by your service provider in the relevant field, save, and update. If you have details for one server, choose its protocol and enter each field individually; don't import a server address as a subscription URL.

After saving, check that the expected group and entries appear in the list, then select the server you want to use. The protocol must match the server. Verify the port, password or identifier, TLS, and transport fields against the original details. Don't change Type to a familiar protocol and reuse parameters from a different one.

Subscribe updates entries maintained by their source; Config updates a configuration file. They are not interchangeable. After updating a subscription, check that the selected entry still exists, whether its name changed, and whether the current policy group still points to valid content. Manual edits to subscription-provided entries may be overwritten by a later update. Record any changes you need to keep and decide how to manage them separately.

When managing multiple subscriptions, use recognizable labels to distinguish their sources, then check for duplicate names and inactive entries after updating. Before deleting, confirm whether the action affects one server or the entire subscription group. Matching names do not guarantee matching settings, and a temporary test failure does not necessarily mean the source is inactive. Subscription URLs may contain access credentials; check for sensitive information before sharing screenshots, records, or backups.

Connectivity Test can help identify possible issues, but a passing test does not mean every destination is reachable. If a test fails, first check your current network and Test Method, then review the server details and subscription update results. For import steps, see the setup guide; for protocol field definitions, see the protocol manual.

On Demand triggers connection behavior based on configured network conditions. It's useful after you've verified a manual connection and want connections handled automatically on specific networks. Find the relevant options in Settings; the system VPN settings may also show the corresponding status. Available options depend on what the app currently displays. Before changing them, decide which network conditions should connect and which should not.

Leave On Demand off at first and complete a full manual test: select a server, set Global Routing, turn on the connection, and visit a destination. Once the basic connection works, open On Demand and review its conditions and actions. Set and save one easy-to-reproduce condition, then check the actual status when the condition is met, when it isn't, and when the network changes. This makes it easier to identify what triggered a connection than adding several overlapping conditions at once.

On Demand does not fix expired authentication details or replace Config rules. It determines when to start a connection; Global Routing determines how connections are handled. If a connection starts after you turn off the main switch, check for automatic triggers before repeatedly deleting server entries.

Data shows traffic recorded by the app. It can help you check whether data was transferred during a connection or whether a test caused a noticeable change. Open Data and review the displayed measurement scope and counters. If the interface offers different time periods or connection scopes, select one before comparing values; don't subtract figures from different scopes.

For a repeatable test, note the displayed values, keep the same server and mode, visit one known destination, then return to Data and check for changes. Pause other apps' background transfers where possible: system sync, media preloading, and other connections can affect the totals. Increased traffic only confirms that data was transferred. It does not prove that a page loaded fully or identify which rule matched.

The app's traffic counters and your provider's billing may differ in where and when traffic is measured and what overhead is included. Don't rely on Data alone to determine your remaining allowance. Allowance details shown in a subscription and traffic recorded on your device come from different sources and should be checked separately. Before clearing or resetting statistics, record any values you need and confirm what the reset affects. Restoring a configuration file does not guarantee that all historical statistics will be restored.

Settings controls app behavior, but not every connection parameter is managed there. Check server-specific details in the relevant entry; rules and some DNS behavior may come from the active Config. Before changing an option, confirm whether it applies globally, to the current configuration, or to one entry. If the configuration contains a related directive, consider its scope when determining the actual result.

DNS: Check Resolution, Then Forwarding

DNS resolves domain names to addresses used for connections. If an IP address works but a domain does not, or the same domain behaves differently on different networks, check DNS as part of troubleshooting. Review the DNS options in Settings along with DNS directives in the active Config. Record the original value, change one option at a time, and test the same domain again.

Changing DNS is not a universal fix. Successful resolution only means an address was returned; the connection can still fail during connection setup, TLS, or server authentication. Account for caching after a change and confirm that the test request uses the updated configuration. Prefer settings whose purpose you understand and that are compatible with your existing configuration. Avoid stacking parameters from sources you can't verify.

Test Method: Understanding What a Test Can Tell You

Test Method determines how server entries are tested. Look for the relevant option in Settings. Different methods check different parts of the connection path, so their results are not directly comparable. Choose a suitable method, keep the destination and network conditions consistent, then run Connectivity Test from Home.

A list test can help flag entries that clearly fail, but it cannot replace a real request to the service you want to use. If a test passes but the destination is unreachable, continue checking DNS, rules, and the destination service. If a test fails but an actual request works, first check whether the test method is appropriate rather than immediately deleting the entry.

Today Widget: Check Status After Using Shortcuts

Today Widget provides related shortcuts through a system widget. Available actions depend on the current system and what the app displays. Check the relevant options in Settings, then add an available widget from the system's widget editing screen. Before using it for the first time, return to Home and check the main switch, selected server, and mode. Trigger an action from the widget, then return to the app to verify the result.

Widget displays may take time to refresh, and shortcuts are not a substitute for full troubleshooting. If the result differs from what you expected, check the actual status in the app and see whether On Demand triggered another connection. A single widget display does not confirm server availability or which rule matched.

iCloud: Keep a Separate Backup Before Syncing

iCloud supports cloud sync and related save operations provided by the app. Before using it, check the account signed in on the device, system iCloud permissions, and relevant in-app options. Follow the current screen to see which data is synced. Check each type of data separately: seeing a Config does not mean subscriptions, selection state, and traffic history have all been restored.

Before switching devices, keep a separate, recoverable backup and avoid making major edits on both devices at once. On the new device, check the file contents and server entries, then verify the active Config and Global Routing. Syncing is convenient, but connection details still need to be checked. Treat files containing credentials as sensitive information.

Diagnostics: Gather Clues from One Failure

Diagnostics provides access to diagnostic and logging actions in the relevant section of Settings. Note when the issue occurred, the network type, selected server, and destination. Reproduce the failure once, then review the diagnostic information provided by the app. A single reproduction with clearly defined conditions is easier to investigate than changing several settings and exporting a large set of logs.

When reviewing logs, distinguish DNS resolution failures from connection, authentication, and handshake failures. Don't attribute every issue to rules. Before sharing logs, check for subscription URLs, server details, destination domains, and authentication data, and remove sensitive information. Logs reflect conditions at the time they were recorded; a new issue after switching networks needs a fresh record and test.