Skip to content

Aster CoreA client-first proxy core built on Mihomo

Compatible with Mihomo configuration and Clash dashboards, plus AnyTLS + REALITY, upstream fixes, and performance work.

Aster Core

About Aster Core ​

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.

How much faster than Mihomo? ​

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 hitHow much fasterWhat that means
TCP core forwardingabout 2% fasterLess wasted work while moving data, and no per-relay allocation
AnyTLS framingabout 1.4–2.0× fasterLower packing cost on high-speed transfers or many small packets
New UDP packet setupabout 5.4× fasterGames, voice, and QUIC create less throwaway memory
Disabled debug logsabout 101× fasterUnused 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.

What changed? ​

  • Reuse buffers: TCP, UDP, and AnyTLS recycle scratch space instead of allocating for every packet.
  • Fewer global locks: rules and proxy lists publish a snapshot, so connections do not queue on one lock.
  • Less repeated UDP work: addresses stay in a comparable form, and socket timers are refreshed in batches.
  • AnyTLS is precomputed: padding rules are parsed once, then frames are packed directly.
  • Disabled logs do no work: messages that will not be shown are skipped before formatting.
  • Cheaper traffic stats: upload and download counters increment in place instead of scanning every connection.

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.

Start here ​

Field-level details live in Configuration. Deployment notes are on the Docker, Linux, and OpenWrt / Nikki pages.