Global Routing
Config, Proxy, and Direct: Three Routing Modes
Go to Global Routing on Home. It determines how requests are handled; it is not the connection toggle and does not provide server details.
| Mode | How it works | When to use it | What to check |
|---|---|---|---|
Config · Config | Applies policies according to the rules in the active configuration file. | For routing traffic by domain, address, and other conditions in everyday use. | Check which configuration is active, the rule order, and the final policy. |
Proxy · Proxy | Routes traffic through a proxy; system-level bypass settings may still apply. | To briefly check whether the selected server can handle a particular request. | Check the selected server and its connection parameters. |
Direct · Direct | Handles traffic by connecting directly. | To check the local network or see whether the proxy route is involved. | Confirm the destination is directly reachable on the current network. |
How to Choose and Verify a Mode
Open Global Routing on Home, choose a mode, then return and check the connection toggle. For rule-based routing, choose Config and confirm the active configuration file on the Config page. Importing a file without activating it, or editing a different file, can make changes appear to have no effect.
To troubleshoot, temporarily compare Proxy and Direct for the same destination, noting the original mode first. If it works in Proxy but fails in Config, check the matching rule and policy. If it works in Direct but fails in Proxy, check the selected server, protocol parameters, and proxy route. These comparisons help narrow down the cause but do not prove that a specific setting is at fault.
Restore the intended mode after testing. Proxy is not a long-term fix for every rule issue. Likewise, seeing a connection status in Direct does not mean requests are passing through a proxy: connection status and routing decisions are separate.
[Rule]
Rule Types, Matching Order, and Policies
Rules define what to match; policies define how to handle it. Find the rule editor for the active configuration file on Config.
Identify the Match Condition
DOMAIN matches an exact domain; DOMAIN-SUFFIX matches a domain and its subdomains; DOMAIN-KEYWORD matches domains containing a specified keyword. Keyword matches are generally broader, so consider the risk of matching unrelated domains before adding one.
IP-CIDR and IP-CIDR6 describe IPv4 and IPv6 address ranges, respectively. GEOIP uses IP geolocation categories, so results depend on the relevant data. USER-AGENT relies on information available in the request and cannot identify every connection.
Check the Action Policy
DIRECT means connect directly, PROXY sends the request through a proxy route, and REJECT blocks matching requests. A policy name is not a server address. If you use a custom policy group, check which option is actually selected within it.
Rules are generally evaluated in order, so put specific conditions before broader rules that might override them. FINAL handles requests not matched by earlier rules and belongs at the end of the list; it does not replace the rules that classify traffic.
How to Edit a Rule
Back up the current configuration, then open the file in use on Config. When adding a rule, check its type, match value, and policy. Save it and confirm the file is still active. The snippets below illustrate syntax only; they are not complete configurations and do not indicate that the example domains have any working service.
[Rule]
DOMAIN,api.example.com,PROXY
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT
DOMAIN-SUFFIX,ads.example.net,REJECT
FINAL,PROXYIn this example, the exact-domain rule comes before the suffix rule, so api.example.com uses PROXY first. To verify the change, check the match record for a new request rather than relying only on whether the page loads. Caching, existing connections, and requests to other domains on the page can affect what you see. Avoid adding multiple broad rules to fix a single domain.
Continue to the guide to configuration file sections →SERVER
Subscription and Server Management
Use Home to view and select servers. Use Add Server to add a server or enter connection details. Server subscriptions and rules in Config are different types of content.
Import Existing Details
Get subscription details from your service provider. Before importing, identify whether you have an updateable server subscription URL, a single-server share link, or a configuration file URL. To add a server subscription, choose Subscribe in Add Server and enter the URL. If the app offers a clipboard or Scan QR Code option, verify that it recognizes the expected content type. A link opening in a browser does not necessarily mean the app can read it as subscription data.
To add a server manually, select its actual protocol in Add Server, then enter the server address, port, and authentication details. Shadowsocks, VMess, VLESS, Trojan, HTTP, SOCKS5, WireGuard, and Hysteria2 require different fields; do not reuse one protocol's parameters for another. Make sure additional settings such as transport, TLS, and hostname match the details you have.
Update, Select, and Back Up
After importing, return to Home and check that the expected items appear in the list. Select the server you want to use. Updating a subscription generally refreshes its server list; it does not change the current Global Routing mode or update the rules file in Config. If you edit an item in a subscription, a later update may overwrite some fields, so save any details you want to keep separately.
If a subscription update fails, check that the URL is complete, has no extra spaces, is still valid, and returns subscription data rather than a login page or error. Do not repeatedly delete the entire group without a backup. Subscription URLs and share links may contain credentials, so redact them from screenshots, logs, and support materials. This site does not provide, sell, or recommend servers or subscriptions.
On Demand
Connect Automatically When Conditions Are Met
On Demand lets the system initiate a connection when configured conditions are met. It does not choose which routing rule applies to a domain.
Where to Configure and Enable It
Look for On Demand options in Settings and configure the triggers for your available network conditions. First confirm that the server, DNS, and rules work when you connect manually; then enable automatic triggers. Otherwise, automatic reconnections may repeatedly reproduce the same issue and make troubleshooting harder.
After setup, test common network scenarios: joining and leaving a specified network, resuming after the screen locks, and switching between Wi-Fi and cellular. Check whether the connection behaves as expected, not just whether the toggle is on. System scheduling, network availability, and other VPN settings can affect behavior, so On Demand does not guarantee the same connection state in every situation.
When to Pause It
If the app reconnects automatically after you turn it off manually, check the On Demand conditions first, then review related VPN settings in the system. Before testing a direct connection or switching configurations, you can pause automatic triggers to keep them from changing the test conditions. Restore them when you are done and note which networks should connect. Routing rules are still determined by Global Routing and the active configuration.
Data
Traffic Statistics and Request Activity
Data shows traffic information recorded by the app. Use these statistics to understand connection activity, not as a substitute for subscription account or network provider billing records.
Check What the Statistics Cover
Open Data and review the scope, time period, and categories shown on the current screen. Different views may show totals, activity during a particular connection, or traffic handled through different routes. Make sure you are comparing the same metrics. Traffic attributed to a domain may come from page resources, background refreshes, or automatic app requests; the domain name alone does not identify what action caused it.
To check a new rule, note the current statistics, visit just one test destination, and review the resulting activity and matched policy in the connection records. If the page offers a reset option, save any data you need before resetting. Clearing statistics does not change the allowance on an existing subscription or fix connection problems.
Don't Draw Conclusions from Statistics Alone
An increase in total traffic only shows that data was transferred; it does not prove that every request followed the intended route. Encryption overhead, retransmissions, connection overhead, and differences in what is counted can make app-side figures differ from account records. To investigate unusual traffic, narrow down the cause using timestamps, request destinations, and background activity rather than assuming a particular setting is responsible.
Settings
DNS, Testing, Shortcuts, and Sync
Settings controls common app-level behavior, while the configuration file may also define related parameters. To check which settings take effect, review the active Config as well.
DNS: Distinguish a Resolution Failure from a Connection Failure
DNS translates domain names into addresses. Related settings may be in Settings or defined by parameters in the Config file's [General] section, such as dns-server. Before making changes, check how the active configuration specifies DNS. Changing one setting in one place does not necessarily update DNS for every request.
If Connectivity Test returns a result but a webpage won't load, check domain resolution, the actual request route, and TLS instead of just switching servers. Back up the configuration first, then adjust one DNS setting whose scope you understand and test the same domain again. Avoid changing DNS, routing mode, and server settings all at once; even if service resumes, you won't know which change helped.
Test Method: Keep Test Conditions Consistent
Check the Test Method used by Connectivity Test in Settings. Different methods test different layers: reachability at the transport layer does not mean a full webpage request will succeed. Test destination, current network, server load, and request method all affect results. Keep the method and destination consistent when comparing servers.
If the test requires a URL, use a destination you know is accessible and suitable for testing. If the test fails, confirm that the destination itself is reachable before checking the server configuration. A single test does not establish long-term reliability, and its result is not the same as real-world page loading speed.
Today Widget: Use It as a Shortcut
Today Widget provides a quick way to view or control supported features. Check for related options in Settings, then add it using the system's current widget controls. Available content and actions depend on the system and app; the widget is not a separate configuration.
After using a shortcut, return to Home to verify the connection status and selected server if either is unclear. Widgets may refresh after a delay, so check the in-app status and actual request results. Don't repeatedly toggle the connection based only on outdated widget information.
iCloud: Check What Syncs Before Restoring
Check iCloud sync or import options in Settings, and make sure the system allows the app to access iCloud. Sync coverage varies by data type; installing the app does not necessarily restore all servers, configurations, and preferences automatically.
Before changing devices, keep a configuration backup you control. After restoring on another device, check the server list, active Config, Global Routing, and On Demand conditions individually. App Store purchase history and app data in iCloud are separate: restoring the app does not restore connection details. Store backups containing authentication details only where you have control over access.
Diagnostics
Troubleshoot Step by Step—Change One Setting at a Time
Diagnostics and connection records can help identify a problem. Record a reproducible symptom first, run the relevant test, and then adjust settings based on the results.
How to Collect Useful Results
Look for Diagnostics in Settings and use the available tools to check network status, DNS resolution, or connectivity. Before testing, note the current network, selected server, Global Routing mode, active configuration, and specific destination that fails. Make one new request and review the results for that request so you don't mistake an earlier error for the current state.
- Check the local network.Confirm that the network itself works and that no sign-in page needs to be completed.
- Check server settings.Verify the address, port, protocol, authentication details, and additional transport settings.
- Check routing and DNS.Review the current mode, the rule matched for the destination, and DNS results. Diagnose resolution and connection issues separately.
- Change one setting and test again.Keep the destination and test method the same, and record the result. If it doesn't help, restore the original setting before trying the next one.
What Information to Protect
Diagnostic records may include domains, addresses, request times, subscription details, or authentication parameters. Before exporting or taking screenshots, redact sensitive information and keep only the error messages and setting names needed to identify the problem. Don't retain detailed logs unrelated to the issue for longer than necessary.
If the issue occurs only on a particular network, with a specific domain, or after a subscription update, preserve that condition in your notes. It's more useful than a vague report that you can't connect. For symptom-based troubleshooting, go to the troubleshooting page. To repeat the connection setup, return to Getting Started rather than clearing all settings.