Clash Setup Guide
Import a Subscription and Verify Your Connection

Before you start: prepare the client and configuration

After installing the client, launch it once to make sure the main window opens and the core isn't reporting persistent errors. This guide assumes you have a subscription link from a trusted provider or a YAML configuration compatible with your core. The client reads the configuration, applies rules, and establishes connections; installing it alone doesn't provide proxy service. If you only have the service's login page, get the configuration link from its subscription page first. Don't import the login page URL.

For your first setup, quit any other apps managing the system proxy or VPN, and leave the client's DNS, listening port, and network stack settings unchanged. This keeps troubleshooting focused on one configuration. Subscription links may contain credentials, so don't post them publicly or include the full address in screenshots. When reporting an issue, share the error type and steps to reproduce it. Remove sensitive parts of any links before sharing logs.

The steps below describe what each setting does; the exact labels may vary. When you see a similar option, first check whether it belongs to configuration management, proxy selection, or network settings. For unfamiliar terms, see the glossary. This guide covers only what's needed for a first connection, not every core setting.

Step 1: Import a subscription and activate the configuration

Open the Configuration page from the sidebar or bottom menu. Look for “New,” “Import,” or a field for entering a subscription URL. Copy the full link, paste it in, and check that it doesn't contain extra spaces, line breaks, or punctuation added by a messaging app. Then download or import it. If asked for a name, choose something easy to recognize; it's usually just a label in the client and doesn't affect rule matching. Wait for the new configuration to appear in the list.

Once the configuration appears, set it as the active one. Depending on the client, click its card, choose “Use,” or select “Enable” from its menu. Check the selected indicator: downloaded doesn't necessarily mean loaded. Then open the Proxy page. You should see the configuration's proxy groups and their available nodes. Group names vary by subscription, so don't look for an item specifically called Proxy.

For a local YAML file, choose “Import file” or open the file picker. Don't paste a file path into the subscription URL field or change the file extension to convert its format. Local configurations usually don't update when the subscription service changes; remote subscriptions can be updated from the configuration menu. For your first setup, try one manual update before enabling automatic updates. This makes it easier to tell an import issue from a scheduled-task issue.

If import fails with a format error, start with the client's message. The response may be a login page, an error page, or a list of nodes rather than a Clash-compatible YAML file. A link opening in a browser doesn't mean its contents are compatible. Ask the provider whether the link supports your client or the mihomo core. Don't submit a private subscription to an untrusted conversion site. If the download times out, first confirm your regular internet connection works, then check whether the provider offers an alternate link.

Done when: The configuration is selected, its proxy groups appear on the Proxy page, and the logs show no recurring configuration parsing errors. If errors persist, check the installation and setup section in the Help Center before enabling more network options. Mode selection only takes effect once the configuration has loaded successfully.

Step 2: Choose a rule mode and proxy route

Once the configuration has loaded, find the mode selector on the overview page, at the top of the Proxy page, or in the tray menu. Choose Rule for your first setup. This mode uses the configuration's rules to send connections DIRECT, through a proxy group, or to a reject policy. It doesn't send every request through a proxy, so some connections showing DIRECT may be expected. Keep the subscription's existing routing rules; don't delete direct rules or move fallback rules just to test the connection.

Open the Proxy page and expand the group that handles proxy traffic. For a manual group, select a node or a nested group. For an automatic group, the health check and selection algorithm determine the route. Some subscriptions route category-specific groups through a main selection group. Follow the selected option through each group until you can identify the final node or DIRECT route. Group names are set by the configuration author, so they don't reliably indicate the actual route.

If the client offers a connection test, run one for the current proxy group and choose a reachable option. Results depend on the test address, timeout, and network conditions at the time; they only describe that test, not access to every site or download speed. If one node times out, try another in the same group. If all nodes fail, check the subscription and network connection instead of repeatedly toggling the system proxy.

Global mode usually sends requests that reach the core through the global policy. It's useful for a brief comparison test, but it doesn't automatically capture traffic from every app. Direct mode sends requests that reach the core straight to their destination. For your first setup, stick with Rule mode. If you temporarily switch to Global for troubleshooting, check the selected option in the global group and switch back to Rule when you're done. Global mode and TUN mode address different layers and aren't interchangeable.

Done when: Rule mode is active, the relevant proxy group has a clear route, and it isn't unintentionally set to DIRECT. You can now send app traffic through the client. For rule order, protocol differences, and automatic group design, see the protocol and core reference. You don't need to change any of these for your first connection.

Step 3: Enable the system proxy and connect

Check the overview or core status first to make sure the core is running. If the interface reports a startup failure, open the logs and check the first related error before changing modes. Once the core is running, enable the system proxy in Settings or the tray menu. Some clients put this toggle on the overview page. For your first test, leave TUN off and make a request from a browser that follows the system proxy. This reduces variables related to permissions, virtual adapters, and routing.

On Windows, check the Proxy page in system settings after enabling the toggle to see whether a local proxy address appears. On macOS, check the proxy settings for your current network service. Use the values set by the client, and don't overwrite existing work or school network settings. If the client says the toggle is on but no browser connections appear, check whether a browser extension manages proxies separately and whether the app uses its own network settings. Linux app support varies, and a system proxy toggle may not affect command-line tools.

If you need to set a proxy manually in an app, first check the listening address and port in the client settings. The table below shows common examples, not default values for every client. If your interface shows different values, use those instead. A loopback listening address is intended for local access; you don't need to enable LAN access for a browser on the same device.

If the logs report that a listening port is already in use, check whether the client is running twice or another proxy app is still active in the background. Close the app using the port and restart the core. If you need to keep the other app running, change the listening port instead. The client may update its managed system proxy automatically, but browsers, terminals, and other apps with manually configured ports need to be updated too, or they'll keep using the old port.

On Android and iOS, the equivalent step is usually to tap Connect and allow the system to create a VPN configuration. The authorization prompt should come from the client you're using. On desktop, consider enabling TUN only if the browser works but a target app doesn't follow the system proxy. Read the client's service installation or permission prompts, grant the requested permissions, and retry. Don't start by layering another VPN on top. For TUN compatibility issues, see the Help Center.

Done when: The core is running and the system proxy is on, or the mobile app has the required system authorization. Next, make a new browser request. Don't rely on a page that was already loaded; existing long-lived connections may not switch routes when you change settings.

Step 4: Verify the rule and actual route

Open the client's Connections page, then visit a trusted HTTPS site in a new browser tab. Check whether the connection list shows the domain or destination; filter by domain if needed. A page loading only proves that the request got a response, not that it went through the proxy. Caching, direct rules, and existing browser connections can all affect the result. Connection logs are the first way to confirm that a request reached the core.

Open the new connection's details and check the destination, matched rule, and proxy chain in order. If the matched rule points to a proxy group, confirm that the last hop is the node you expect. If it shows DIRECT, first check whether that destination is supposed to be direct; don't assume the setup failed. Test another destination that should use a proxy under your subscription's rules, and compare the result with those rules. Some clients display proxy chains in layers, so expand the details to see the final route.

If the connection list shows no matching entry, first check that the request is still active and that the interface isn't showing active connections only; short-lived connections may disappear quickly. Then reload the page, clear connection filters, and check the system proxy toggle and browser extensions. For apps with their own proxy settings, verify the address, port, and protocol. Don't change DNS or replace the entire ruleset before confirming that traffic reaches the client; otherwise, it'll be hard to tell which change made a difference.

If a connection appears but the request fails, focus on the rule's route, node availability, and DNS results. Check the selected node, then review logs from the same time. A DNS resolution error and a connection timeout are different issues; troubleshoot them separately and keep the original error type. If you temporarily raise the log level, collect only the details needed to diagnose the problem, then restore the normal level to avoid retaining detailed logs of visited destinations.

An IP lookup can provide an additional check, but the lookup site is also subject to your rules. The same browser may use different routes for different destinations, so compare the result with that page's connection record. A site's apparent exit IP also can't confirm that DNS behaved as expected or that every app uses the same route. For deeper analysis of DNS resolution, TUN routing, and protocol compatibility, see the protocol reference. You don't need to solve every advanced scenario during your first connection.

Done when: The new request appears in the connection logs, the matched policy is what you expected, and the destination page responds. Your first-time setup is complete. After updating a subscription, check your selected options again if group or node names have changed. To stop using the client, turn off the system proxy or disconnect the VPN before quitting, so apps don't keep sending requests to a local port that's no longer active.

Everyday use: follow a repeatable troubleshooting order

You don't need to repeat every step for routine use. First confirm that the configuration is valid, then check the proxy group's route, and finally enable traffic capture. If something goes wrong, check in this order: configuration loaded, mode correct, request reached the client, route available. Change one setting at a time, then make a new request and check the logs. This makes it easier to identify the cause than changing the node, DNS, and TUN settings all at once.

Subscription updates may replace the rules and nodes in a remote configuration. For custom changes, prefer the client's override or merge features, then check the active configuration after an update. To learn more, use the glossary to understand proxy groups and rule types, the Help Center to troubleshoot specific errors, and the protocol and core reference to compare protocol compatibility and use cases. You don't need to change every advanced option to get started.