Mihomo is a rule-based network proxy core that reads a YAML configuration and routes each connection through a proxy or directly, based on domain, IP, and process rules. Use it to run Clash-compatible proxy setups on servers and inside desktop, mobile, and router clients.
Mihomo is a command-line network proxy core that reads a YAML configuration file and decides, connection by connection, whether traffic goes out directly or through one of your configured proxies. It handles protocol negotiation, DNS resolution, and traffic forwarding while you or a client application supply the server list and routing rules. The typical workflow starts with a config.yaml file that declares proxies, proxy groups, rule providers, and rules; Mihomo loads that file at startup, opens its local listening ports, and exposes a RESTful API for monitoring. Desktop and mobile clients such as Clash Verge Rev and FlClash bundle the core and manage that configuration for you, so the same routing logic serves hand-written server setups and click-driven apps alike.
Beyond basic forwarding, Mihomo adds features that plain HTTP proxies do not attempt: TUN mode captures traffic from applications that ignore system proxy settings, a built-in DNS module with fake-ip and encrypted upstreams keeps name resolution consistent with your rules, and subscription-aware proxy providers refresh node lists without a restart. Configuration lives in readable YAML, so a setup can be version-controlled, shared, or generated by scripts. If you manage remote infrastructure rather than a single desktop, tools like Outline Manager solve a different problem by creating and administering Shadowsocks servers, while Mihomo operates as the local engine that chooses what to send through them. Caching, process matching, and health checks round out the package.
The main benefit of Mihomo is control: instead of sending every request through one tunnel, you describe intent in rules and let the engine apply them per connection, so local services stay fast while selected domains, IP ranges, or applications use a proxy. That granularity pays off in everyday use, because streaming, banking, and office tools can each follow different paths without you switching anything manually. A second benefit is flexibility. The same configuration format works across many front-ends, so moving between a desktop client, a phone app, or a headless router box rarely means rewriting rules. Health checks and fallback groups keep a broken node from stalling your work, and provider support means new servers appear without a restart. Because it is a lightweight background process with an HTTP API, it integrates cleanly with dashboards, scripts, and existing service managers. For anyone who needs repeatable, documented routing rather than a single toggle, Mihomo is the dependable layer that does the work quietly.
Every connection is evaluated against the rules you write, which can match domain names, domain suffixes, IP ranges, geo-located IP databases, client processes, or third-party rule sets. Traffic that matches goes through the proxy or group you name, and everything else follows your final rule. In practice this means you can send only the sites and applications that need a tunnel, keeping local and latency-sensitive traffic direct.
Groups bundle several servers so the core can choose between them automatically. Select groups wait for your manual choice, url-test groups pick the fastest node at a set interval, fallback groups switch when the current server fails, and load-balance and relay types spread or chain traffic. Health checks run against a test URL, so a dead node is skipped instead of breaking your browsing.
Providers pull node lists and rule collections from remote URLs or local files and reload them on a schedule, so subscription updates and rule-set changes arrive without editing your main configuration. Filters and exclusions tidy messy provider lists before they reach a group, which keeps large node sets usable rather than overwhelming. The result is a configuration that stays current with little manual maintenance.
TUN mode creates a virtual network interface and captures traffic at the operating-system level, so applications that ignore system proxy settings still follow your rules. The alternative system-proxy mode sets the proxy environment directly and leaves more of the network stack untouched. Choosing between them lets you decide how broadly traffic should be intercepted on a given machine.
The DNS module resolves names itself instead of leaving them to the operating system, supporting fake-IP mode, per-domain nameserver policies, hosts entries, and encrypted upstream protocols. Because resolution happens inside the core, routing rules match the names you actually intended and name lookups travel through the path you chose, which reduces leaks and mismatched routing decisions. Caching keeps repeat lookups fast.
A single configuration can mix many outbound types, including Shadowsocks and its variants, VMess, VLESS, Trojan, Hysteria and Hysteria2, TUIC, WireGuard, SOCKS5, HTTP, and SSH. Each server keeps its own transport options, so plugins, TLS settings, and multiplexing are configured per node. That breadth means a provider change usually needs a new entry rather than a different tool.
An HTTP controller exposes live state: active connections with their matched rule and route, upload and download totals, current group selections, and logs. Dashboard front-ends and scripts use that API to display traffic, close connections, or switch nodes, and the same endpoint makes automation possible for monitoring and switch-over workflows.
Everything lives in a plain YAML file that lists proxies, groups, providers, rules, and DNS settings in human-readable text. That makes configurations easy to review, diff, back up, and generate from templates or scripts, and it means a working setup can be copied between machines. Comments and sensible defaults keep the file approachable even as it grows.
Mihomo is a proxy core: it reads a configuration file, accepts network connections from applications on the machine, and forwards each one either directly or through a proxy server according to your rules. It also handles DNS resolution and exposes an API for monitoring. It is not a full application by itself, so you either run it as a background service or let a graphical client manage it for you.
No. Mihomo is deliberately headless and runs from the command line, with a configuration folder supplied as a startup argument. The graphical experience comes from separate clients that embed the core, such as Clash Verge Rev, FlClash, or Clash Meta for Android, which write the configuration and start and stop the process for you.
It continues the Clash family. The original Clash project was discontinued and taken down, and the community fork Clash.Meta carried the work forward before being renamed Mihomo. Because the configuration format stayed compatible, existing YAML files and subscription links generally keep working, which is why the ecosystem still uses the name Clash informally.
Usually not. Most desktop and mobile clients bundle a compatible core and keep it updated, so installing another copy alongside them only creates confusion about which build is handling your traffic. Running the core on its own makes sense for headless machines such as servers, containers, or routers, where no graphical client is available.
Create a config.yaml containing your proxies, proxy groups, providers, rules, and DNS options, place it in a working directory, and start the program pointing at that directory. You can also use rule providers and script shortcuts to keep the file modular. If a graphical client manages the core, edit settings inside that client instead of touching the file by hand.
Yes. Rules can match the process or package name behind a connection, so one application can be sent through a proxy while another goes direct on the same machine. Domain, IP, and geo-based rules work alongside those process rules, which lets you build a policy that mixes application-level and destination-level decisions in a single configuration.
Comments