Clash Setup Guide

Before You Start: Get the Client and Configuration

Install a client that supports your operating system and processor architecture. If you haven’t installed one yet, visit the Clash downloads page and choose the right platform. If you already have multiple clients installed, run only one during setup to avoid conflicts over system proxy settings, local ports, or virtual network interfaces. You can leave the old client installed for now; wait until the new one is working before cleaning up.

The client reads the configuration, applies routing rules, and handles traffic. Installing it doesn’t mean you have usable nodes. Before continuing, get a valid subscription link from a trusted configuration provider, or a configuration file containing nodes and rules. Subscription URLs may include account identifiers, so paste them only into the client on your device. Don’t share the full link, its QR code, or logs containing credentials when asking for help.

This guide focuses on importing a subscription link; leave the client’s default ports and DNS settings as they are. Get a basic connection working first, then adjust advanced options one at a time to make problems easier to diagnose. If you’re unsure how subscriptions, nodes, and policy groups differ, see the subscription and configuration sections in the glossary, then return to step one.

Step 1: Import a Subscription and Activate the Configuration

Open the client’s “Profiles” or “Subscriptions” page and look for an option such as “New,” “Add,” or “Import from URL.” Choose the remote URL option, paste the full subscription address, enter a name you’ll recognize, then save or import it. Don’t use a sign-in, order, or help page URL as the subscription address. Your provider should clearly identify the correct link as a subscription URL or client import link.

Wait for the download and parsing to finish. On success, the configuration list should show the name you entered, along with an update time, update option, or active status. Select the configuration to make it active. Some clients activate it automatically after import; others require you to click “Use” or select its card. Seeing a filename in the list alone doesn’t confirm that the core is using it.

Next, open the “Proxies” page. If you can see policy groups and available nodes within them, the configuration has loaded proxy entries. If the page is still empty, return to the configuration page and check which profile is selected and whether there are any error messages. If the download failed, check that the link is complete, your subscription is active, and your network can reach the subscription server. Avoid repeated update attempts, which can make temporary request limits look like a client issue.

If the client reports a YAML parsing error or an unsupported field, first check that your provider supplied a Clash- or mihomo-compatible configuration, not a format made for another client. A single share link is not necessarily a complete subscription that every client can import. For format compatibility, see the protocol and core reference. For now, use a configuration explicitly marked as compatible.

If you have a local configuration file, choose “Import from file,” select the YAML file, then activate it as above. Unlike a remote subscription, a local file usually won’t fetch updates automatically. After the first successful import, set a reasonable update interval if your provider recommends one. A subscription URL isn’t a node address that needs frequent replacement. Once the policy groups appear, continue to the next step.

Step 2: Choose Rule Mode and a Proxy Node

Find “Outbound Mode” or “Proxy Mode” in the client and choose “Rule” for your first setup. In Rule mode, the active configuration determines whether each connection goes direct, through a proxy, or is blocked. It doesn’t send all traffic through a single node. A typical configuration routes local networks and some sites directly, while sending other traffic to a designated policy group. The actual behavior depends on the rules in your configuration.

Then open the “Proxies” page and find the main policy group referenced by your rules. Its name depends on the configuration; it may include “PROXY” or “Proxy Select,” or use a custom name from your provider. Expand the group and select an available node. If the group uses an Auto Select or Failover subgroup, that subgroup chooses the actual node according to its own settings. For easier troubleshooting, start with a group that lets you select a node manually.

If the client offers a connectivity test, run it once to check whether the selected node responds. A successful test doesn’t guarantee that every site or protocol will work, and a timeout may be caused by the test address or your current network. Choose a node that appears healthy and continue; verify it with real traffic rather than switching repeatedly based only on test results.

Global mode usually sends connections handled by the core to the global policy. Use it briefly to compare results and see whether rules are affecting access. Direct mode doesn’t use proxy nodes. Global mode doesn’t replace the system proxy or VPN connection, and it won’t capture apps whose traffic never reaches the core. If you switch to Global for a test, check that the right global policy group is selected, then switch back to Rule mode. For more on rule matching and policy groups, see the glossary.

Step 3: Enable the System Proxy or Connect via VPN

Your configuration and node are ready, but apps still need to route traffic through the client. On Windows, macOS, and desktop Linux, enable “System Proxy” from the client’s overview or settings page, or its tray menu. The client points the system proxy to a local listening port. Browsers and apps that follow system proxy settings will then send requests to the core. Keep the client running after you enable it; don’t close it before testing.

For your first setup, keep the default port. You don’t need to enter it in your router or enable “Allow LAN.” That option lets other devices use the proxy on your computer; it isn’t required for your own connection. If the client reports a listener failure or port conflict, quit other proxy clients and restart this one. If you do change the port, make sure the proxy address used by your apps matches the new listening port.

Android and iOS usually route traffic through the system VPN interface. Return to the client’s home screen, tap Start or Connect, and approve the VPN permission prompt the first time you connect. Check that the client shows an active connection and that the system VPN status is on. Other VPN apps may replace or conflict with this connection, so close them while testing. The VPN indicator confirms that the system interface is active; access to a specific site still depends on your configuration, node, and rules.

If your desktop browser works but an app ignores the system proxy, consider enabling “TUN” or the client’s equivalent enhanced mode. It routes traffic through a virtual network interface and may require a background service, network extension permission, or elevated privileges. Follow the prompts in your client. Don’t change several options such as stack, routes, and DNS at the same time. Start with the defaults and check whether the affected app can connect.

System proxy and TUN handle traffic routing at different levels; you don’t usually need both. If enabling TUN disrupts local network access, turn it off and return to the system proxy setup you’ve already tested, then check your configuration. For more on protocol support, DNS, and core differences, see the protocol guide. You don’t need to tune each setting for your first connection.

Step 4: Check Access and Rule Matches

Keep the client running, reopen your browser, and visit a site you expect a proxy rule to handle. An existing page may reuse a connection or cached content, so don’t judge the result by refreshing a tab that was already open. Once the page loads, open the client’s “Connections” or “Logs” page and search for the site’s domain.

Check three details in the connection record: the destination domain, the matched rule, and the outbound policy or node. For example, if your configuration includes DOMAIN-SUFFIX,github.com,PROXY, connections to matching domains should use the policy represented by PROXY. An earlier rule may match first, so rely on the actual record. Log layouts vary by client; if there’s no separate rule column, expand the connection details.

Next, visit a site or local network service you expect to connect to directly, then check its matched policy. A working proxy connection and a working direct connection are both signs that Rule mode is behaving as expected. A changed public IP address alone can’t verify every rule, since some traffic is supposed to go direct. Likewise, an enabled system proxy only confirms that the setting was applied; it doesn’t prove the node is working.

If a site won’t load, first check whether it appears in the connection list. If there’s no matching record, check the system proxy or VPN status, and see whether the browser has its own proxy settings or extension. If a record appears but the connection fails, leave other settings unchanged and try another node. If that works, troubleshoot the original node. If the record shows DIRECT when you expected a proxy, check the current mode, active configuration, and rule order before changing DNS.

If you still can’t find the cause, note the client name, operating system, time of the issue, and any error message, then follow the relevant steps in the FAQ. Remove subscription URLs, passwords, and account details before sharing logs. Once a site loads normally, you can keep using the current settings. Configure startup or UWP options only if you need them.

Clash Launch at Startup: Check Startup and Connection Separately

After confirming that a manual connection works, enable “Launch at startup” or “Start at login” in the client settings. If your operating system asks for permission to add a startup item, allow it if needed. On macOS, check Login Items in System Settings; on Windows, check whether the app is disabled in the Startup apps list. Linux desktop support depends on the client, installation method, and desktop environment.

Launching at startup only means the client process will run. It may not restore the system proxy, TUN, or a mobile VPN connection. If the client offers separate options such as “Connect on startup” or “Set system proxy on startup,” enable them only if you need them. Desktop clients using TUN may also depend on a background service, so an open window alone doesn’t confirm that networking is fully restored.

After setup, sign out and back in or restart to test it. First check that the client is running, then confirm the active configuration and mode, and finally test a site as described in step four. Startup is configured only when the whole connection works. If the connection occasionally fails after a restart, try connecting manually and check whether the network was ready in time. Don’t try to fix it by running multiple proxy clients at once.

Clash UWP Loopback: Fix Access for Specific Apps

On Windows, a browser may work while some Microsoft Store apps can’t use a local proxy. Apps that use the app container model may be blocked from accessing the local loopback address, even though the system proxy points to a local listening port. This is separate from importing a subscription successfully, and not every Store app is affected.

If your client offers “UWP Loopback,” “Loopback Exemptions,” or a similar tool, open it and grant the requested permission. Find the affected app in the list, enable the exemption only for apps that need to access the local proxy, then save. Fully quit and reopen the app, and check whether its requests appear in the connection list. Don’t enable exemptions for every app just to save time, and don’t assume a missing loopback tool means the node is broken.

If the client doesn’t include this option, check its Windows guide or, if you understand the permission implications, try routing traffic through TUN and verify the result as described in step four. Organization policies may restrict these settings. Before investigating further, confirm that the app can connect to the internet on its own; sign-in issues, app service outages, and firewall problems aren’t necessarily caused by UWP loopback.

Exit and Restore Settings: Stop Traffic Routing First

When you’re done on desktop, turn off the system proxy and TUN, if enabled, before choosing Exit from the client menu. Many clients restore system proxy settings on a normal exit. However, force-quitting the process, an unexpected shutdown, or conflicting settings from multiple clients may leave the proxy pointing to a local port. The client is no longer listening, but your browser still tries to connect to that port, so pages won’t load.

If this happens, restart the original client, turn off the system proxy, then exit normally. Alternatively, open your operating system’s network proxy settings, check whether a manual proxy still points to a local address, and disable entries you can confirm were set by that client. Don’t remove proxy settings managed by your organization. On Android and iOS, disconnect in the client, then check the system VPN settings to make sure the connection has ended.

When switching clients, follow the same order: stop traffic routing in the old client, exit it, import and activate the configuration in the new client, then connect and verify it. For help choosing a replacement, see the client comparison guide. If you’re fixing a specific issue, visit the FAQ. Keeping one proven baseline setup is easier to maintain than changing several network settings at once.