First-time setup comes down to four tasks: import a readable configuration, choose a proxy mode, enable system traffic interception, and verify rule matching with a real request. Follow the main flow first; investigate protocol and core differences only when needed.
Client names and button locations vary, but the workflow is the same: the configuration enters the core, the core starts listening, and the system proxy, VPN, or network extension sends app traffic to it.
After importing the configuration, confirm that the core is running before enabling the system proxy. Some apps use their own proxy settings, and some store apps may also be affected by system network permissions, so check both client logs and browser requests during verification. When switching clients, disable the system proxy in the old client before exiting it.
Different clients may use the system proxy, enhanced mode, or a network extension. On first activation, macOS may ask you to approve a network configuration or enter device credentials. After granting permission, return to the client and check its status. If only the core is running and system traffic interception is off, browser traffic usually will not enter Clash automatically.
After selecting a configuration and node, tap Start. Android will display a VPN connection permission dialog. After approval, a VPN indicator should appear in the status bar. If another VPN, network filter, or local firewall app is running, identify which app owns the VPN channel first to avoid an immediate disconnect.
The first connection triggers a system permission request. After approval, iOS saves the VPN configuration in Settings. Later, you can usually start and stop it from the client. During verification, do not rely only on the status-bar icon; return to the client, check the selected policy, and use a real webpage request to confirm the corresponding connection log entry.
A graphical client can help configure the desktop environment’s proxy, but the entry point differs across distributions and desktop environments. Starting the mihomo core alone does not necessarily intercept every app; also confirm that environment variables, desktop proxy settings, or a transparent proxy setup match your usage. For a first setup, use a graphical client to verify browser traffic first.
The key point: a successful import does not mean the configuration is already running. This step is complete when the client shows the new configuration, parses it successfully, and marks it as the active configuration.
Open the installed Clash client and look for “Subscription,” “Configuration,” “Profiles,” or “Configuration Files.” Most graphical clients provide a URL field and an “Import,” “Download,” or “Update” button. Paste the complete subscription URL from your service provider into the field and start the import. Subscription URLs usually contain access credentials, so store them only on trusted devices and in the client you use; never copy them into public pages, screenshots, or public issue reports.
If you received a local YAML configuration file, choose “Import from file” or drag the file into the client’s designated area. The key difference is how updates work: a remote subscription can usually be refreshed from its original URL, while a local file must be imported again after its contents change. During first-time setup, do not add multiple similar sources at once, or it will be difficult to tell which one is active.
After clicking Import, wait for the client to return a result. Normally, a new item appears in the configuration list with a name or update time. Open it and confirm that it contains at least one proxy node or policy group. If the client immediately reports a YAML format error, unsupported field, empty subscription, or download failure, stop here: a configuration that was not parsed successfully cannot be fixed by switching modes.
A configuration may appear in the list without being selected. Click the configuration entry, enable its toggle, or choose “Set as active configuration” so the client clearly marks it as current. Some clients reload the core during a switch, so a brief stop-and-start sequence is normal. If the status remains on an error or loading screen, open the logs and inspect the earliest parsing message instead of repeatedly clicking Start.
At this point, the client should have one clearly marked active configuration. The configuration page should open, and the policy groups should show selectable items. Do not rush to test a webpage yet: the next step determines how requests are matched against rules. The configuration is usable data; the proxy mode determines how that data participates in each connection.
For first-time use, choose Rule mode. It evaluates requests against the rules listed in the configuration, supporting both proxy and direct connections. Global mode is useful for short comparison tests, while Direct mode pauses proxying or checks the local network.
Open the “Mode,” “Mode” page, or the running-mode section on the home screen. You will usually see Rule, Global, and Direct. In Rule mode, domains, network addresses, or processes are matched to a policy group according to the configuration; after a match, later rules are not evaluated. This is the usual starting point because the configuration maintainer has already defined how different traffic should be handled.
Global mode usually sends most requests to one unified policy, making it useful for checking whether a site connects when complex rules are bypassed. It is not always the best everyday default: local-network devices, local services, and traffic that needs no proxy may also be sent through the proxy. Direct mode bypasses proxy nodes, helping confirm whether the original network works and serving as a temporary recovery option before closing the client.
Matches requests against the configuration rules in order and works well as the everyday default. If one domain takes an unexpected route, check the matched rule and policy group instead of immediately changing every node.
Sends most requests through the same policy to temporarily eliminate rule interference. Switch back to Rule mode after testing so local-network devices and services do not keep using a changed route.
Uses no proxy node and is useful for comparing the local network state. If the destination also fails in Direct mode, the issue likely should not be investigated only as a node or proxy-protocol problem.
Once the mode is set, open “Proxies,” “Proxy,” or “Policy Groups.” This is not merely a list of nodes; it is a set of policies with selection logic. Common types include manual selection, latency testing, failover, and load balancing. For first-time setup, start with the main policy group named something like “Node Selection” or “Proxy Selection,” or the group specified by the configuration notes, and choose an available node.
The latency shown by a client reflects only one type of probe and does not represent the experience of every website or app. Once a node is selectable, keep it selected and continue; there is no need to test every item. If the policy group is completely empty, return to step one and confirm that the subscription parsed successfully. If only some protocol nodes are missing, the cause may be a core support difference. Consult Protocol and core technical reference instead of rewriting the configuration blindly during basic setup.
Before connecting, note the current mode and main policy-group selection. If verification later fails, keep the node unchanged and switch from Rule mode to Global mode for one comparison, or keep Rule mode and change only the node. Change one variable at a time so you can tell whether the issue comes from the rules, node, or system interception. If you switch modes, change nodes, and refresh the subscription together, you will not know which action restored the connection.
This stage requires checking two layers: whether the Clash core is running and whether the operating system is sending the target app’s traffic to it. If only one layer is working, webpages may still follow their original route.
Return to the client home screen or general settings and click “Start,” “Run,” or the main toggle. After a normal launch, the status should change from stopped to running, and the logs should no longer show recurring configuration parsing errors. Desktop clients may also display HTTP, SOCKS, or mixed ports, which are local proxy listening endpoints. With a graphical client, leave the defaults unchanged at first to reduce configuration variables.
If the client stops immediately after starting, inspect the earliest error in the logs. A port conflict often means another proxy client is still running in the background. If configuration loading fails, return to the subscription page and select a configuration that can be parsed. Do not try to fix a core startup failure by repeatedly toggling the system proxy: the system proxy only sends traffic to a listening port and cannot repair the core itself.
On Windows, macOS, and common Linux desktop clients, continue by enabling “System Proxy.” This changes the operating system’s proxy settings so apps that follow them connect to Clash’s local listening port. Keep the client running after enabling it and proceed directly to verification. If the client offers enhanced mode, TUN, or service mode, you do not need to enable all of them for first-time setup. Start with the system proxy and a browser test to reduce permission, routing, and DNS variables.
Android and iOS usually do not show a “System Proxy” switch. Instead, tapping Connect requests permission to create a VPN configuration. Approve it, check for a VPN indicator in the system status area, and return to the client to confirm that the connection is still running. Mobile operating systems usually allow only one app to occupy the VPN channel, so another VPN, filter, or security app may reject or replace the new connection.
After connecting, do not update the subscription, switch configurations, or change DNS yet. Keep the active configuration, Rule mode, and node selection unchanged, and open the client’s connection or log page to prepare for observing requests. You should be able to answer four questions: which configuration is active, which mode is selected, which policy is selected, and whether system interception is enabled. If any answer is unclear, confirm it in the relevant page before testing a webpage.
Do not judge the result only by a toggle color, tray icon, or VPN indicator. Reliable verification requires a successful app request, a corresponding client connection record, and confirmation that the request matched the expected rule or policy.
Keep the client’s connection or log page visible, then open a previously unvisited webpage in your browser or use a private window. This reduces the chance that the browser will return cached content. Once the page starts loading, return to the client and check whether the domain appears in the connection list. If it does, browser traffic has entered Clash; next check whether the record used Direct or a proxy policy.
If the page opens but the client shows no new record, the browser may not be using the system proxy, or it may have completed the request through a cache, independent proxy, or another network path. Test a new domain first, then check for an independent browser proxy setting. If no app requests enter the client, return to step three and confirm that the system proxy or VPN is still enabled.
In Rule mode, a connection record usually shows the matched rule, policy group, or final route. If the target request shows DIRECT, the rules sent it directly; if it shows a policy group or node, the request followed that proxy path. The goal is not for every request to use a proxy, but for the result to match the configuration’s expectations. LAN addresses, local services, and some common network requests may legitimately be handled by direct rules.
If a target fails in Rule mode, keep the node unchanged and temporarily switch to Global mode before opening the page again. If Global mode succeeds but Rule mode fails, focus on rule order, GeoIP, GeoSite, or policy-group selection. If both modes fail, consider the node, protocol support, or local network. Switch back to Rule mode after the comparison so a temporary test state does not become the long-term configuration.
After the first successful verification, close and reopen the client normally, then check the active configuration, proxy mode, and system proxy status. Clients differ in whether they restore the system proxy at startup: some do so automatically, while others require it to be enabled again. Make another webpage request and inspect the connection record to confirm that the configuration works beyond the current session.
Before exiting a desktop client, also check whether the system proxy has been restored. If the client exits unexpectedly while the system still points to a stopped local port, browsers may fail to load every webpage. Reopen the client and disable the system proxy, or restore automatic configuration in the operating system’s network settings. On mobile, the VPN indicator should disappear after disconnecting; if it does not, open the system VPN settings and check which configuration is active.
When all six points are clear, the first-time setup workflow is complete. Use the same order later when optimizing rules or switching clients to identify what changed.