Clash Setup Guide

Before You Begin

You’ll need an installed client and a valid subscription link or local config file from a trusted source. If you haven’t installed a client yet, visit the client downloads page and choose the installer for your operating system and processor architecture. The client loads configs and handles connections; it is not itself a remote proxy service. Installing it alone won’t necessarily add any nodes to the proxy list.

Allow about ten minutes for your first setup, and use a network that can reach the subscription URL. First, note whether your device can currently browse the web, then quit any other proxy or VPN apps that are capturing traffic. Multiple tools changing the system proxy, routes, or DNS can make test results hard to interpret. Don’t disable your security software; just pause overlapping network-capture features for the test.

This guide follows the shortest path to a working connection: load one config, choose one outbound group, enable one traffic-capture method, and test one request. Leave DNS enhancements, custom rules, and rule providers untouched for now. For protocol details or core compatibility, see the protocol and core guide rather than changing too many things before your first connection.

1. Import a Subscription and Enable the Config

Open the client and go to Config or Profiles. Find an option such as “Subscription URL” or “Import from URL,” paste the full link, then click Import or Download. Don’t include quotation marks, line breaks, or surrounding text copied from a chat message. Subscription URLs often contain access credentials, so paste them only into a trusted client. Don’t post them publicly or leave the full URL visible in troubleshooting screenshots.

Wait for the download and parsing to finish. On success, you’ll usually see a config card with details such as its name, source, or last-updated time. Importing a config and using it are two separate steps. Some clients activate new configs automatically; others require you to click the card, select its radio button, or choose “Use this config.” Confirm it’s selected, then open the proxy page and check for the expected groups and outbound options.

For a local YAML file, choose “Import from file” on the Config page or open the file using your system’s file picker. Don’t paste the file contents into a subscription URL field. Select and apply the config after importing it. Some clients copy the file into their own config directory, so later edits to the original may not sync. Check how your client manages files to find out whether to reimport or edit the copy directly.

Check the Import Result

If groups appear on the proxy page, the client has read at least some of the config, but that doesn’t prove remote nodes are reachable. If the page is still empty, return to Config to confirm your selection, then check the import message or logs. A successful download followed by a parsing error may mean the link returned a login page, an error message, or a format the client doesn’t support. Don’t judge the format by the file extension, and don’t send your subscription to an unknown conversion site just to try it.

If a subscription update fails, first check that the URL is complete, the service hasn’t expired, and your current network can reach it. If the client still has a working config, keep it rather than deleting and adding it again. Updates require a separate network request: a working node doesn’t mean the subscription server is reachable right now, and a successful download doesn’t mean every node works. See the FAQ for more details.

A remote config may overwrite direct edits the next time it updates. Keep the original config during your first connection. If you need to add rules later, use the client’s supported override, merge, or extension features. For now, confirm that one config is selected on the Config page and that its groups appear on the proxy page. Then choose a proxy mode.

2. Choose Rule Mode and an Outbound Node

Open the client’s Proxy, Overview, or Outbound Mode section and find the Rule / Global / Direct switch. For your first setup, choose Rule mode. It routes each connection according to the rules in your config, deciding whether to use a proxy, connect directly, or use another outbound. It isn’t a fixed list of sites that must use a proxy: the result depends entirely on the rules and policy references in your active config.

Next, open the policy group list and find the group your config uses for most proxy traffic. Group names are set by the config author and may include terms like “Proxy Select” or “Node Select,” so don’t expect one exact name. Open the group to see whether it contains nodes or another nested group. In a manual selection group, choose a known working node and make sure it stays selected. If DIRECT is selected, relevant connections go straight to their destinations.

With an automatic selection or failover group, the client may probe and switch nodes according to the config; the interface may not let you pin a node as you would in a manual group. “Auto” in a group name doesn’t mean all app traffic is captured automatically: policy groups only decide how connections already reaching the core are routed. The operating system’s traffic capture settings are a separate step. If the group structure is unfamiliar, see the policy group and outbound sections in the concepts quick reference.

What the Three Modes Do

Global mode usually sends connections controlled by the mode to the selected global policy, making it useful for a quick comparison test. After switching, check which outbound the global group has selected. Global mode won’t capture apps that aren’t routed through the system proxy or TUN, and it doesn’t mean every bit of device traffic necessarily passes through a remote node. Direct mode sends connections normally controlled by the mode straight to their destinations. It can help restore direct access or troubleshoot a proxy path, but it won’t verify that a remote proxy works.

If the client offers latency tests, run one for the current group and wait for the results before choosing a node. A test only shows how the node reaches a specific test target; it doesn’t predict the speed of every site. Timeouts can also result from the test target, authentication, or network conditions. Choose an outbound that completes the test and can reach your actual destination. There’s no need to chase the lowest number during initial setup.

When you’re done, stay in Rule mode and note the selection in the main policy group. Then enable traffic capture. If something goes wrong, you’ll be able to distinguish a wrong outbound from traffic that never reached the core. Don’t switch modes, update the subscription, and change node settings all at once, or it’ll be hard to tell what affected the result.

3. Connect and Grant System Permissions

On desktop, check whether the client shows that the core is running. If there’s a separate Start or Run Core button, start it first, then enable System Proxy. Some clients start the core automatically; just make sure there’s no startup error. Test with a browser that follows system proxy settings. The system proxy provides apps with a local proxy address, but it doesn’t guarantee that every app or protocol will use it.

On Windows, check the system proxy settings to confirm the client enabled the proxy; there’s no need to change the port manually during initial setup. macOS may ask permission to change network proxy settings; follow the system prompt. Support for proxy settings varies across Linux desktop environments and apps. If a browser works but a command-line tool doesn’t use the proxy, that alone doesn’t mean the client is broken. Verify with a browser first, then configure environment variables or app-specific proxy settings separately if needed.

On Android or iOS, tap Connect or the start switch on the main screen. When the system first asks to establish a VPN connection or add a VPN configuration, make sure the request comes from the client you just installed, then allow it as prompted. The VPN interface is how mobile operating systems route traffic; it doesn’t mean the client’s remote protocol is necessarily a traditional VPN protocol. Once permission is granted, return to the client, wait for the connection status to stabilize, then continue.

When to Use TUN Mode

Consider TUN mode if a target app ignores the system proxy or you need to capture more types of connections. TUN routes traffic through a virtual network interface and typically involves routing and DNS settings. On desktop, it may require a service component, elevated permissions, or approval for a network extension. Follow the client’s documentation and don’t install drivers from unknown sources. If you don’t need TUN for your first test, start with the system proxy to keep troubleshooting simple.

Some clients support running the system proxy and TUN together; others recommend a specific combination. For your first test, choose one primary capture method, verify the result, then adjust as needed. On mobile, check per-app proxy, bypass lists, or per-app VPN settings too. If the test browser is excluded, its requests won’t reach the core through the expected path. Don’t just check the main switch; make sure the test app is included.

If enabling traffic capture immediately cuts off your connection, turn off the capture feature you just enabled and confirm your original connection is back. Then check the client logs for startup errors, port conflicts, or permission issues. Repeated restarts and permission prompts aren’t a substitute for troubleshooting. If you only closed a desktop window, check whether the app is still running in the system tray or menu bar; closing the window may not stop the proxy. Leave the client running and check the connection path with an actual request.

4. Verify Rule Matches and the Proxy Exit

Open the client’s Connections page, then open a new browser tab and visit a destination that should use the proxy. Make a fresh request rather than relying on a cached page. Back in the client, find the connection record for the domain or destination address. Check the matched rule, policy group, and final outbound. Fields vary between clients; you may need to open connection details to see the full policy chain.

Check that the destination loads, the connection reaches the core, and the expected outbound is used. If the record shows DIRECT and your config is meant to connect directly to that destination, the rules are working as intended. If you expected a proxy but a direct rule matched, first check which config is loaded and the order of its rules instead of immediately changing DNS. Rules are evaluated from top to bottom, so an earlier match can prevent later rules from being considered.

A trusted exit IP lookup service can help confirm the result, but remember that the lookup page is also subject to your rules. The displayed exit applies only to that request; it doesn’t show that every app on your device uses the same route. Mobile networks, IPv4 versus IPv6, and multiple exit addresses can also lead to different results. Compare the lookup with the client’s connection log rather than checking only whether the IP changed. Avoid exposing personal network details when sharing results.

Trace the Connection to Find the Problem

If the page loads but you can’t find the request on the Connections page, reload it and check whether the client is showing active connections or history. Short-lived connections may have ended, and the browser may have reused cached content. If the request is still missing, check the system proxy, browser-specific proxy settings, TUN capture scope, and whether other network tools are still running. Focus on the path from the app to the core, not remote node speed.

If the connection appears and uses the expected outbound but the destination still won’t load, check the log for errors related to that request. Authentication failures, connection timeouts, and DNS resolution errors need different fixes. Try another node in the same group and make the same request again. If all nodes fail, check the subscription status, network conditions, and error type. Change one setting at a time, and don’t assume a problem with one destination means the entire config is broken.

If a particular site fails in Rule mode, briefly switch to Global mode, select the same node explicitly, and repeat the same request. If it works in Global but not Rule mode, check the rules and policy routing first. If both modes fail, investigate the node or traffic capture path. This is a comparison test to narrow down the cause; switch back to Rule mode when you’re done. For protocol support, DNS behavior, and core differences, see the protocol guide. For common usage issues, see the FAQ.

Finally, visit a destination your config is expected to route directly and check its outbound. This verifies that the proxy connection works without sending every request down the same path. Keep the working config and policy group selection as your baseline for future changes.

Updates and Disconnecting

After your first successful connection, check the subscription update settings on the Config page. Follow the subscription provider’s recommended update frequency; refreshing more often doesn’t make the connection more stable. After changing networks, updating the config, or upgrading the client, recheck the main policy group and a target request. There’s no need to repeat every permission step. Record lasting local changes using the client’s supported override feature and keep a recoverable copy.

When you’re done, turn off the system proxy or TUN before quitting the desktop client. On mobile, tap Disconnect and confirm the system connection has ended. If your browser can’t connect after the client exits unexpectedly, check whether the system is still pointing to a local proxy that has stopped before resetting all network settings. Exiting cleanly helps prevent differences in your setup next time.