Before You Begin: Get a Client and an Existing Subscription
First, install a client that supports your operating system. If you haven’t installed one yet, visit the Clash downloads page to choose a platform and installer, then return here. The graphical client provides the interface; the core reads configurations, matches rules, and establishes connections. You don’t need to download a separate core or edit configuration files before getting started. Use the features already available in the client.
Get a valid Clash-compatible subscription URL or a configuration file from a trusted source. A subscription URL points to configuration data; it is not an account management page or a page describing an individual node. Installing a client alone does not provide a service to connect to, so this guide assumes you already have a subscription or configuration. If the source offers multiple formats, choose one explicitly marked for Clash or mihomo.
Keep your current working internet connection available, and check that your device’s date and time are correct. Close other proxy or VPN tools that are currently handling traffic, so you can tell which client is receiving it during your first connection. Subscription links may contain account credentials. Don’t post them publicly or show the full URL in screenshots. Once you’re ready, open the configuration page to import your subscription.
Step 1: Import a Subscription and Activate the Configuration
Add a Remote Subscription
Open the client’s “Configuration” or “Subscription” page and look for “Add,” “New,” or “Import from URL.” Choose the remote URL option and paste the full subscription URL into the address field. If there’s a name field, enter a label that’s easy to recognize, such as “Daily configuration.” The label only distinguishes the entry; it doesn’t affect how you connect. Make sure there are no extra spaces and that you haven’t copied any surrounding instructions, then save or import.
Some clients fetch the subscription as soon as you save it; others require you to click “Update” next to the entry. Wait for the result, then check the entry’s update time, configuration details, or node list. A successful import should show usable proxy entries; a complete configuration usually also includes proxy groups and routing rules. Seeing a subscription name doesn’t mean its contents have been downloaded successfully, so check that the configuration is usable.
Select the Active Configuration
Click the configuration you just imported and choose “Use,” “Activate,” or a similar option. Check that it’s marked as selected, then open the proxy page and make sure its proxy groups come from this configuration. Some clients can store several subscriptions at once, and the active configuration may not be the one you added most recently. If the old list still appears after an update succeeds, check which configuration is active before deleting or importing anything again.
For a local configuration file, choose “Import from file,” select the relevant YAML file, and activate it the same way. The difference is how updates are obtained: remote subscriptions can be fetched again, while local files usually need to be replaced manually. If the source provides only a node link and the import shows no rules or proxy groups, it may not be a complete configuration. Check whether your client supports that import format.
If Import Fails, Check the Error Type First
For a download error, check whether the URL has expired, whether you need to sign in to the source service again to get a fresh link, and whether your current network can reach the subscription host. For a parsing error, check whether you used a format for another client or downloaded a login page instead of a configuration. Don’t submit a private subscription to an unknown online converter. For protocol fields and format compatibility, see the core and configuration compatibility reference. This step is complete when the configuration is active and its contents appear on the proxy page.
Step 2: Choose Rule Mode and a Node
After activating the configuration, find the “Mode” setting and select “Rule” for your first setup. It uses the rules in the current configuration to decide whether each connection goes direct, through a proxy, or is blocked. Rule mode does not turn the connection on; you’ll still need to enable the system proxy or connect on mobile in the next step. Set the routing mode first to avoid changing several options at once and making it harder to identify what caused a problem.
| Mode | How It Works | Recommendation for First-Time Setup |
|---|---|---|
| Rule | Routes connections according to the configuration’s rules. | A good starting point for everyday use; check which rules match your traffic. |
| Global | Connections entering the core are generally handled by the global policy. | Use briefly for comparison and troubleshooting; make sure the global policy has a node selected. |
| Direct | Connections entering the core go direct. | Useful for comparing connection behavior, but not for testing a proxy node’s exit. |
Next, open the “Proxy” or “Proxy Group” page. Find the group that handles proxy traffic in your configuration. It may be called “Proxy,” but the name can vary. Open the group and select an available node. If the selected entry is another proxy group, check its next level until you can identify the node in use. Group names are labels chosen by the configuration author; a name alone doesn’t confirm that traffic goes through a proxy.
If the current selection is DIRECT, it usually means direct connection, without a remote proxy node. If the configuration includes an automatic selection or failover group, check which entry it has selected. For your first setup, you can temporarily choose a specific node to make the result easier to verify. The client’s test feature can indicate connectivity, but a successful test doesn’t guarantee that every website or app will work.
At this point, confirm two things: Rule mode is selected, and the intended node is selected in the target proxy group. Don’t change rules, DNS, and core settings all at once just to get everything configured immediately. Protocol choices and resource trade-offs are advanced topics; see the protocol reference later. They aren’t needed to establish a basic connection.
Step 3: Connect and Grant Required Permissions
On Desktop, Start with the System Proxy
Return to the client’s home or settings page, make sure the core is running, and then enable “System Proxy.” If the client has a single main connection button, click it and check the status message to see whether it also starts the core and sets the system proxy. The system proxy registers a local proxy address with the operating system. Apps such as browsers that honor this setting then send connections to the client, making it a good starting point for verification.
Start with the default listening port; there’s no need to change it to a specific number just because a guide uses one. If you see a port-in-use error, check whether another client or an old process is still running. Close the conflicting program and try again. If you need to change the port, save it in the client settings and re-enable the system proxy so the system setting matches the current listening port. Don’t change the address in system settings without also updating the client’s listening settings.
On Mobile, Approve the System Connection
Tap “Connect” or the main toggle on your phone. The first time you connect, the system will usually ask for permission to establish a VPN connection. Check that the request comes from the client you’re using, then approve it. The VPN label means the system is routing traffic through that client’s network extension or virtual interface; you don’t need to install a separate VPN app. Return to the client after granting permission and check that it shows as connected. Also check the system’s network status.
If a connection on Android stops soon after starting, keep the client in the foreground for an initial test, then check background activity and battery restrictions in system settings. On iOS, confirm that the system allows the corresponding VPN configuration to be added and enabled. Some systems can’t run two similar connections at once. Disconnect the current client before switching to another to avoid sending traffic through an old configuration.
Consider TUN Only If Apps Ignore the System Proxy
If your browser works but a game, command-line tool, or other app doesn’t send traffic through the client, check whether you need TUN. TUN uses a virtual network interface to handle traffic routed through it and usually requires service mode or administrator privileges. Follow the client’s instructions to install or enable the service, then turn on TUN. Don’t keep switching the system proxy, TUN, and DNS settings before you understand the cause of the problem.
TUN’s actual coverage also depends on routes, exclusions, and system restrictions, so verify the target app after enabling it. If you see a virtual adapter or routing error, turn off TUN and return to the system proxy setup that was working. Keep the exact error message for troubleshooting. At the end of this step, the client should show as running or connected. Next, use real requests to verify that the connection works instead of relying on the toggle’s color.
Step 4: Check Requests and Matched Rules
Open a familiar website you’re authorized to access and refresh the page, then open the client’s “Connections” or “Logs” page. Check the log right after refreshing so it’s easier to find the matching request. If the page is cached, reopening the tab may not create a new connection. Refresh the page or open another page on the site, then check whether the log has changed.
Find the target domain, then check the matched rule, proxy group, and final exit in that order. For example, if the configuration includes DOMAIN-SUFFIX,github.com,Proxy, connections to that domain and its subdomains that match the rule will be handled by the Proxy policy. Earlier rules may match first, so use the actual connection log to confirm. If the target goes direct, check the rules and group selection before assuming the node has failed.
Next, test another destination that should go direct and confirm that Rule mode handles different requests in different ways. Not every connection should use a proxy; a rule-based configuration may intentionally send some traffic direct. A page loading, a VPN icon appearing, or a successful node test alone doesn’t prove that a particular request followed the expected route. Connection logs are a more direct way to check.
If the target app doesn’t appear in the logs at all, check how its traffic enters the client: is the system proxy still enabled on desktop, does the app use its own proxy settings, or do you need TUN? If a request appears but the connection fails, try another node in the same proxy group and see whether the error changes. If only one website fails, test other destinations before concluding that the entire client is broken.
Finally, compare results with the connection off and on. Turn off the system proxy or disconnect on mobile, refresh the page, then reconnect and check the logs again. Don’t run other proxy tools during the test, or the comparison won’t be meaningful. Once requests appear in the current client, match the expected policy, and the page loads, the basic setup is complete. Keep these settings as a starting point for future changes.
Fake-IP: Keep the Default Configuration First
Fake-IP is a DNS mode. The core can return a synthetic address to an app, then use a mapping to recover the target domain when the connection is made, allowing traffic to be routed by rule. Seeing a synthetic address doesn’t necessarily mean DNS is broken, and you shouldn’t treat it as the website’s actual server address. If your first setup is working, keep the DNS settings provided by the subscription and client. There’s no need to change them just to enable a feature.
If a local network app, device discovery feature, or specific service stops working, note the current DNS mode and check whether the problem is actually related to name resolution before changing exclusions. After changing modes, existing connections and app caches may affect the result. Reload the configuration as instructed by the client, close the target app, and test again. Don’t change the DNS server, mode, and rules all at once, or you won’t know which change helped.
This guide covers only the concepts needed to connect. For more on how DNS relates to routing rules and protocol capabilities, see the protocol and core technical reference. If basic verification hasn’t passed yet, return to check connection logs and confirm whether traffic reaches the core.
Daily Use: Updates, Disconnecting, and Keeping Your Configuration
When you open the client, check the active configuration and connection status first. Manually refresh the subscription only when its contents have changed, a node has stopped working, or the source says an update is available. After updating, check that the expected entry is still selected in each proxy group; a node may have been renamed or removed. Remote updates can overwrite manual edits to imported content. For long-term customizations, use the client’s supported override method and save a recoverable copy first.
Before quitting the desktop client, turn off the system proxy and use the client’s normal exit option. On mobile, disconnect first. If you have network problems after an unexpected exit, check whether the system still has a proxy setting pointing to a local port, and make sure proxy settings needed for other work weren’t changed accidentally. Don’t force-quit the process as your usual way to disconnect.
When asking for help, include your operating system, client name, mode, whether the target request appears, and which step shows the error. Before sharing logs, hide subscription URLs, authentication details, and any unnecessary browsing history. Keep a copy of a configuration you’ve verified works. Change one setting at a time and test again so you can start troubleshooting from the most recent change.