Choose a client for your platform, configure subscription imports, system proxy, and routing rules, then check the logs to confirm how traffic is routed.
The client provides the settings interface, the core handles connections, and subscriptions supply configuration. Understanding these three parts makes it easier to pinpoint issues when changing proxy modes. The examples below illustrate how configuration fields relate; available features depend on the client and its core, so check their documentation.
Rule mode selects an outbound connection based on conditions such as the domain or destination address. The first matching rule takes effect. Rather than sending all traffic through one outbound connection, you can route local services, development tools, and other traffic separately. Put more specific conditions first and the fallback rule last, and make sure every referenced proxy group is defined. If something cannot connect, check the matching rule in the connection log before changing a rule or proxy group. Switching nodes alone won’t fix rules in the wrong order.
# PROXY must be a defined proxy group
mode: rule
rules:
- DOMAIN-SUFFIX,github.com,PROXY
- GEOIP,CN,DIRECT
- MATCH,PROXYA subscription URL retrieves remote configuration, but after importing it you also need to select that profile for the core to use its proxy groups and rules. Subscriptions make it easier to receive provider updates than repeatedly pasting a whole file, but remote updates may overwrite local edits. Use the client’s override feature for personal changes and keep a backup of a working configuration. If an update fails, check the URL and account status first, then inspect the network path used to fetch the configuration. Never post a full subscription URL containing access credentials in a public forum.
TUN mode routes traffic through a virtual network interface, making it useful for apps that cannot use system proxy settings directly. Unlike the system proxy, it can capture traffic from apps that don’t opt in to proxy settings. First verify a connection with the regular system proxy, then follow the client’s prompts to install a service or grant the required permissions. Check routing and DNS together; other VPNs or virtual network interfaces can also affect results. If LAN services become unreachable, inspect route exclusions and rules instead of repeatedly switching nodes. Mobile operating systems use VPN integration differently from desktop systems.
# mihomo configuration example; requires appropriate system permissions
tun:
enable: true
stack: mixed
auto-route: true
auto-detect-interface: true
dns-hijack:
- any:53Clash is the name of a client ecosystem; not every app uses the same core. Support for protocols, rule providers, and DNS fields varies between cores, and similar interfaces don’t mean configurations are interchangeable. Check the app’s documentation and subscription requirements to confirm that the fields you need are supported. Some clients let you switch cores, but not all do. If a configuration fails to parse, check the field and line number in the log, then consult the documentation for the active core. Don’t mistake a syntax error for an unavailable node.
Cross-platform configuration sharing means reusing compatible subscriptions and rules across devices; it doesn’t mean the client automatically syncs subscription URLs or access credentials. Import the same source on each device, then check proxy group names, rule providers, and core-specific fields. Unlike copying the entire app folder, this approach accommodates system differences: desktops may use a system proxy, while mobile devices typically require VPN permission. Back up local overrides before migrating. After importing, verify DNS and outbound connections, and don’t copy device-specific paths or port settings as-is.
Check your operating system and processor architecture before comparing how clients manage configurations. On desktop, start with the system proxy; on mobile, understand the system’s VPN permission prompts. Server and router users may work directly with a core. Similar installer names don’t guarantee the same system requirements, so check compatibility notes, especially for older devices. The client itself doesn’t provide proxy service: after installation, you’ll still need a subscription or configuration file obtained legitimately and compatible with your chosen core.
For desktop browsers, development tools, and everyday apps. Choose an installer for your device architecture, import a subscription, and enable the system proxy. Set up the TUN service if you need to route traffic from more apps. If a Store app can’t connect, check for UWP loopback restrictions before assuming a general network issue or reinstalling the client.
Go to downloadsBefore installing, check System Information to see whether your Mac has an Apple Silicon or Intel processor. On first launch, follow the system prompts to grant app and network permissions, then confirm the proxy is active for your current network service. After switching Wi-Fi networks or enabling another VPN, verify routing and DNS again to avoid mistaking a network change for a subscription issue.
Go to downloadsChoose an installer for your phone’s architecture and confirm the system VPN permission when you connect for the first time. Background activity is subject to battery restrictions, so if the connection drops when the screen is off, check background activity permissions and battery saver settings. If you have other VPN apps installed, check which one is currently handling network traffic before assessing the connection.
Go to downloadsOpen the Clash Plus App Store page from the download page. The product’s official website is clashplus.io. After installing, import a compatible configuration and follow the system prompts to add a VPN configuration. A VPN status indicator only confirms that the network extension is enabled; check your rules and connection logs to verify that traffic uses the expected outbound connection.
Go to downloadsDesktop users can choose a graphical client based on their distribution’s package manager. For command-line tools, you may also need to set proxy environment variables separately. Desktop environment proxy settings aren’t always passed through to terminals or background services. Before using TUN, check service permissions, routing, and existing network tools; enabling settings one at a time makes troubleshooting easier.
Go to downloadsThe download page lists clients and system requirements by platform. For installation, service permissions, and platform-specific details, see the Platform Guide. If you already have a working configuration, go straight to the connection steps below.
Keep your first setup simple: run only one proxy client and start with a known-working configuration. Don’t change DNS, rules, and virtual network settings at the same time. After you’ve verified a connection you can reproduce, add startup behavior or personal overrides one at a time. If something breaks, you’ll know which change to undo.
In configuration management, add a remote profile and paste the full URL provided by your service provider. Wait for the configuration to load, then select the profile and confirm its proxy groups and rules are available. An imported profile that isn’t active won’t supply the configuration you expect—even if the main switch is on. If an update fails, check for extra spaces in the URL and confirm the subscription hasn’t expired, then review the client logs. Don’t delete all your settings and start over.
See how to import a subscription →Set the proxy mode to Rule, select an outbound connection in any proxy group that requires manual selection, then enable the system proxy. Global mode is useful for short-term troubleshooting, but it isn’t a fix for every issue. Consider TUN only after confirming that the target app doesn’t use the system proxy. TUN still needs valid rules and a working outbound connection: the virtual interface changes how traffic reaches the core, not the connection details in your subscription.
See how to configure the system proxy →Visit a site you expect to use the proxy, then check its domain, matched rule, and outbound connection in the client’s connection log. Also test a local network service to confirm that direct connections still work. A successful latency test only shows that the test request completed; it doesn’t verify real browsing, downloads, or app traffic. If the browser works but one app doesn’t, check how that app connects to a proxy. If nothing works, troubleshoot the subscription, DNS, and local ports one by one.
See rule and connection verification steps →The Clash ecosystem includes rule-based proxy cores and clients built around them. After the original Clash project was discontinued, the community continued developing compatible implementations. Mihomo follows the Clash.Meta project lineage and extends compatible configurations with additional protocol, rule, and DNS capabilities. Search results may still use all these names, so check the client’s actual core to assess compatibility rather than assuming products have the same features because their names include Clash.
Open-source project repositories let you review code, commit history, issues, and licenses. They’re useful for checking whether a field is supported or whether an issue has already been discussed. Community projects aren’t maintained by a single team: cores, graphical interfaces, and subscription services all have their own release schedules. This site organizes download links and user guides; its brand name doesn’t imply that it co-maintains every upstream project. Check each project’s documentation for release sources and license terms.
Updating a client may change its interface, system integration, or bundled core. Updating a subscription fetches new configuration from its provider; one doesn’t replace the other. Some clients bundle a core, while others provide a separate update option, so read the release notes before proceeding. If a configuration won’t parse, first determine whether the syntax is incompatible or the remote content is invalid. Then decide whether to update the software, revise the configuration, or contact the subscription provider. Avoid changing multiple layers at once.
Before upgrading, keep a copy of your working configuration and personal overrides, and note key settings such as proxy mode and network access method. After upgrading, verify that the configuration loads, then check everyday access and LAN services; compare logs if needed. An old client may still launch but lack support for newer protocols or system compatibility fixes. Discontinued apps can help explain legacy configurations, but for everyday use, choose an actively maintained client that supports your current system.
Open source means code can be reviewed and used under its license; it doesn’t mean proxy service is free or subscription details can be shared publicly. Subscription URLs often grant access to an account, and configuration files may contain server credentials. When reporting an issue, you can include error fields, rule order, and your environment, but remove subscription URLs and authentication details. A minimal, sanitized reproduction is more useful for discussion and easier to troubleshoot than a full configuration.
These articles cover three common scenarios: verifying your first connection, troubleshooting node timeouts, and understanding latency tests. Choose a path based on what you’re seeing: start with connection verification if you haven’t confirmed the proxy is working; investigate timeouts when repeated requests fail with the same configuration; if test results don’t match your experience, distinguish latency from throughput and packet loss. Keeping logs from when the issue occurred is more useful than repeatedly reimporting the subscription.
For your first session after importing a subscription, follow these steps: switch to Rule mode, choose a proxy group, test latency, then check the logs and your IP to confirm traffic is going through the proxy.
Read the connection verification guide →Troubleshoot node timeouts in order, starting with your local network and system clock, then checking subscription status, protocol settings, and blocked ports. Find the likely cause and what to do next.
Read the node timeout troubleshooting guide →See what happens during url-test requests, how handshake time, test URLs, bandwidth, and packet loss differ, and why a low-latency node isn’t always faster in practice.
Read how latency tests work →