QUICK SETUP / MIHOMO CORE
Clash Setup Guide
Import a Subscription and Test Your Connection
Follow four steps for your first setup: import a subscription → choose a proxy mode → connect → verify. With an active subscription ready, the main setup usually takes about 10 minutes, depending on download speed and network conditions.
This guide follows common workflows in the Clash Verge Rev desktop client. In other clients, look for features with the same or similar names. If you haven’t installed a client yet, choose your operating system and processor architecture on the client download page, then come back to continue.
Before You Start: Check Your Configuration Source and Network
With the client disconnected, open a website you can normally access directly to check that your device is online. Then check that your system date, time, and time zone are correct. An incorrect clock can interfere with HTTPS connections and subscription downloads. If your basic network connection is down, troubleshoot Wi-Fi, mobile data, or your gateway first; don’t change proxy rules yet.
The client reads configuration files, manages policies, and routes traffic. Installing it doesn’t provide usable nodes by itself. You’ll need a subscription URL from a service provider or a compatible configuration file containing nodes and rules. Prefer subscription formats explicitly marked as compatible with Clash or mihomo. A website plan page, account login page, or purchase history URL cannot be imported as a configuration.
Subscription URLs may contain account identifiers or access credentials. Copy the full URL, but don’t share it in public screenshots, chat logs, or support requests. When troubleshooting, you can describe the error and client without exposing the full URL. Temporarily disable other proxy tools and VPNs during setup to avoid conflicts over the system proxy, virtual network adapters, or local listening ports. Keep your current working internet connection available, then start by importing the configuration.
STEP 01 / PROFILE
Import a Subscription and Enable the Configuration
Open “Subscriptions” or “Profiles” in the client’s sidebar or bottom navigation, then look for “New,” “Add,” or “Import.” If you can choose between remote and local, select remote for a subscription URL. Paste the full URL into the URL field, give the configuration a recognizable name such as “Daily profile,” and select Save or Import. The name is only for your reference; the actual configuration comes from the file returned by the URL.
Wait for the download to finish. On success, you’ll usually see a profile card, an update timestamp, or an update button; some clients open the node list directly. Make sure the profile is marked “Enabled,” “Active,” or selected. Downloading a file without enabling it may leave the core using an older configuration. Select the profile’s enable option, wait for it to load, then open “Proxies” or “Policies.”
Make sure the Proxy page shows policy groups and nodes. Group names depend on the configuration author: they may not be “PROXY” or “Node Selection,” and could instead be named for browsing, streaming, or downloads. Check that the list contains nodes before choosing a mode. If it’s empty, check the configuration page for download or parsing errors instead of repeatedly tapping Connect. A login page returned in place of a subscription, an incompatible format, or an expired service can all prevent the configuration from loading.
To import a local config.yaml, choose the file import option on the configuration page, locate the file, then save and enable it. Don’t save an entire web page displayed in your browser as YAML; a valid file extension doesn’t guarantee valid content. After import, check the policy groups as usual. For your first setup, avoid changing rules or DNS. Getting the provider’s complete configuration working as-is makes it easier to identify the source of any problem.
Keep a Working Configuration When Updating a Subscription
A manual update helps you check whether the provider has changed the configuration. Select Update next to the profile and wait for the result; don’t refresh repeatedly. If an update fails, keep the current working configuration, check that the URL is valid and the network path is available, then try again. Set automatic updates as needed. Updating too often generates extra requests and won’t restore unavailable nodes.
Clients handle local edits and remote updates differently, and an update may overwrite manual changes. For your first setup, avoid adding complex override scripts. If you need persistent customizations, learn how your client handles overrides. For detailed steps to diagnose subscription download and configuration parsing errors, see Troubleshooting. After a successful import, leave the configuration enabled and move on to choosing a mode.
STEP 02 / ROUTING
Choose a Proxy Mode: Start with Rule, Then Select a Node
Open the Proxy page and find the mode selector for “Rule,” “Global,” or “Direct.” Start with Rule for everyday use: requests are checked against the configuration’s rules and sent to the specified policy or direct connection. This lets you use direct connections for some services and proxies for others on the same device. Rule mode depends on the configuration; it won’t automatically decide which route each website should use.
Global mode usually sends regular outbound requests through the global policy. It can help you briefly check whether a problem is related to routing rules, but it’s not a universal fix. Direct mode sends regular outbound requests straight to their destinations and can help restore basic connectivity or compare results. Existing connections may keep using their original route after you switch modes. Start a new request to test the change, and close old tabs or connections if needed.
Modes and TUN are two separate concepts. Rule, Global, and Direct determine how the core handles traffic after it reaches the core. The system proxy and TUN determine how traffic gets there. So selecting Rule doesn’t mean your browser is already using a proxy, and enabling TUN doesn’t mean every request must go through a node. Decide how traffic should be routed first, then configure how it enters the core to avoid changing too many things at once.
Choose a Node in the Policy Group Used by Your Rules
Expand the policy group that handles regular proxy traffic, select the latency test button, and wait for results. Choose a node with a successful test, then make sure its selection indicator changes. A latency test only checks connectivity to its test destination. A lower number doesn’t guarantee faster large downloads or that a destination website will accept that egress. For your first test, choose one node that can complete a request; there’s no need to cycle through every route.
Pay special attention to DIRECT and REJECT. The former means direct access; the latter blocks the connection. Neither is a remote proxy node. If a policy group that should use a proxy selects DIRECT, the client may show as connected even though traffic is going direct. Check which group the final matching rule references, then select a node in that group. Changing a node in a group that the rule doesn’t use won’t help.
If your configuration uses an automatic selection group, the interface may let you choose only the group, not a specific node within it. That’s how the policy group works; it doesn’t mean the interface is broken. Keep the provider’s automatic policy for now and use the connection log to see what it selects. For more on rule priority, policy chains, and DNS issues, see systematic troubleshooting. For your first setup, just make sure the current group has a working egress.
This is a setup checklist, not a client control. Once the mode and policy are confirmed, continue to connect.
STEP 03 / NETWORK ENTRY
Connect: Desktop and Mobile Steps
Desktop: Test the System Proxy First
Return to the client’s home or settings page and make sure the core is running. Some desktop clients start it automatically; others require you to select Start or Connect. The running status shows whether the local service is active, not whether a remote node is reachable. Once the core is running, enable “System Proxy” in settings and open a new page in your browser. This is the simplest route for your first connection test.
The system proxy mainly affects apps that read your operating system’s proxy settings. Browsers usually do, but a browser proxy extension, custom PAC settings, or enterprise policy may override them. Pause browser proxy extensions during your first test to avoid competing proxy settings. Terminals, games, and some download tools may not use the system proxy, so their lack of change doesn’t mean the client isn’t working.
Check the local HTTP or mixed port shown in the client and match it to the port configured in your app. Don’t copy a port number from an old tutorial: defaults and user settings vary between clients. The local entry point usually uses the loopback address 127.0.0.1. For a typical single-device setup, you don’t need to enable “Allow LAN” or expose the proxy listener to other devices on your network.
Mobile: Approve the VPN Connection
After enabling a configuration and selecting a node on mobile, return to the home screen and tap Connect. The first time, the system usually asks to add a VPN configuration or establish a VPN connection. Confirm that the request comes from your client, then allow it. This VPN interface routes device traffic through the client; it doesn’t provide a remote node. The egress route is still determined by the configuration and policy you imported.
After granting permission, wait for the status to show Connected, then switch to your browser and test a request. In most cases, only one regular VPN service can handle this kind of connection on a device. An existing VPN, another proxy client, or a filtering app that uses a local VPN may conflict. Disconnect those tools during testing rather than letting them compete. If the connection drops repeatedly, first check whether the system revoked permission or restricted background activity; don’t change your rules right away.
Enable TUN Only If You Need to Route More Traffic
If your browser works through the system proxy but other apps still bypass it, consider TUN. Open the client settings, install the service component or grant the required permissions as prompted, then enable TUN. It typically routes traffic through a virtual network interface, but the actual scope depends on route exclusions, app settings, and system restrictions. An “Enabled” status doesn’t prove that every protocol on the device is being routed successfully.
For your first TUN test, turn off the system proxy and use the same destination to compare results without stacking traffic routes. If you run into problems with a corporate VPN, virtual machine adapter, or local network access, disable TUN to restore the previous state, then follow the symptoms in the troubleshooting guide. Don’t disable your system firewall just to run the client. Install services and grant permissions only as explicitly requested by the client.
STEP 04 / CONNECTION CHECK
Verify It Works: Check Requests, Not Just Toggles
Keep the client connected, open its “Connections,” “Activity,” or “Logs” page, then start a new browser request. The connection list usually shows the destination domain and address, matched rule, policy, or traffic changes. Find your request and confirm it reached the core. Browser cache may show an old page, so try a new page or private window. Private browsing doesn’t change the proxy route by itself.
Next, distinguish between “reached the core” and “used a proxy node.” In Rule mode, direct requests may still appear in the connection list. Expand the record to check its rule and policy chain: DIRECT means a direct connection; if it matches a proxy group, check the final node too. Test two familiar destinations—one that should connect directly and one that should use a proxy—and compare their records. This tells you more than simply checking whether a page loads.
To check your egress, use a service that displays connection details. Keep in mind that egress information only shows the route for that request. In Rule mode, different websites may use different nodes or connect directly, so one site’s displayed address doesn’t represent every app. The reported location can also depend on how the service identifies your connection. Check the policy chain in the connection log first, then use egress details as supporting evidence.
Terminal Test: Specify the Client’s Actual Port
Whether terminal tools use the system proxy depends on the tool and environment. To test the local HTTP entry point by itself, specify the proxy explicitly with curl. The example below applies only if the client’s actual HTTP or mixed port is 7890. If the port shown in settings is different, replace the number in the command with the actual value. This command routes only this request through the local proxy; the rules still determine whether it uses a remote node.
curl --proxy http://127.0.0.1:7890 --connect-timeout 10 -I https://example.com
An HTTP response header means the request received a response. Check the connection log to confirm the destination and policy used. If the local address is unreachable, check that the core is running and the port matches. If the proxy entry accepts the connection but the destination times out, check the node and network. Don’t immediately save the proxy setting as a permanent environment variable. Test it once first, so your terminal doesn’t keep pointing to a local port after the client exits.
After Setup, Keep a Repeatable Check Sequence
Your first setup is complete when destinations that should use a proxy go through the expected node, destinations that should connect directly follow their rules, and web pages load normally. Note the active configuration, mode, policy group, and traffic entry method. If a problem comes up later, repeat the same checks, changing one thing at a time and starting a new request after each change. Don’t update the subscription, switch modes, change nodes, and modify DNS all at once; even if that restores the connection, you won’t know what fixed it.
When you’re done, turn off the system proxy before quitting the desktop client. If you used TUN, make sure traffic routing through the virtual interface has stopped. On mobile, tap Disconnect and confirm the system VPN has ended. Some clients restore settings automatically when they exit, but a forced quit or crash may prevent that. If your basic connection stops working after quitting, check whether the system proxy still points to a local port before reinstalling the software.
If you still can’t connect, read Clash Troubleshooting and look up symptoms such as no internet access, node timeouts, subscription errors, DNS issues, or the system proxy not working. To review a step, return to subscription import or connection setup; you don’t need to repeat the installation.