Check Global Routing first, then review Config and your server. The connection switch, rule matching, and On Demand triggers operate at different levels. Troubleshoot one at a time.
Home / Global Routing
Config, Proxy, and Direct define the overall routing mode. They are separate from the connection switch and from the policy names used in individual rules.
| Mode | How it works | When to use it | What to check first |
|---|---|---|---|
| Config · Rules | Uses the rules in the currently active configuration to choose a policy. | For everyday routing based on domains, IP ranges, and other conditions. | Is the expected file selected in Config? Are the rules and FINAL rule complete? |
| Proxy · Proxy | Routes traffic through the proxy path overall, subject to system and app handling limits. | Use briefly to test the proxy path and see whether rule matching may be the issue. | Can the selected server connect? Are authentication, DNS, and the destination working? |
| Direct · Direct | Uses a direct route overall, without forwarding traffic through a proxy server. | Test how the current network reaches the destination directly. | Can the local network, DNS, and destination be reached? |
In Home, find Global Routing and note the current mode before choosing one to test. Before using Config, open Config and confirm that the intended file is active—not merely downloaded and listed. Return to Home, select a server, and turn on the connection. Compare results using the same destination so the test remains consistent.
If Proxy works but Config does not, check which rule matched and the policy it selected. This is a troubleshooting clue, not proof that a rule is wrong. If Direct also fails, check the current network and destination first. Direct does not turn off the system VPN configuration. To stop the client from handling connections entirely, use the connection switch and check whether On Demand could reconnect it.
Some screens also show Scene, which is used for scene-related configuration and is not one of the three basic modes covered here. For initial troubleshooting, stick to one clear mode to avoid adding scene-switching conditions.
Config / [Rule]
A rule specifies what request to match; a policy specifies what to do when it matches. In Config mode, rules are checked from top to bottom, and evaluation stops at the first match. They are not automatically sorted by keyword length.
DOMAIN matches an exact domain; DOMAIN-SUFFIX matches a domain and its subdomains; DOMAIN-KEYWORD matches a keyword in the domain and usually has a broader scope. IP-CIDR and IP-CIDR6 specify IPv4 and IPv6 ranges. GEOIP matches using IP geolocation data; results depend on the database and resolution process and do not prove where a website is based.
USER-AGENT matches available User-Agent information. Don’t assume it covers every app request or identifies apps universally. FINAL is the fallback rule for requests not matched earlier. Put it too high, and later rules won’t get a chance to match.
[Rule]
DOMAIN,api.example.net,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,example,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXYexample.com and example.net are reserved for documentation. This illustrates rule order; it is not a complete file to replace your existing configuration with.
PROXY sends traffic through the proxy path, DIRECT connects directly, and REJECT blocks the matching request. Adding PROXY to a rule does not supply server settings automatically; make sure the required server or policy is valid. Use REJECT only for targets you know should be blocked. An overly broad rule may also break page authentication, images, or API requests.
Open the active file in Config and review its [Rule] section, checking the type, match value, policy, and order of each rule. Keep a copy before editing and change one condition at a time. Retry the destination and check the logs to confirm which rule matched. Don’t move a broad keyword rule to the top just to fix one domain.
See the Complete Rules and Configuration ReferenceHome / SERVER / Add Server
Server entries store connection parameters. Subscribe updates entries from a subscription you already have, while Config contains rules and other configuration. They work together but are not interchangeable.
From Home, open Add Server and choose Subscribe. Enter a subscription URL you already have, save it, and update it. Then check SERVER to confirm entries were created. Subscription URLs often contain access credentials; don’t include them in public screenshots, chats, or shared diagnostics.
If an update fails, check for spaces, line breaks, or expired parameters in the URL, then confirm the current network can reach it. An update only means the subscription content was fetched again; it does not mean every server in it is reachable. Subscription-managed entries may be rebuilt during later updates, so keep a separate record of important manual changes.
If you already have the details for a server, choose its protocol in Add Server and enter the address, port, authentication, and transport options as provided. Shadowsocks, VMess, VLESS, Trojan, Hysteria2, and WireGuard use different fields. Don’t just change the protocol name while keeping parameters from another entry.
Scan QR Code is an input method, not a check of the source or whether the server works. After scanning, verify the protocol, address, and key parameters; QR codes may contain sensitive information. Once saved, run Connectivity Test, then test access using that entry. Being added does not mean it connected successfully.
Use clear labels for entries, but don’t put passwords in their names. Keep subscription-generated entries distinct from manual ones, and check for configuration references before deleting anything. If the server test succeeds but the destination doesn’t work, check Global Routing, rules, DNS, and the destination service instead of repeatedly deleting and importing the same content. For the full first-connection walkthrough, see Getting Started.
Settings / On Demand
On Demand lets the system trigger VPN connections when specified conditions are met. It controls when a connection starts, not which route a domain takes. Conditions such as Wi-Fi and Cellular are separate from Global Routing and [Rule]. After enabling it, make sure the active configuration and server work as expected.
Find On Demand in Settings. Review the conditions and actions shown in the current interface, then configure it for a specific use case. If using Wi-Fi names, verify the exact network rather than relying on a similar name. Start with one easy-to-reproduce condition; add others only after confirming the behavior.
System scheduling, network changes, and app state can all affect when a trigger runs. On Demand is not an exact-to-the-second timer.
If the connection comes back after you disconnect manually, check On Demand conditions before deleting the system VPN configuration. To troubleshoot an ordinary connection issue, note the current settings and temporarily disable On Demand, then test a manual connection before turning it back on. When switching networks, watch for sign-in pages: complete the Wi-Fi network’s own login process first.
Data
Data shows traffic recorded by the client. Open Data and identify the scope, direction, or time range currently displayed; totals may be calculated differently across screens. Upload and download counts can help show whether traffic occurred, but a total alone cannot confirm that a page loaded fully or be treated as an ISP bill.
Before testing, note the displayed value, perform one specific action, and check the change afterward. Background sync, system requests, retries, and protocol overhead can all add traffic. If you play media while testing other sites, it becomes difficult to attribute the change. To establish a new baseline, record the old data first, then use the reset option available in the current interface. Resetting won’t restore local statistics that have been cleared.
Data does not show the remaining allowance on a subscription. Check the account information for any service you already use for its data limits, expiry, and billing terms. Client traffic totals do not guarantee the server-side balance. If usage rises unexpectedly, use request logs to identify the source and narrow down your tests rather than switching the global mode and leaving it there.
Settings
Available settings and options depend on the current system and app interface. Note the original value before changing it. If a configuration file controls the feature, check Config too; changing only the on-screen option may not be enough.
What it does: DNS resolves domain names to addresses, which can affect subsequent IP-based rules and routing. Successful resolution does not mean the server port is reachable, and a failed connection is not necessarily a DNS problem.
Where to find it and how to set it: Look for DNS options in Settings, and check whether the [General] section of the active Config includes resolution settings. Review the resolver and related options against your network requirements. Change one setting at a time, then test the same domain again.
What to watch for: Randomly changing DNS is not a universal fix. Internal network domains, sign-in pages, and IPv6 behavior may have specific requirements. Caching can also delay the effect of a change. Record resolution results before and after so you can compare them.
What it does: Test Method selects how Connectivity Test probes a connection. Different methods test different parts of the path, so results should not be compared without considering the method used.
Where to find it and how to set it: Find Test Method in Settings and review the available methods and test destinations. Note your selection, then return to Home and run Connectivity Test. When comparing servers, keep the method, destination, and network conditions as consistent as possible.
What to watch for: A successful probe does not mean every website is reachable, and a failed probe alone does not prove that authentication details are wrong. Don’t repeatedly change the method to chase a lower displayed value. Test the actual destination too, and use the error details to guide troubleshooting.
What it does: Today Widget provides quick access through a system widget, where supported by the current system. It is a shortcut, not a separate routing configuration.
Where to find it and how to set it: Check Today Widget options in Settings, then see whether it can be added from the system’s widget management screen. Set it up using the options supported by your system, try a quick action, and return to Home to verify the connection and selected server.
What to watch for: Widgets may not refresh immediately, so an old status doesn’t confirm the current connection. If the widget isn’t listed, check system support and the options actually available in the app; menus may differ on other devices.
What it does: iCloud features sync supported app data between eligible devices. Check the interface for the exact sync scope; don’t assume server credentials, configurations, or every Settings option will sync in full.
Where to find it and how to set it: Check system iCloud permissions and account status first, then review the app’s sync options in Settings. Keep the existing configuration before switching devices, and verify the actual content on the other device—not just that a filename appears.
What to watch for: Network access, available storage, and sync conflicts can affect results. Before deleting content, check whether it could affect other devices. Sync is not a substitute for a separate backup. Exported files or configurations may contain server credentials, so limit who can access them when saving or sharing.
Settings / Diagnostics
Diagnostics helps collect or review clues to distinguish issues with resolution, connectivity, authentication, and rule routing. Find the relevant option in Settings, read the available tool and output descriptions, then reproduce the issue once. Tools and details vary by platform and interface; a missing option does not mean the app cannot connect.
Start troubleshooting with one specific destination. Note whether you’re on Wi-Fi or Cellular, the Global Routing mode, selected server, active Config, and what failed. Check the basic network first, then server connectivity and authentication, followed by DNS and rule matches. Restore On Demand and other automation last. Change one variable per test and record the result so multiple changes don’t hide the cause.
For example, if a destination works in Proxy but fails in Config, keep the server unchanged and check whether a broader rule matched first and whether its policy is expected. If both modes fail, investigate server settings, the current network, and the destination instead of repeatedly moving FINAL. Rule, server, and system network issues require different evidence.
Before sharing diagnostics, check for subscription URLs, authentication fields, personal domains, device information, or browsing records, and redact them as needed. Share only the reproduction steps, relevant errors, and necessary rule snippets; don’t publish the full configuration to get troubleshooting advice. After resolving the issue, restore temporary test settings and verify the everyday Config and On Demand conditions.
Continue to the Configuration Structure and Rule Matching Reference