Mihomo compatible
Keeps Mihomo YAML, rules, DNS, TUN, proxy groups, and the Clash-compatible API.
Compatible with Mihomo configuration and Clash dashboards, plus AnyTLS + REALITY, upstream fixes, and performance work.

Aster Core is a client-oriented fork of MetaCubeX/mihomo. It usually runs on a computer, router, or gateway and connects to nodes provided by Xray, sing-box, SideraCore, or another compatible implementation.
The project keeps Mihomo configuration, rules, DNS, TUN, and the Clash-compatible controller, then adds AnyTLS + REALITY and fixes upstream issues around connections, reloads, and updates. Aster can also host VLESS / AnyTLS listeners and manage users, but that path is optional.
In plain terms: Aster removes core work that used to be redone for every packet. The medians below come from three identical rounds on a real OpenWrt soft router:
| Workload you actually hit | How much faster | What that means |
|---|---|---|
| TCP core forwarding | about 2% faster | Less wasted work while moving data, and no per-relay allocation |
| AnyTLS framing | about 1.4–2.0× faster | Lower packing cost on high-speed transfers or many small packets |
| New UDP packet setup | about 5.4× faster | Games, voice, and QUIC create less throwaway memory |
| Disabled debug logs | about 101× faster | Unused logs are skipped before the string is built |
Memory needs separate claims. These hot paths remove per-operation heap allocations, but the complete core with a minimal idle profile measured about 39.3 MiB for Aster and 34.7 MiB for Mihomo on OpenWrt, so Aster was about 4.6 MiB larger. The five-run Windows validation on 2026-08-24 likewise put Aster's working set about 0.93 MiB higher. Aster does not claim universally lower idle RAM; the benefit is less temporary garbage on busy paths plus explicit cache, mapping, and pool bounds.
IMPORTANT
This does not mean Speedtest becomes 5.4× faster. That figure is one small core step: preparing UDP metadata. The closest whole-path number is the TCP test, about 2%. The Ryzen 7 5825U soft router is still stronger than many home routers, so do not copy these figures to another device. The single-core 25% CPU-quota / 512 MiB run only shows that the gains persisted under throttling on the same x86 VM; it does not simulate ARM, MIPS, cache, or memory bandwidth. The homepage keeps the conservative unrestricted result.
WARNING
“Closer to dae” is not the same as faster. On one real OpenWrt router, the experimental TC eBPF classifier dropped same-server speedtest from about 1,647 Mbps to 692 Mbps. The recommended setup is still Kernel DIRECT with the nftables backend and OpenWrt flow offload. See OpenWrt and Nikki.
Full numbers, three-round ranges, and the test method are in Performance and benchmarks.
Field-level details live in Configuration. Deployment notes are on the Docker, Linux, and OpenWrt / Nikki pages.