Step 1: Import a Subscription and Enable the Configuration
Before you begin, get a subscription URL compatible with Clash or mihomo, or a YAML configuration file. The client does not include proxy nodes; the provider determines which nodes are available, how long the subscription lasts, and any usage limits. An account page, website URL, and subscription URL are different things. Copy the link explicitly labeled for Clash or mihomo, not the login page URL from your browser's address bar.
Open the client and go to “Configuration” or “Subscriptions.” Look for “New,” “Add,” or “Import,” then choose the remote URL option. Paste the full subscription URL and give it a recognizable name, such as “Daily profile.” Check that the URL is complete at both ends, and remove any line breaks, quotation marks, or punctuation copied from a chat message. Subscription URLs often contain access credentials. Never post one in a public comment or include the full URL in a support screenshot.
Click “Download,” “Import,” or “Save” and wait for the client to fetch the profile. It should appear in the list, often with an update time or import status. Select it to make it active; some clients don't switch to an imported profile automatically. Then open the Proxy page and check that policy groups and outbound options are available. If you see a profile card but no selectable options, first make sure the profile is enabled—don't jump straight to TUN.
For a local file, choose “Import from file,” locate the YAML file, and confirm. The extension may be .yaml or .yml; what matters is that its contents match a format supported by the current core. Don't save a web page returned after a failed subscription download and use it as YAML. If import reports a parse error, check the line number in the message and confirm the source format. See the configuration reference for field details; you don't need to rewrite fields one by one to get started.
If a Subscription Won't Download, Check the Source First
If the download times out, first confirm that the device itself is online, then check the provider's site for an updated URL or an expired subscription. For access denied or an empty response, check your account and URL. For a YAML parse error, make sure you copied the right format. Repeatedly clicking Import won't fix an invalid URL. Some subscriptions require an existing network connection to download; follow the provider's instructions and don't paste a private subscription into an unfamiliar conversion site.
After importing, find the profile's “Update” option so you know where to refresh it manually. Updating a remote subscription may replace nodes or policy groups, and edits to the subscription content may be overwritten. Keep the original rules for your initial setup. If you later need ongoing customizations, read the configuration reference section on overrides and merges. Once the profile is active and its policy groups appear, move on to choosing a mode.
Step 2: Choose a Proxy Mode and Outbound
Return to the client home screen or Proxy page and find the “Rule / Global / Direct” mode selector. For your first setup, choose “Rule.” These modes determine how the core selects an outbound for each request; they don't automatically route every app through the client. You must also enable traffic capture via the system proxy or VPN in the next step. If you change the mode without enabling capture, your browser may keep using its existing network path.
Rule mode checks requests against the configuration's rules in order. The first matching rule determines the policy. A configuration might send some domains direct, route others through a proxy, or use an ad-blocking or other dedicated policy. The behavior depends on the active configuration; not all subscriptions use the same routing rules. A site using Direct isn't necessarily a sign of failure—check whether the matched rule is expected.
Global mode sends all requests that reach the core through the global policy, which is useful for a quick comparison but does not capture all traffic on the device. Direct mode connects requests that reach the core straight to their destinations without using a proxy node. Keep in mind that “Rule / Global / Direct” controls outbound selection, while “System Proxy / TUN / VPN” controls traffic capture. These settings solve different problems.
With Rule mode selected, open the policy group list and find the group used as the main proxy outbound by the active configuration. It may be named PROXY, Node Selection, or something else; check the configuration and connection logs to confirm. Select an available node and make sure the selection indicator changes. If you choose an “Auto Select” subgroup, open it and check that it has available candidates. Switching nodes in a group that no rule references may not affect actual requests.
Node Tests Are Only a First-Pass Check
You can use the client's built-in connection test to screen candidate nodes, but its result only reflects connectivity to a specific test address at that moment. A successful test doesn't guarantee access to every site, protocol, or app; likewise, an unreachable test address doesn't mean all requests will fail. Choose an available candidate and continue with verification, then adjust based on actual results. There's no need to test every option during initial setup.
At this point, two things should be clear: the active profile is selected, and the policy group used by the rules has an outbound selected. If the page shows an empty group, no nodes, or a configuration error, go back to Step 1 rather than using Global mode to mask the problem. For more on modes and policy groups, visit the Help Center. Next, route app requests through the client.
Step 3: Enable the System Proxy or VPN
First, check the core status on the client's home screen. Most GUI clients start the core with the app, but some have a separate “Start” or “Connect” button. If startup fails, check the logs for a port conflict, configuration parse error, or insufficient permissions. Fix the reported startup issue instead of repeatedly switching nodes. Once the core is running, enable traffic capture for your device.
For a first desktop test, enable “System Proxy.” This points the system proxy settings to the client's local listening address, allowing browsers and apps that follow those settings to send requests to the core. Leave the client running, open a new browser window, and visit a site. Some apps use their own proxy settings or ignore the system proxy entirely, so a working browser alongside an app that can't connect doesn't necessarily mean the subscription is at fault.
On mobile, tap “Connect” or the start button on the home screen. When the system first asks to configure or connect a VPN, confirm the request comes from the client you just installed, then approve it. Return to the app and check its connection status. A VPN icon in the status bar only confirms that the system tunnel is up; Step 4 will verify actual traffic routing. Don't connect while another VPN app is active—the system may switch tunnels and disconnect the client you just started.
Enable TUN Only If You Need It
If an app doesn't follow the system proxy, consider using TUN. TUN captures traffic matching the routing settings through a virtual network interface and may require a service installation, administrator permissions, or approval for a system network extension. Use the client's built-in option and follow the system prompts to install and grant access. If setup fails, check the specific error. Don't disable system security features or install purported repair drivers from unknown sources.
For initial troubleshooting, use one traffic capture method at a time: test the system proxy first, then decide whether to switch to or add TUN, following your client's guidance. Running multiple proxy tools can overwrite system settings, change routes, or compete for the same listening port. Close other tools and unnecessary browser proxy extensions to reduce variables. For details on virtual interfaces, DNS capture, and stack values, see the TUN configuration reference; advanced settings are outside this guide's scope.
At this point, the client should be running with the selected profile and mode unchanged, and the system proxy or VPN capture enabled. Hold off on startup settings, background keep-alive, and complex overrides until you've verified a complete request. When you're done, use the client's “Disconnect” or “Quit” option so it can restore the network settings it changed. If your network behaves unexpectedly after an abrupt shutdown, check whether the system still points to a proxy address on the stopped client.
Step 4: Verify Access and Rule Matching
Open a new browser window and visit a site you know you can access, while opening the client's “Connections” or “Logs” page. Check whether the request appears, then inspect the destination domain, matched rule, and outbound route. Clients show slightly different fields, but the key questions are the same: did the request reach the core, and which policy handled it?
A page loading successfully doesn't by itself prove the proxy is working: the site may be reachable directly, or the browser may be showing cached content. In the active configuration, test one destination expected to connect directly and another expected to use the proxy. Make a fresh request and check the logs. If the request matches DIRECT, confirm that's what the rules intend. If it matches a proxy policy, check the final selected node rather than relying on the mode shown on the home screen.
For an extra check, compare the results from a trusted public IP lookup service before and after switching, but don't rely on it alone. Rule mode may send the lookup service direct, and browser caches, app-specific proxy settings, or existing connections can affect what you see. Connection logs and actual access results together are more reliable than a single IP address. After switching nodes, start a new request; existing long-lived connections may not immediately use the new outbound.
If Verification Fails, Narrow It Down Layer by Layer
If the target request doesn't appear in the logs at all, check traffic capture first: is the system proxy still enabled, is the mobile VPN connected, and does the browser have its own proxy settings? If the request appears but uses the wrong policy, return to Step 2 and check the matched rule and associated policy group. If the policy is right but the connection times out, try another candidate node and check the subscription status. Don't change the mode, DNS, and TUN all at once or you'll lose a useful point of comparison.
If the logs show a DNS resolution failure, investigate the DNS layer next. First confirm the device's basic network connection, keep the client's default settings, and note the domain and time of the error. Under Fake-IP, seeing a reserved address mapping isn't necessarily a problem; don't disable the mode just because the address looks unfamiliar. See the DNS configuration reference for field details and limitations. For port conflicts, permission errors, or apps that can't connect, use the Help Center to narrow down the issue.
Once pages load as expected and the rules and outbounds in the logs match your expectations, the initial setup is complete. Note the active profile name, traffic capture method, and main policy group. When making changes later, adjust one thing at a time. Repeat the same checks after updating the subscription, especially if node or policy group names have changed. For support, provide the client name, OS version, error message, and steps already tried. Before sharing a screenshot, hide subscription URLs, account details, and private browsing history.