Before You Begin: Client and Working Configuration
This guide is for users who have installed a client and want to make their first connection. The main setup usually takes about 10 minutes, though subscription downloads, network conditions, and system permissions can add time. You’ll need a configuration for Clash or mihomo, either as a subscription URL or a YAML file from your provider. The client reads the configuration, routes traffic, and establishes connections; installing a client does not provide proxy nodes by itself.
Open the client and locate the configuration and settings pages. Make sure the app is working normally. Quit any other proxy clients or VPNs to prevent them from changing your network settings at the same time. Keep your current network connection active, and check that regular websites load before enabling the proxy. If your basic connection is already down, troubleshoot Wi-Fi, mobile data, or your router first; otherwise, it will be difficult to tell whether a later problem comes from the configuration.
A subscription URL may contain account details or access credentials, so treat it like a password. Don’t post the full URL in public forums or submit it to an untrusted online conversion tool. If you run into an error, note its type; before sharing a screenshot, hide the subscription URL, node credentials, and personal information. Once you’re ready, start by importing the configuration. There’s no need to change ports, DNS, or advanced network settings first.
Step 1: Import a Subscription and Enable the Configuration
On your configuration provider’s account page or in its setup instructions, find a subscription link specifically marked for Clash, Clash Meta, or mihomo. Copy the full subscription URL—not the account dashboard address, page title, or a node’s share text. Before pasting, make sure it contains no leading or trailing spaces, line breaks, or extra text. If the provider offers multiple formats, choose one supported by your client that’s compatible with Clash. Protocol support also depends on the core the client uses.
Return to the client and open the “Configuration” or “Subscription” page. Click Add, Import, or the plus button, then choose an option such as “Import from URL” and paste the link. Give it a recognizable name, such as “Daily setup.” If the client offers an update interval, keep the default for now. Confirm and wait for the client to download and parse the configuration. Avoid clicking Import repeatedly, which can create several similarly named entries.
After a successful import, the configuration list usually shows a new entry, sometimes with an updated time, active indicator, or action menu. Select the entry and choose “Use,” “Activate,” or “Switch to this configuration.” A successful download does not necessarily make it the active configuration, so check that the active indicator is on the new entry. Then open the proxy page. If you see proxy groups and nodes, the client has read the configuration and you can continue to Step 2.
If you have a local YAML file, choose “Import from file,” find it in the system file picker, and confirm. Then enable it using the same steps. Don’t paste text from an editor into the subscription URL field: the two options accept different types of input. A local file may not support remote updates. That depends on its provider settings and the client’s capabilities, not the file extension.
If an error appears, first identify where the process failed. “Request timed out” or “Download failed” usually means the client couldn’t retrieve the configuration. “Parse error” or “Unsupported field” means it downloaded the content, but there may be a format, syntax, or core compatibility issue. Check whether the subscription URL has expired and whether your account is active, then see if your provider offers a format for your client. Don’t change DNS for every error, or delete fields near an error without understanding the syntax.
You’re done with this step when the configuration is enabled and the proxy page shows the expected proxy groups—not just when a subscription appears in the list. Don’t connect yet. Next, choose how traffic should be routed and which group should handle proxied traffic.
Step 2: Choose a Rule Mode and Proxy Group
Find the mode setting on the client’s home, proxy, or settings page. Common options are “Rule,” “Global,” and “Direct.” Choose “Rule” mode for your first setup. It uses the configuration’s rules to decide how to handle each request: some go direct, some use a proxy group, and others are rejected. Rule mode doesn’t send every website through a proxy, nor does the client decide on its own which route each site should use.
Global mode typically sends requests that reach the core through the global policy, making it useful for quick comparison tests. Direct mode typically connects those requests straight to their destinations. The key phrase is “reach the core”: proxy mode determines what happens after a request reaches the core, while the system proxy or VPN determines whether an app’s requests reach it at all. Switching to Global won’t route traffic from an app that doesn’t use the system proxy.
After selecting rule mode, open the “Proxy” page and find the main proxy group used by your configuration. Group names vary; you might see “Proxy Selection,” “Node Selection,” or something else. Expand the group and check the current selection. For a manual group, choose a node your account can access. If the default is an automatic test or failover group, keep it for now and check that it contains available nodes.
Some proxy groups contain other groups instead of listing nodes directly. For example, the main group might select “Auto,” and that group then chooses an exit node. This is normal; there’s no need to edit the YAML to reduce the number of levels. Just make sure the main proxy group isn’t set to DIRECT or REJECT: DIRECT means connect without a proxy, and REJECT means block the connection. Neither is a regular proxy node.
If the client has a connection test, run it for a candidate node. The result shows how that node connects to a specific test address; it doesn’t directly measure download speed or guarantee access to every website. If a node times out, compare it with another available node in the same configuration. Don’t keep changing every setting to chase a particular number. The priority is to establish a reliable baseline connection.
Once you’ve confirmed the main proxy group, leave the other groups as configured for now. Whether video, download, or app-specific groups need separate selections depends on which groups your rules actually reference. Changing an unused group may have no effect. Rules are checked from top to bottom, and the first match usually determines the policy. See Rules and traffic routing for syntax details. For now, just confirm that rule mode is selected and the main proxy group has an available exit.
Your configuration and policy are ready, but app traffic may not be going through the client yet. In Step 3, enable the system proxy or mobile VPN to route app traffic through the rules you just selected.
Step 3: Connect and Grant System Permissions
Desktop: Start the Core, Then Enable the System Proxy
In the desktop client, check its status first. If there’s a “Start,” “Run,” or core toggle, make sure it’s on. Some clients start the core when the app launches, so you may not need to do anything else. Then find and enable “System Proxy.” Windows and macOS clients usually update the system proxy settings for you, directing browsers and apps that follow those settings to the client’s local proxy.
For your first setup, use the system proxy without enabling TUN. Once it’s on, close the page in your test browser and open a new tab to make a fresh request. If the browser has a proxy extension, make sure it isn’t locked to a different proxy; otherwise, it may override the system settings and make browser behavior inconsistent with the client. Browsers can use the system proxy, but some games, command-line tools, and standalone apps may not. That’s a difference in how they route traffic.
The client’s listening port must match the port used by the system proxy. Many configurations use a mixed port, but check the value shown in your client rather than copying a number from a guide. If the client sets the system proxy automatically, you usually don’t need to enter an address manually. If you do, the local address is usually 127.0.0.1; use the port shown in your current configuration. Don’t enter a remote proxy server’s address in the local system proxy field.
Linux desktop environments and clients may handle system proxy settings differently. First check whether your client offers a system proxy toggle, then confirm that your desktop environment accepted the setting. A command-line core alone won’t automatically route traffic from every app; you’ll need to configure each app or session to use it. Linux command-line deployment is outside this quick-start workflow. See Troubleshooting and Network Routing rather than applying desktop client steps directly to a server.
Mobile: Approve VPN Access, Then Connect
Android and iOS clients typically route traffic through the system VPN interface. When you tap “Connect” or “Start” on the home screen, the system may ask to establish a VPN connection, add a VPN configuration, or grant permissions. Confirm that the prompt comes from the client you just opened, then approve it as requested. Without permission, imported configurations and nodes can’t handle app requests through this connection method.
After granting permission, return to the client and check that its status shows Connected or Running. The system status bar may display a VPN icon, but some systems hide or collapse it, so check the client status too. If another VPN starts at the same time, the system may pause the current connection or switch to a different configuration. For testing, keep only one client actively connected to rule out conflicts.
After your first successful mobile connection, keep the client in the foreground while you complete the next step. Don’t adjust battery optimization or background restrictions yet. If the connection drops only when the screen locks or you switch apps, check the system’s background permissions. If a desktop app doesn’t follow the system proxy, you can look into TUN mode later. It affects routing, permissions, and DNS, so avoid changing it alongside other settings before your first verification. See the Help Center for details.
At the end of this step, you should know whether you’re using a desktop system proxy or a mobile VPN connection, and see that the client is running. A connected status only confirms that the entry point is active. You still need to test an actual request to verify the rules and node, so continue to Step 4.
Step 4: Check Requests and Verify Your Rules
First, open the client’s “Connections,” “Active Connections,” or “Logs” page. Then open a new browser tab and visit a site that should load directly, followed by one that your current configuration should route through a proxy group. Choose test sites based on your actual use case; don’t assume how a rule will behave based only on a site’s location. The route depends on both the configuration and the rules that match the request.
After sending a request, check whether the client shows a connection for the domain or destination. A webpage may request resources from several domains, so don’t mistake a resource request for the main page request. Find the record for the main domain, then check its matched rule, policy chain, or exit node. The fields shown vary by client. If process detection is enabled, you may also see the app name; missing process information doesn’t necessarily mean the proxy failed.
For a request that should use a proxy, check that its policy chain passes through the proxy group you selected in Step 2 and ends at an available node. For a request that should go direct, check that it shows DIRECT. A page loading is only the first check; the routing flow is working as expected when the connection record also matches the intended policy. If the page loads but the policy is wrong, check rule order and the active configuration before changing all your nodes.
If no new record appears on the connections page, first make sure you sent a fresh request rather than loading a cached page. Then check whether the system proxy or VPN is still on, whether another client is running, and whether the browser has its own proxy settings. Logs can offer extra clues, but low log verbosity may hide details. Don’t assume the core received no request just because you don’t see a log line.
If a connection record appears but the page fails, check where the request stopped. If it matched REJECT, first confirm whether the configuration is meant to block it. If it matched DIRECT, check whether the destination should go direct. If it reached a proxy group but timed out, switch nodes and retry the same URL. DNS errors, connection timeouts, and TLS errors are different symptoms; don’t treat them all as speed issues. Change one thing at a time and use the same test URL so you can compare results.
If only one website fails while others work, don’t reinstall the client right away. The destination service, node restrictions, rule groups, or browser state could all cause an isolated failure. If switching nodes fixes it, keep the working selection. If all nodes fail, continue with the Complete Troubleshooting Guide. For DNS or Fake-IP issues, check DNS and Network Stack Terms to understand your current configuration before making changes.
Once verification passes, decide whether to enable launch at startup, automatic connection on launch, or scheduled subscription updates. First check what each option does: start the app, run the core, or route system traffic. These aren’t necessarily the same action. Before quitting the desktop client, check whether it will turn off the system proxy. If the app closes while the system still points to a local proxy port, regular websites may stop loading. On mobile, confirm that the system VPN disconnects when you stop the connection.
For everyday use, follow the same short checklist: confirm the configuration works, check the mode and proxy group, check the connection toggle, then review actual connection records. To set up another device, choose its client from the Download Center and repeat these four steps. If menu labels or basic concepts are unclear, visit the Help Center. For persistent connection problems, use the Systematic Troubleshooting Guide. There’s no need to configure every advanced option during your first setup.