Complete the basic setup in this order: Import subscription → Choose proxy mode → Establish connection → Verify the result. This guide covers only the steps needed for first use; YAML fields, DNS details, and rule syntax are covered in the configuration documentation.
Menu names vary across clients such as Clash Plus, Clash Verge Rev, FlClash, and Clash Meta for Android. Common desktop entries include “Configuration,” “Proxies,” and “System Proxy,” while mobile apps may use “Subscriptions,” “Policies,” “Start,” or “Connect.” The names differ, but the order stays the same: make the configuration active, choose a policy, then enable the system proxy or VPN connection.
Installers for Windows, macOS, Android, iOS, and Linux are not interchangeable. On the download page, open the tab for your operating system and choose a graphical client. Most desktop and mobile use cases do not require a separate mihomo core download.
A subscription URL usually comes from your network service provider; the Clash client does not generate it automatically. Preserve the full protocol, path, and parameters when copying it, and avoid stopping halfway through the link. Treat the URL as a configuration credential—never publish it on a public page or include it in screenshots.
Temporarily disable old proxies, other VPNs, and similar clients, then open a website that normally works without a proxy. If the device is already offline, restore the local network first; otherwise, it will be difficult to tell whether the issue comes from the underlying connection or the proxy configuration.
The goal is not merely to save the link, but to let the client retrieve the configuration and make it the active runtime configuration.
After launching the client, look for “Configuration,” “Profiles,” “Subscription Management,” or “Configuration Files.” Desktop clients usually place it in the left navigation bar, while mobile clients typically put it near the top of the home screen or in a side menu. You may see remote subscriptions, local files, and new configuration options; for this setup, import from a link rather than creating a blank YAML file manually.
If the client asks you to choose a core or service mode on first launch, use the default recommended option to finish initialization. Windows clients may request administrator access to install a service or change system proxy settings; macOS may ask for your system password; Android and iOS usually request VPN permission when you connect. If a permission prompt is denied, there is no need to reinstall—grant access later in system settings.
Paste the URL into the subscription field. Check that it begins with a network protocol supported by the client and that there are no extra spaces or line breaks at either end. Then click “Import,” “Download,” “Update,” or “Save.” Some clients ask for a configuration name; use an identifying name such as the service or intended use, and never display the subscription URL as the name.
Normally, the client downloads the configuration and adds an item to the list. The entry may show an update time, traffic information, or an update button, but not every subscription provides every field, so a missing field does not by itself indicate failure. More reliable signs are that the configuration can be selected, the proxy page shows policy groups and nodes, and the client reports no YAML parsing error.
After importing, click the configuration or use its menu to choose “Select,” “Enable,” or “Set as active.” Some clients switch automatically after import, while others only add the configuration to the repository. If the proxy page is still blank, return to the configuration list and check the selected name before proceeding to connect.
If an import fails, shows an invalid response, or reports a configuration parse error, copy the address again and verify in a browser that it still returns content. Do not alter the service-generated YAML indentation. For persistent failures, check the installation and Troubleshooting entries in the Help Center; to understand the proxies, proxy-groups, and rules relationships, see the configuration field reference.
The mode determines how requests are matched against rules; the policy group determines which node or direct route handles the match. For your first connection, start with Rule mode.
Open the “Proxies,” “Proxies,” or “Policies” page and find the mode switch. Common choices are Rule, Global, and Direct. For first-time setup, choose Rule mode: the client checks rules from top to bottom and sends each connection to the specified policy group, DIRECT, or REJECT based on its domain, IP, process, or rule set. This is also how subscription configurations are generally designed to run.
Global mode sends most connections through one proxy policy. It can help you quickly check whether a node works, but it should not be the only result used to validate a first-time setup. Direct mode bypasses the proxy and is mainly useful for temporarily restoring local access or comparing results. For the full differences among the three modes, rule priority, and matching flow, see the terminology handbook and configuration field reference.
After selecting Rule mode, you will usually see several policy groups, such as “Node Select,” “Auto Select,” “Non-China Traffic,” “Streaming,” or names customized by the subscription provider. Find the group that handles the main proxy traffic, open it, and choose a specific node. If the group contains nodes, automatic test groups, and nested policies, select a single node for the first test to reduce uncertainty from automatic testing.
Node names may include region, protocol, multiplier, or route markers. A latency figure only reflects one probe response time and does not prove that a node can reach every destination. Choose a clearly named, testable node whose latency is not timing out. If the first node fails, keep the same mode and try another node to determine whether the problem is limited to that node.
Seeing DIRECT or REJECT on the policy page does not mean the configuration is broken. DIRECT sends requests matching the relevant rule through the local network; REJECT blocks them according to the rule. Do not change every policy group just to force all traffic through the proxy—local services, LAN addresses, and some system connections usually need direct access. For the first setup, change only the main node selection and leave other groups at their configured defaults.
If a policy group is completely empty or every group shows an unavailable status, go back and confirm that the correct configuration is active, then run a subscription update. If the client reports that a rule provider failed to download, nodes may still appear while traffic-splitting rules remain incomplete. Do not start a long-running connection until you have checked the network, rule URL, and configuration compatibility.
After the client loads the configuration, the operating system must send network requests to Clash. Desktop clients usually use the system proxy, while mobile clients typically create a local VPN tunnel.
In the home page, settings, or tray menu of a Windows, macOS, or Linux graphical client, find and enable “System Proxy.” Once enabled, the client points the operating system’s proxy address to a local listening port. Keep the client running while connected; before quitting, disable the system proxy so the system does not continue pointing to a stopped local port.
If the switch will not stay enabled on Windows, check that the client has permission to modify system settings and that no other proxy tool is controlling the system proxy. Some Microsoft Store apps use UWP network isolation, so an app may not access the local proxy even when the browser works. See the Help Center Troubleshooting guide for Clash UWP loopback handling.
When macOS changes network proxy settings for the first time, it may display a system authentication prompt; follow the instructions to confirm. Linux desktop environments do not implement system proxies consistently: GNOME, KDE, and other desktops may read different settings, and terminal programs may not adopt the desktop proxy automatically. For an initial setup, verify with a browser first. Command-line environment variables, transparent proxying, and service-based operation are advanced uses; consult the configuration field documentation and your client’s guide.
Android and iOS clients usually provide a prominent start button. After tapping it, the system displays a VPN configuration or connection request. Approve it; a VPN icon should appear in the status bar, and the client home screen should change from stopped to connected. The local tunnel sends device traffic into the proxy core, so you do not need to enter a Wi-Fi proxy address manually.
If the system authorization prompt does not appear, check whether another VPN connection is active. Mobile operating systems generally allow only one active VPN tunnel, so a new client may not start while the old connection remains. Stop the old VPN in system settings, then reconnect in Clash. Battery-saving policies may also restrict background activity after the screen turns off; if the connection drops when the screen locks, allow the client to run continuously in the system battery settings.
After enabling the switch, do not change other settings immediately. Observe the client status first. A normal state usually includes a home page showing started or connected, the correct active configuration name, and new connection records in the logs. If the switch immediately turns itself off, check the top error message or the last few log lines, especially for port conflicts, core startup failures, configuration parsing errors, and insufficient permissions.
A port conflict is often caused by another Clash instance still running in the background or by an old client process that did not exit cleanly. Fully quit other proxy clients, then restart the current client. Do not change multiple ports at once without understanding their purpose; address one cause at a time so you can tell which action restored the connection.
Verification should cover the basic network, destination access, and rule matching together. A lit connection switch alone does not prove that a specific request used the expected policy.
Keep the client running. First open a website that normally works over the local network and confirm that it loads. Then open a destination that requires proxy rules. The first check confirms that the direct route and basic DNS still work; the second confirms that the proxy node can establish a connection. When both succeed, the basic setup is essentially complete.
For testing, use a new private browser window or fully close and reopen the destination page to avoid misleading results from cached data. Do not generate a large number of connections with multiple browsers, download tools, and video apps. Keep the first verification to a few clear requests so the logs remain easy to read.
Return to the client’s “Connections,” “Connections,” or “Logs” page and find the record created when you visited the destination. Entries usually list the destination domain, matched rule, policy group, and final node. If the request was sent to the expected policy group and used the node you selected, the rule chain is working as configured.
If the destination opens but the record shows DIRECT, check whether the rule actually requires a direct route instead of assuming that the proxy failed. If the destination does not open and the record shows REJECT, the request matched a reject rule. If it used a proxy node but timed out, try another node in the same policy group and repeat the test. Rule, policy group, and node are three separate layers and should be checked separately.
If neither group of websites opens, disable the system proxy or disconnect the VPN and check whether local networking recovers. If it does, the issue is in the client, configuration, or node; if it does not, fix the device network first. Only when ordinary sites work but the destination fails should you check the current mode, policy group, node status, and log errors in that order. If changing nodes does not help, check whether the subscription expired, DNS is failing, or a rule provider could not load.
If a desktop browser works but a standalone app fails, the app likely ignores the system proxy or uses a different network stack. Check whether the app supports system proxy settings before changing the entire configuration to Global mode. If traffic interception is truly needed, evaluate TUN mode. On mobile, if only some apps fail, check whether they use Private DNS, cache old connections, or are restricted by system VPN settings.
An occasional single connection failure in the logs does not necessarily affect overall use. A webpage may request multiple domains, and ads, analytics, or unavailable resources may be rejected by rules. Focus on whether the main page loads, which rule handles the core domains, and whether the failure keeps recurring. See the Help Center for common error mappings, and use the configuration field reference for complete field definitions.