Before You Start: Client and Subscription
Start by choosing a client from the Download Center that matches your device's operating system and processor architecture. Install it and make sure the main window opens normally. The app, its core, and its subscription are separate: the client provides the interface, the core handles connections, and the subscription supplies nodes and may include policy groups and rules. Installing the client doesn't provide a working route by itself; you'll also need a valid subscription or an existing configuration file.
Confirm with your subscription provider that the link supports Clash or mihomo, and keep their setup instructions handy. An account page URL or purchase-history link is not a subscription URL. A generic link containing only nodes may not load as a complete configuration. If the provider offers multiple formats, choose one explicitly marked for your client. If you're unsure, read the glossary entry on subscriptions and configurations rather than repeatedly trying conversion services from unknown sources.
Before you begin, temporarily quit other proxy or VPN clients, check that your device has the correct time and time zone, and make sure your regular network can reach everyday websites. Subscription links may contain account identifiers, so treat them as private. Hide the full link and any authentication parameters in screenshots, shared logs, or support requests. In the four steps below, change one key setting at a time. That makes it easier to pinpoint the stage where a problem occurs instead of toggling multiple options at random.
1. Import a Subscription and Enable the Configuration
Open the “Configuration” or “Subscription” page in the client's sidebar. Look for an option such as “Add,” “New Configuration,” or “Import,” then choose the option to import a remote configuration by URL. Paste the full subscription URL into the address field. If there's a name field, enter a local label that will help you identify it. Check the beginning and end of the URL and remove any line breaks, explanatory text, quotation marks, or trailing punctuation copied from a message. Then click “Import,” “Download,” or “Save.”
The client will fetch and parse the remote content. If it succeeds, a new entry usually appears in the configuration list with a name or update time. Some clients also display plan details returned by the provider, but this information isn't always available. A saved entry isn't necessarily enabled. Select it and choose the corresponding option to enable or activate it. Then open the Proxy page and check that policy groups or nodes are available.
If you already have a local .yaml or .yml file, choose “Import from file” and select it in your system's file picker. The file extension can help identify the format, but it doesn't guarantee that the contents meet the requirements of your current core. A local import is usually a static copy and won't automatically receive remote subscription updates; remote configurations can typically be refreshed with an update button. Use either method for your first verification—you don't need to import the same configuration more than once.
If the import fails, first identify which stage produced the error. A download timeout means the client couldn't retrieve the content; check your network, the link, and the subscription service. A parsing error means the content was retrieved but couldn't be read as an expected configuration. Common causes include using a webpage URL, choosing an incompatible format, or using fields unsupported by the current core. Reopen your account page and copy the correct link; this is usually more useful than changing ports or DNS. Don't delete configuration sections you don't recognize just to bypass an error.
This step is complete when the subscription entry is enabled and policy groups appear on the Proxy page. If the list is empty, return to the configuration page, confirm the correct entry is selected, and check for parsing errors. Some configurations load nodes through remote proxy providers, so those resources must also download successfully. There's no need to enable TUN yet. Once the configuration has loaded, move on to choosing how traffic will be routed.
2. Choose Rule Mode
After enabling the configuration, find “Proxy Mode” on the Overview, Proxy, or Settings page. Common options are “Rule,” “Global,” and “Direct.” For your first setup, choose “Rule” so the core routes connections according to the rules in your configuration. If the interface is in English, the options are usually labeled Rule, Global, and Direct. Check which option is selected to make sure you haven't chosen a different mode by mistake.
Rule mode doesn't send every request through the same node. A configuration may route some domains through a proxy group, send others directly, and use a fallback rule for everything else. So if a site shows your usual local exit, the connection may be working as intended—it may have matched a Direct rule. For now, use the rules included with your subscription. You can check the actual match in the connection panel later; don't assume the entire client has failed based on one site's behavior.
| Mode | When to Use It for Your First Setup |
|---|---|
| Rule | Routes traffic according to the configuration; the recommended starting point for your first connection and everyday use. |
| Global | Sends connections entering the core through the global policy. Use it for a temporary comparison test, and check which policy is selected. |
| Direct | Handles connections entering the core as direct connections. Use it to compare your baseline network performance. |
Keep “proxy mode” and “traffic routing method” separate. The mode determines how connections entering the core are handled; the system proxy or TUN determines how app traffic gets to the core. Switching to Global won't automatically route traffic from every app on your device. Apps that ignore the system proxy may not pass through the client at all. In the next step, set up a clear routing path before you verify the connection.
When troubleshooting a single site, you can briefly use Global for comparison. First make sure its selected policy group points to a proxy node, not DIRECT. After testing, switch back to Rule and reload the test page. Existing connections may continue using their old route, so they don't reflect the new setting. You don't need to change rule syntax, Fake-IP, or DNS yet. To learn how they work, read the protocol and core technical reference.
3. Choose a Node and Enable Traffic Routing
Return to the Proxy page and expand the policy group responsible for the traffic you want to route. Group names are set by the configuration provider and may describe a purpose, region, or service; the group may not be called “Proxy.” In a group that allows manual selection, choose an available node and confirm the selection indicator moves to it. If groups are nested, check the selection at the next level too. Otherwise, you may change a group that your current rules don't actually use.
Use the “Test,” “Speed Test,” or latency test button next to the group or node, then wait for the test to finish. A result means the request to that specific test target completed at that time; if it times out, try another node or check your subscription. Latency isn't download speed and doesn't prove that every website is reachable. For your first connection, choose a node that tests reliably instead of repeatedly switching to chase a lower number.
On desktop, enable “System Proxy” on the Overview or Settings page. Some clients have separate controls for starting the core and enabling the system proxy. If there's a separate start button, make sure the core is running before you enable the proxy. The first time, your operating system may ask for permission; follow its prompts. Then make a new connection in a browser that respects the system proxy. Browser proxy extensions or custom proxy settings can override system settings, so disable them for this test.
On Android or iOS, you usually need to tap Connect on the home screen and allow the system prompt to add or establish a VPN configuration. This is the mobile operating system's built-in way for the client to route traffic; it doesn't require a separate VPN subscription. After allowing it, return to the client and confirm the connection status. Check that the system also shows the connection indicator. If Android is set up for per-app proxying, make sure your test browser is included. Options may have different names in different clients.
For your first test, don't enable the system proxy, TUN, and another VPN at the same time. On desktop, start with a regular browser and the system proxy. Consider TUN only if an app doesn't respect the system proxy. TUN typically requires additional permissions and a virtual network adapter, and may also take over DNS; enabling it won't automatically fix every network problem. A mobile system VPN connection isn't the same as a TUN switch in a desktop client. Follow the connection flow for your platform.
If only a few nodes time out, try another node. If they all time out, check that your subscription is valid, your device clock is correct, and the logs don't show authentication or connection errors. If the core won't start, check for port conflicts and configuration parsing errors. Don't change several ports before you've identified the source of the problem. Once a node is selected, the core is running, and traffic routing is enabled, move on to verifying an actual request.
4. Verify the Connection and Exit IP
Close any old test tabs, open a new one, and visit the site you want to check. A page loading is only the first clue; you also need to determine which route it took. Open the client's Connections page and watch for a new connection while the page loads. Find it by domain or app. If the panel shows the matched rule, target policy, and proxy chain, check each field to confirm whether the request went through your chosen node or DIRECT.
In Rule mode, make sure your test target matches what the rules are expected to do. If the connection panel shows that the domain matched a Direct rule, seeing your usual exit is expected. Test a site that should use a proxy, or temporarily switch to Global and select a specific proxy node for comparison. Restore Rule mode when you're done. Don't delete all the Direct rules in your configuration just to make one lookup page show a different address.
Cross-check with a trusted exit IP lookup. You can record a baseline with traffic routing off, then enable it, make a new request, and compare the displayed exit address and network provider. If the lookup site is configured to go Direct, its result won't show the proxy exit. IP geolocation databases can also be inaccurate, so check the connection panel instead of relying only on the city displayed on the page.
The same browser may use IPv4 and IPv6 separately, or keep an existing connection open; one lookup can't cover every route. If results don't match, close the relevant tabs, make a new request, and check the destination address and final policy for that connection. Don't compare results from different address families, websites, or apps as if they were equivalent. For a more complete walkthrough, read the guide to first connections and exit IP checks.
If a webpage loads but the connection panel never shows a related entry, first check whether the browser bypasses the system proxy, whether another proxy extension is active, and whether you're looking at the client that's actually running. The panel may also have filters enabled; clear them and check again. If a connection appears with the expected proxy chain but the page still fails, inspect the nearby logs to distinguish DNS resolution problems, connection timeouts, and certificate errors. Don't assume every issue is caused by a “bad node.”
The setup is verified when the current configuration is enabled, the proxy group has selected a working node, a new request from the test app appears in the client, and the request follows the expected rule to its exit. A latency test result, a VPN icon, or an enabled toggle confirms only one part of the process—not the entire route. Once all four checks pass, you can keep Rule mode for everyday use.
After Setup: Everyday Use
When you open the client, confirm that you're still using the configuration and mode you verified, then connect as needed. If your subscription provider replaces nodes, update the configuration and check that your policy group selection is still in place. If you enable automatic updates, follow the provider's recommended schedule. More frequent updates don't make nodes more stable, and there's no need to keep clicking if an update fails.
Before quitting the desktop client, use its normal exit option and confirm that the system proxy is turned off. If the process ends unexpectedly and browsers can no longer connect, check whether the system proxy still points to a local service that has stopped. On mobile, disconnect in the client and confirm the system VPN has ended. If you enabled on-demand connections, check whether they reconnect automatically.
For help adjusting rules, choosing protocols, or understanding core compatibility, see the technical reference. Look up terms such as policy group, DNS, and Fake-IP in the glossary. Keep a record of the configuration and settings that passed this verification; if something goes wrong later, you can compare against a known-good baseline instead of changing everything from scratch.