Rule mode
Use the configuration rules to decide whether each type of request goes through a proxy, connects directly, or uses another strategy. Suitable for the first connection and everyday use.
10 MINUTE START
Work through four stages: import a subscription, choose a proxy mode, establish the connection, and verify the result. Each step builds on the previous state, making this guide suitable for users who have installed a client and are ready for their first configuration.
INPUT → RULE CORE → SYSTEM ROUTE → RESULT
PRE-FLIGHT CHECK
This guide assumes that the client is already installed and that you have a working subscription URL or local YAML configuration file. If you have not installed a client yet, open the client download page and choose the entry for your operating system. Windows, macOS, Android, iOS, and Linux clients may use different interface labels, but the configuration flow is broadly the same: the configuration feeds the core, rules determine where traffic goes, and the system proxy or TUN passes application requests to the core.
After opening the client, first check that the home page shows the core status, configuration entry, and proxy entry correctly. Some desktop clients request network, firewall, or administrator permissions on first launch; mobile clients typically show a system VPN permission prompt when connecting. These permissions create a local network interface or change the system proxy state. Grant the permissions required for your setup before continuing, and do not repeatedly toggle the connection while the permission prompt is still pending.
If you are migrating a configuration from an older client, avoid running multiple Clash clients during the first setup. Multiple programs may compete for the same listening port or repeatedly change the system proxy, leaving the interface connected while actual traffic is handled by another process. Exit other proxy tools and use only the current client for the steps below.
The home page shows entries for the core, configuration, and proxy.
The subscription URL is reachable, or the local configuration file can be read.
Prevent the system proxy from being overwritten and avoid local listening-port conflicts.
PROFILE INPUT
Open the client's configuration page. Desktop clients typically provide a Profiles or Configuration entry in the left navigation, while mobile clients may place it in the profile-name area on the home page. Find the option to import from a URL, add a subscription, or create a profile, then paste the complete subscription URL into the input field. Check the beginning and end of the URL for spaces, line breaks, or Chinese punctuation before clicking Import, Download, or Save.
After the client starts reading the subscription, a new entry should appear in the profile list. It usually shows a profile name, update time, or update button. An entry appearing in the list does not mean it is active; click the entry or use its switch button to set it as the current Profile. After the switch succeeds, the active profile name on the home page or status bar should update as well. All proxy modes and strategy groups in the next steps come from this active profile, so selecting it is essential.
If the source is a local YAML file, choose Import from File or drag the file into the configuration area. The file extension is usually .yaml or .yml. After importing, set it as the active profile in the list. If the client reports a parsing failure, do not proceed to the connection step; check the YAML indentation, spaces after colons, and list nesting around the reported location. If the core cannot load the configuration completely, the system proxy switch may still work, but usable rules and strategies will not be available.
After importing, stay on the configuration page and perform a quick status check. The active profile should have a clear selected indicator, and its details should show proxy strategy groups and rules rather than an empty entry. If the client offers a configuration check or reload button, run it once. Enter the proxy page only after the profile loads successfully; this separates configuration issues from connection issues and avoids troubleshooting several variables at once.
Automatic subscription update intervals are maintenance settings and do not affect this first connection. The immediate goal is simply to confirm that the configuration can be read and made active. After the connection succeeds, continue with the complete system guide for configuration structure, rule providers, subscription updates, and multi-profile management; this page keeps the initial workflow short.
A new entry appears in the profile list, the active profile name has changed, and the page shows no parsing error.
RULE SELECTION
Once the active profile has loaded, open the Proxy or Proxies page. Find the mode selector; the common options are Rule, Global, and Direct. For everyday use, start with Rule mode. In this mode, requests are matched against the configuration's rules from top to bottom and then sent to the relevant strategy group. Traffic that needs a proxy uses a proxy strategy, while other traffic can remain direct, according to the configuration.
Global mode sends most requests through one unified strategy. It is useful for temporarily checking whether a rule is keeping a site from using the proxy, but it should not be the default when you do not understand the configuration. Direct mode bypasses proxy strategies and is useful for pausing the proxy or comparing network states. Changing the mode changes how traffic decisions are made; it does not replace configuration import or fix an unavailable strategy automatically.
Use the configuration rules to decide whether each type of request goes through a proxy, connects directly, or uses another strategy. Suitable for the first connection and everyday use.
Send requests through a selected strategy to determine whether an access problem is related to rule matching.
Connect requests directly to their destinations to restore the normal network path or compare results before and after proxying.
After selecting Rule mode, do not return to the home page immediately. Continue to inspect the strategy groups on the proxy page. Names vary by configuration, such as Node Selection, Proxy, Auto Select, or Manual Select. Open the group that handles most proxy traffic and confirm that a usable strategy is selected. If the group has no selection or points to an inactive item, the rule may match correctly while the final connection still fails.
If the client provides latency testing, run one basic test to identify items that clearly cannot connect. A latency figure represents one request to the test target and does not equal the real experience across all websites, so there is no need to chase the lowest number at this stage. Choose a strategy that completes the test and remains stable, then fine-tune it after the basic connection works.
Some configurations contain strategy groups that reference one another. In that case, handle the top-level group referenced directly by the rules first, then confirm that its nested groups also have selections. DIRECT and REJECT are rule actions or built-in strategies, not ordinary proxy entries. For the first setup, simply make sure the main proxy group has a clear usable selection; there is no need to edit every group.
Rule mode is active, the main strategy group has a clear selection, and the basic test is not showing persistent connection failures.
SYSTEM ROUTE
Return to the client home page and confirm that the core is running. Some clients start the core automatically after installation, while others require a Start Service or Run button. When the core is running, the page usually shows Running, Started, or a similar status and displays a local listening port. Only a core that is listening normally can receive requests after browsers and other applications switch to the system proxy.
Next, enable the system proxy switch. On desktop systems, this directs HTTP or HTTPS requests to the client's local listening address. After enabling it, the client should indicate that the system proxy is set, and the operating system's proxy settings should show the local address as well. Do not enable multiple interception methods at once; keep the easily observable combination of “core running + system proxy enabled,” then proceed to verification.
Android and iOS clients usually capture traffic through the system VPN interface. The first time you connect, the system displays an authorization prompt; after approval, a VPN indicator appears in the status bar. This confirms that the system interface has been created, but access still depends on the configuration, strategy, and DNS, so the fourth step is still required. If authorization is canceled, the client may return to a disconnected state; click Connect again and handle the system prompt.
Some desktop applications do not read the system proxy or use an independent network stack. Their traffic may require TUN mode to enter Clash. Do not add TUN before the system proxy has been verified, because TUN also involves a virtual network adapter, administrator permissions, routing, and DNS interception. First confirm the basic path in a browser; only enable TUN according to the client's instructions after confirming that a specific application bypasses the system proxy, and disable duplicate interception methods.
After enabling TUN, complete any administrator-permission request or service-component installation prompt, then check whether TUN remains enabled. If the switch immediately falls back, the permissions, service component, or virtual adapter is usually not ready. TUN operation, strict routing, DNS hijacking, and platform differences are advanced topics; continue with the TUN chapter in the system guide.
After connecting, wait a few seconds and watch whether the core keeps running, the connection switch stays enabled, and the log avoids repeated port-conflict, permission, or configuration-load errors. If the switch turns off immediately, address the first clear error in the log; repeatedly clicking Start will not usually resolve a port conflict or permission problem.
If the status remains stable, do not change the mode, strategy, or DNS settings yet. Keep the current configuration unchanged while you verify the connection, so the result corresponds to a clear set of states. After verification succeeds, learn other features one at a time; if a problem appears, it will be easier to return to this basic combination.
The core keeps running, the system proxy or mobile VPN interface is enabled, and the page shows no recurring startup errors.
RESULT CHECK
Leave the client running in the background and open a new browser window. First visit an ordinary page that normally loads successfully to confirm that the proxy has not interrupted the network as a whole; then visit a destination that should use the proxy strategy. Use a new window or refresh the page where possible, so cached content does not make an old result look valid.
While the page loads, switch back to the client and inspect the connection log. Normally, you should see the domain request from the browser along with the matched rule, strategy group, and final strategy. A connection record is more reliable than the page result alone because it proves that the request entered the current client. If the page opens but the client shows no record at all, the browser may be using its own proxy settings, another network tool may be handling the request, or the request may not have used the current system proxy.
The connection log shows the domain you just visited, confirming that system traffic has reached the Clash core.
The record shows a rule type that matches the destination and sends the request to the expected strategy group.
The destination page finishes loading, and the client shows no persistent timeout, refusal, or DNS errors.
If the client shows no new connection record, first check whether the system proxy or VPN interface is still enabled, then confirm that the browser has not specified a separate proxy. If a record exists but shows DIRECT when the request should use a proxy, the issue is more likely related to rule matching or the current mode. Temporarily switch to Global mode for comparison: if Global works but Rule mode does not, inspect the rules or strategy groups; if both fail, continue checking the selected strategy and network connection.
If the record shows that a proxy strategy was selected but the result timed out, return to the proxy page, choose another strategy that passed the basic test, and try again. If you see a DNS resolution failure or an error saying that the host cannot be resolved, focus on DNS settings, the system network, and the DNS section of the configuration. Do not change rules, strategies, DNS, and TUN at the same time; adjust one variable, refresh the destination, and inspect the new log each time for a reproducible diagnosis.
After verification, switch back to Rule mode and keep the strategy that has been confirmed usable. The basic connection path is now established: the configuration provides rules and strategies, the mode controls decision-making, the system proxy or TUN captures traffic, and connection records show which path the request took. Use this same order whenever you update a subscription or change a strategy.
The configuration, mode, system interception, and request result have all been confirmed. You can now learn about custom rules, DNS, TUN, and multi-profile management as needed.
QUICK DIAGNOSIS
If the four steps do not produce the expected result, return to the beginning and verify each layer instead of reinstalling everything or changing many settings at once. The basic Clash path has five layers: configuration, strategy, core, system interception, and destination request. If an earlier layer is incomplete, a later switch may appear enabled without creating a usable connection.
Open the configuration page, check that the active indicator is on the newly imported entry, and confirm that there are no parsing errors. Downloading a subscription into the list without making it the active configuration is a common interruption during first-time setup.
Return to the proxy page and check Rule mode and the main strategy group. If strategy tests keep failing, switch to an item that can establish a connection before adjusting complex rules.
Check the running status and logs. If the port is already in use, close the program using the same port or change the listening port in the configuration and restart. Then confirm that the system proxy points to the new port.
On desktop, check the system proxy; on mobile, check VPN authorization and the status indicator. If a specific application does not read the system proxy, evaluate TUN separately rather than mixing browser testing with TUN troubleshooting.
Visit the destination again and check the domain, the matched rule, and the strategy used. An empty log, an unexpected rule, and a strategy timeout each point to a different troubleshooting path.
If you still need to address port conflicts, DNS, rule coverage, TUN routing, or migration from an older client after basic troubleshooting, continue with the complete Clash system guide. It organizes core concepts, client selection, installation, subscriptions, proxy modes, rule-based routing, TUN, and routine maintenance into separate chapters for reference after the basic connection is established.