# Local configuration snippetmixed-port: 7890
allow-lan: false
mode: rule
log-level: info
dns:
enable: true
enhanced-mode: fake-ip
rules:
- DOMAIN-SUFFIX,github.com,PROXY
- GEOIP,CN,DIRECT
- MATCH,PROXY
# PROXY must match a defined policy group
YAMLUTF-8Rule mode
Rule map
‹•••
Network settings
Traffic routing
System proxy
TUN mode
Allow LAN connections
Proxy mode
RuleGlobalDirect
Profiles, cores, and interfaces each have a role
Clash is a proxy ecosystem, not a single app that works identically on every platform. Clients provide interfaces for importing profiles, switching settings, and viewing logs. The core handles protocol connections and rule processing, while configuration files define proxies and policies. When choosing a client, check your operating system and processor architecture first, then confirm that its core supports your existing configuration. Similar-looking interfaces do not guarantee identical fields or permission requirements.
Import a subscription, then activate the profile
Paste the subscription URL from your service provider into the Profiles page. Wait for it to finish downloading, then select the profile. Next, open the Proxies page and check that the policy groups contain usable proxies. A successful import only means the file was retrieved; it does not mean your system traffic is being routed through Clash. Subscription URLs may contain access credentials, so remove them before sharing screenshots, logs, or support requests.
Rules determine where traffic goes; policy groups choose the exit
Rule mode is a good starting point for everyday use. Requests are matched against a domain or address, then handled by the corresponding policy group. A manual group is useful when you want a fixed exit, while an automatic test group can select a candidate based on its configured criteria. If one website misbehaves, check the matched rule and actual exit on the Connections page. There is no need to route all traffic through a global proxy right away.
Check traffic routing and connection quality separately
The system proxy mainly affects apps that follow the system proxy settings. TUN uses a virtual network interface to route a wider range of traffic. Neither can directly improve the quality of a remote connection. When troubleshooting, first confirm that requests reach the core, then inspect the rules, DNS results, and exit. Change one setting at a time and keep a working profile so you can tell whether a change actually fixed the problem.
Rules are checked from top to bottom, and the first matching rule usually determines where a request goes. Put specific domain rules before broader ones, then use MATCH at the end to catch everything else. DOMAIN-SUFFIX matches a domain and its subdomains; IP-CIDR matches an address range; GEOIP relies on a geolocation database. PROXY in this table is an example policy group name, so define a group with that exact name in your configuration before using it. Reload the profile after making changes, then check the matched rule on the Connections page instead of judging by whether a webpage loads.
Policy groups organize proxies into selectable exits. A select group lets you choose manually. A url-test group selects a candidate based on the configured test URL, interval, and tolerance. A fallback group switches according to proxy availability and its configured order. Automatic selection does not guarantee faster downloads, and test results cannot represent every website. First verify that a proxy works with a manual group, then consider an automatic policy. After updating a subscription, check the group members to make sure rules do not point to a removed or renamed policy.
Type
Target
Policy
DOMAIN-SUFFIX
github.com
PROXY
IP-CIDR
192.168.0.0/16
DIRECT
GEOIP
CN
DIRECT
MATCH
Other requests
PROXY
These examples illustrate how matching works; they are not complete, standalone configurations. Add LAN ranges that match your network, and do not rely on geolocation rules in place of explicit decisions about service domains.
Some command-line tools, games, and standalone network components do not use the system proxy. If the client supports TUN, a virtual network interface and routing settings can send this traffic to the core, where rules decide whether to connect directly or use a proxy. Desktop systems may require service mode or administrator privileges; mobile devices typically use the system VPN interface. Get a regular connection working before enabling TUN, then test the target app separately. TUN does not guarantee that all traffic will be routed; exclusions, platform permissions, and other network software can affect coverage.
DNS resolves domain names to addresses and can also affect whether domain-based rules have the information they need. Fake-IP mode maps domain names to a reserved address range, keeping the domain associated with subsequent connections. For devices or apps that need real DNS results, consult the core documentation to determine whether to configure fake-ip-filter. DNS hijacking, encrypted system DNS, and built-in app resolvers can all change how requests are handled. Record the original settings, change one thing at a time, and test web browsing, LAN services, and app sign-in separately.
After turning on TUN, check the core logs for interface, permission, or routing errors rather than relying on the toggle alone. On desktop, confirm that the client service is installed correctly; on mobile, check whether VPN permission has been revoked. Existing VPNs, virtual machine adapters, or security software can affect the default route, so disable them one at a time to compare. If enabling TUN cuts off all network access, turn it off to restore the basic connection, save the error details, then follow the client documentation to resolve permission or routing conflicts.
System proxy and TUN are two ways to route traffic into Clash; rule mode determines which exit to use. They operate at different layers, so rule-based routing can still be used with TUN enabled.
Check your operating system, architecture, and permissions before choosing an installation method. If you already have a profile, also confirm that its protocols and core-specific fields are supported.
Windows
For a first setup, start with Clash Plus, or choose another client such as Clash Verge Rev or FlClash to suit your workflow. Before downloading, check your processor architecture in system settings; do not rely on the computer’s brand alone. After installation, import a profile and enable the system proxy. If you need to route traffic from other apps, check the service mode and TUN permissions.
If websites work in your browser but not in some system apps, first check whether those apps follow the system proxy. UWP apps may require a separate loopback exemption; the issue is not necessarily a broken proxy. Before switching clients, quit the existing one to avoid multiple apps competing for the same local listening port.
Choose the installer that matches your Apple Silicon or Intel device. Clash Plus, Clash Verge Rev, and FlClash offer different interfaces and profile management options; compare them on the download page before installing. Follow the system prompts to grant permissions on first launch, then confirm that the menu bar client is actually running.
System proxy and network extension permissions have different scopes, so verify the target app again after changing how traffic is routed. If your workplace network relies on automatic proxy settings or specific DNS, record the original settings first. When quitting the client, turn off the proxy cleanly to avoid leaving the system pointed at a local port that is no longer listening.
Choose Clash Plus, Clash Meta for Android, or FlClash based on your configuration needs. Before installing, check your device’s supported architecture. Import a subscription, grant the system VPN permission, then choose an exit in the policy group. Android’s VPN interface generally cannot be used at the same time as another VPN app.
If the connection drops after the screen locks, check background activity permissions, battery optimization, and your device manufacturer’s power-saving settings. Do not assume battery optimization is the cause: compare mobile data with Wi-Fi, check whether the subscription has expired and the proxy is available, and see whether switching networks restores the connection.
The download page links to Clash Plus on the App Store and lists the official website, clashplus.io. After installing, follow the app prompts to import a compatible profile, add a VPN configuration, and grant system permission. Test a few commonly used websites on your first connection, then check the policy groups and connection history in the app to confirm that traffic is using the expected exit.
Mobile operating systems restrict background activity and network extensions, so desktop instructions for installing services or configuring loopback access do not apply as-is. If a subscription fails to parse, first check its format and client compatibility rather than repeatedly deleting the system VPN configuration.
On desktop Linux, compare Clash Verge Rev and FlClash, choose a package format for your distribution, and check the required system dependencies. Terminal apps may not inherit your desktop proxy settings. You may need to set proxy environment variables for the current process, or enable TUN after understanding its routing implications.
For servers and routers, see the Mihomo packages in the core section. Running the core on its own means managing the configuration path, service permissions, and logs yourself. Do not copy network interface names or routing parameters from another device. If working remotely, have a way to restore your connection before making changes.
Distinguish project origins, client maintenance, and network services to focus updates and troubleshooting in the right place.
Clash is an ecosystem, not a single client
Clash began as a rule-based proxy core and grew into an ecosystem of desktop interfaces, mobile clients, and configuration tools. The original project and its derivatives do not all share the same maintenance status. Today, the name Clash may refer to a core, a configuration format, or simply a client. When discussing compatibility, include the client name, core type, and operating system instead of saying only “Clash isn’t working.”
Clash Tutorial Hub organizes client downloads and English-language setup guides. It is not the development team behind these clients and does not provide proxy services. The download page lists client options by platform and marks projects that are no longer maintained. Prefer a maintained client that can read your existing configuration. Screenshots and field names in older guides are useful clues, but follow the current client documentation for exact steps.
How Mihomo relates to graphical clients
Mihomo is a maintained open-source core in the Clash ecosystem, formerly known as Clash.Meta. The core handles protocols, DNS, rule matching, and traffic forwarding; graphical clients manage profiles, system integration, and the user interface. A single toggle in the interface may change both core parameters and system settings. To identify which layer is causing a problem, first check whether the profile loaded, then review the core logs, and finally inspect the system proxy and routing.
YAML that follows Clash conventions does not mean every core supports the same fields. Newer protocols, rule providers, and DNS options may require a specific core. When migrating a profile, keep the original file and import a copy into the new client. If you see an unknown field or missing policy error, inspect the reported location rather than deleting all DNS or rules. The command below only retrieves the Mihomo source code; it does not install a graphical client or provide usable proxies.
Clients, cores, and subscriptions update separately
Client updates can change system integration and the interface; core updates can fix protocol and network behavior; subscription updates mainly refresh proxies, policy groups, or rules. These are separate updates. Before updating, save local overrides, routing rules, and any screenshots you may need. Afterward, confirm the profile is still selected, then check its proxy members and traffic routing settings. Avoid changing the client, subscription, and DNS all at once, or it will be difficult to pinpoint the cause of a problem.
A subscription manager may overwrite manual changes. Before keeping custom rules long-term, check whether the client supports overrides or merging, and inspect the resulting configuration. If it does not, save a separate copy at minimum to avoid losing your changes at the next subscription refresh. To run on startup, verify client auto-launch, core startup, and proxy restoration separately; the tray icon alone is not enough.
Use connection history to verify your configuration
The Connections page usually shows request destinations, matched rules, and exit policies. The Logs page is better for investigating DNS resolution failures, handshake failures, or permission errors. A latency test reflects only its specific test conditions; it does not measure bandwidth, stability, or speed across all websites. For comparable results, keep the network and target fixed and switch candidate proxies one at a time.
When sharing troubleshooting details, include the error type, steps to reproduce, system environment, and relevant fields. Remove subscription URLs, account details, and proxy credentials. If a browser works but one app does not, check traffic coverage first; if all requests fail, inspect the core, DNS, and exit. Comparing connection history before and after a change is more useful than switching several toggles in a row.
Start with persistent VPN notifications, background restrictions, and manufacturer power-saving settings, then use TUN and DNS settings to investigate unusual battery drain. First distinguish continuous traffic from repeated wake-ups before changing background permissions. Keeping the app alive is not the only goal; check actual traffic too.
Learn how reserved addresses and domain mappings affect connection handling, and compare the behavior of the two DNS modes. Consider LAN access and apps that need real addresses to decide when to configure exclusions, rather than switching your entire DNS setup.
Check proxy quality, ISP routing, matched rules, DNS resolution, and your local network separately. Keep other conditions unchanged while testing each layer, and compare repeatable results to distinguish high latency, low throughput, and failed connections.
