Core migration dashboard
From system traffic interception to DNS resolution chains, modern configuration goes beyond simple forwarding. Select a capability on the left to see the problem it solves, where to configure it, and its practical limits.
TUN mode captures traffic from apps that do not read system proxy settings, including some game launchers, command-line tools, and standalone network programs. Once enabled, the core receives traffic through a virtual network interface and passes it to the rule engine for a direct connection, proxy, or rejection. Compared with simply enabling the system proxy, it covers more traffic but depends more heavily on administrator permissions, routing, and DNS. Start with the mixed stack and confirm that local subnets still connect directly. If LAN devices become unreachable, check route exclusions instead of repeatedly switching nodes.
tun:
enable: true
stack: mixed
auto-route: true
strict-route: falseRule mode evaluates domains, IPs, processes, and network types against the configuration, while proxy groups decide which node to use. It addresses the detours caused by sending every request through one path: local services can connect directly, selected sites can enter a proxy group, and unmatched traffic is handled by the final rule. Put more specific rules first and fallback rules last; proxy group names must match their rule targets exactly. Compared with a simple global proxy, this approach is better for long-running use and makes it easier to identify the rule matched by a request.
proxy-groups:
- name: Manual Selection
type: select
proxies:
- DIRECT
rules:
- DOMAIN-SUFFIX,example.com,Manual Selection
- MATCH,DIRECTCentralized DNS handling reduces conflicts between system resolution results and proxy rules. After the client takes over queries, it can choose DNS servers by domain category and keep Fake-IP mappings aligned with connection records. The goal is not simply faster responses, but keeping domain-rule decisions and actual connection targets on the same chain. Preserve filters for LAN domains, time-sync services, and some game domains. If core DNS is disabled, also check whether the system, browser, or security software has enabled encrypted DNS separately, which can cause multiple resolution chains to interfere.
dns:
enable: true
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
respect-rules: truemihomo brings multiple proxy protocols into one configuration system. The client can pass subscription content to the core without installing a separate connector for each node type. Compatibility does not mean every parameter is interchangeable: the transport, TLS settings, server name, user identity, and port must still match the provider's details. When an import fails, first confirm that the subscription is complete, then verify that the client is calling the mihomo core correctly. Compared with clients tied to the old core, the newer ecosystem handles evolving protocol fields better, but invalid fields still appear clearly in startup logs and should be corrected one by one.
Subscription updates usually replace the remote configuration. If personal rules are written directly into the subscription, they may disappear at the next refresh. Overrides and merging place local ports, DNS, rules, and proxy-group changes in a separate layer, then combine them with the subscription to generate the runtime configuration. This suits users who need fixed LAN settings, additional direct-connection rules, or renamed proxy groups. Distinguish between appending and overriding: appended rules still depend on order, while an overridden field with the same name replaces the original value. After editing, inspect the final generated YAML rather than checking only the override fragment.
mode: rule
mixed-port: 7890
allow-lan: false
log-level: infoClient download center
Graphical clients handle subscription imports, proxy switching, and system proxy controls; the mihomo core handles connections and rule evaluation. Open the download page for your device first, then choose a client based on its installation method and your workflow.
Ideal for desktop work, browser proxies, and apps that need TUN interception. The download page lists graphical clients and distinguishes maintained projects from archived ones. After installation, import your subscription and enable the system proxy only when needed; configure TUN only for apps that ignore the system proxy.
Go to downloadsSuitable for both Apple Silicon and Intel Macs. Before choosing an installer, confirm the processor architecture. The first launch may also require permission for the system network extension or proxy. Menu-bar clients make everyday proxy switching easy, while desktop clients are better for reviewing connection logs, matched rules, and subscription content.
Go to downloadsAndroid clients typically use the system VPN interface to capture app traffic, so individual apps do not need separate proxy settings. After importing a configuration, choose which apps should use the proxy. If the connection drops in the background, check battery optimization, VPN permissions, and background restrictions instead of changing nodes first.
Go to downloadsiPhone and iPad use a system network extension to establish the proxy connection. After installation, allow the VPN configuration to be added, then import the subscription in the client. Switching between mobile data and Wi-Fi may cause the system to reconnect. If rules do not behave as expected, reload the configuration and check the current proxy group first.
Go to downloadsDesktop users can choose a graphical client, while servers, software routers, and containers often run the mihomo core directly. Direct core operation requires you to manage configuration paths, permissions, logs, and startup services yourself, as well as the routing and firewall rules needed for transparent proxying.
Go to downloadsQuick-start preview
You do not need to change every setting on your first run. Install the client and import the subscription, confirm that the basic connection works, then tune proxy groups, DNS, and TUN step by step.
Open the download page, select your operating system, then choose a client based on processor architecture and how you plan to use it. Windows and macOS users usually start with a graphical client; Android and iOS require system VPN permission; Linux server users can run the core directly. After installation, open the client and confirm that its interface loads normally. Do not repeatedly toggle the system proxy before importing a configuration.
Paste the subscription URL provided by your service provider into the configuration or subscription page, then select the imported configuration after updating. Open the proxy or policy page and confirm that usable nodes appear in the selection group. A subscription URL is not an ordinary webpage link, so do not use a browser to judge whether its contents are complete. If parsing fails, check for spaces introduced during copying, an expired URL, and valid YAML structure.
Select rule mode first, then enable the system proxy or mobile VPN. Watch connection logs to see whether requests enter the expected proxy group, and visit a local service to confirm that direct-connection rules still work. If a regular browser connects but a standalone app has no traffic, consider enabling TUN. If domain resolution is abnormal, return to DNS settings and check enhanced mode and the filter list. Following this order separates node, rule, system interception, and DNS issues.
Open-source ecosystem and core handoff
The client interface and proxy core are two independent components. Understanding this relationship helps identify where updates come from and where to find the right logs and configuration entry points when something goes wrong.
Clash established a workflow centered on YAML configuration, rule lists, and proxy groups. Many desktop and mobile clients were built around this structure. When the old core stopped advancing, existing subscription formats, rule conventions, and client workflows did not disappear at the same time. Building on compatibility with common Clash configurations, mihomo continues to maintain core capabilities. Many so-called “Clash Meta clients” today are essentially graphical interfaces that call mihomo for connections, DNS, rule matching, and traffic interception.
This handoff usually means migration does not require rewriting a configuration from scratch, but it does not mean every legacy field should be kept unchanged. Long-unupdated templates may contain obsolete options or private fields tied to an old client. A safer migration process is to import the original configuration, review startup logs, and then organize DNS, TUN, and proxy groups one by one instead of copying a large set of overrides at once.
The mihomo core handles network connections and rule execution. Clients such as Clash Plus, Clash Verge Rev, and FlClash provide graphical controls, system integration, and configuration management, while rule-set projects offer reusable domain or IP categories. These components can update on their own schedules, and users can switch interfaces by platform while keeping a similar configuration approach. For interface crashes, tray failures, or a system proxy that cannot switch, check the client first. For configuration parsing, protocol connections, and rule matches, inspect the core logs.
This layered structure also reduces dependence on any single client. A desktop configuration can move to another client that calls mihomo, and a server configuration can run directly through the core once paths and permissions are clear. However, clients implement override scripts, configuration storage, and system services differently. Before migrating, export local rules and record the DNS and proxy settings currently in use.
A Clash configuration mainly declares ports, proxy nodes, proxy groups, DNS, and rules. After reading it, the client may merge the subscription with local overrides before passing the final result to mihomo. The merged runtime configuration—not the original subscription or an individual override fragment—determines where connections go. When troubleshooting, locate the final configuration generated by the client and read it together with the logs; this is more reliable than focusing only on a subscription editor.
Rules are matched in order, so specific conditions earlier in the list usually take priority over broad conditions later on; proxy groups determine how a matched request selects a node. DNS resolution affects the targets seen by domain and IP rules, while TUN determines which app traffic can enter the core. These four parts are connected, so switching nodes without effect does not prove that the node is at fault. The request may never have entered the core, or an earlier rule may have sent it to another proxy group.
Client updates and core updates address different concerns. A client update may change installation, interface layout, system services, or subscription management; a core update is more likely to affect protocol implementation, DNS behavior, rule syntax, or the network stack. If basic connectivity still works after an update, there is usually no need to rewrite the configuration immediately. Adjust the relevant sections only when logs show deprecated fields or parsing failures, or when network behavior has clearly changed.
For long-term use, keep a simple base configuration with an explicit mode, ports, DNS, proxy groups, and final rules, then extend it with rule sets or overrides. The more complicated the configuration, the harder it is to identify the layer causing a conflict after an update. Ensuring the base chain works before adding custom rules one by one is a lower-cost way to maintain a migration from the old core to the new one.
Configuration and troubleshooting articles
From DNS behavior and certificate errors to router deployment, these articles break configuration chains down by problem, making it easier to continue troubleshooting when the client connects but behaves unexpectedly.
Starting with DNS queries entering the core, this guide explains how the fake address pool stores domain mappings, how targets are restored during connections, and which filtering strategies suit browsers, games, and LAN services. It also covers the Redir-Host resolution path to help determine whether an issue comes from address mapping or upstream DNS.
Read the full article →Certificate errors can come from the system clock, browser cache, the node path, local security software, or decryption settings. This guide verifies each layer based on the scope of the error: first check whether only one site is affected, then compare direct access, system certificate status, and proxy logs instead of blaming every certificate issue on the node.
Read the full article →Compare running mihomo on the main router with using a bypass router for traffic interception. The guide explains how binary architecture, configuration directories, transparent proxying, DNS forwarding, and startup services fit together, with emphasis on pre-deployment architecture decisions: which traffic reaches the core and whether the original router still handles DHCP and gateway duties.
Read the full article →