↗
Mihomo 相容
沿用 Mihomo 的 YAML、規則、DNS、TUN、代理群組與 Clash-compatible API。
Aster Core以 Mihomo 為基礎的客戶端代理核心
相容 Mihomo 設定與 Clash 面板，加入 AnyTLS + REALITY、上游問題修正及效能改善。
Skip to content
關於 Aster Core
Aster Core 是 MetaCubeX/mihomo 的衍生專案，主要用於客戶端。它通常裝在電腦、路由器或閘道上，連接由 Xray、sing-box、SideraCore 或其他相容實作提供的節點。
專案保留 Mihomo 的設定格式、規則、DNS、TUN 與 Clash 相容控制介面，另外加入 AnyTLS + REALITY，並修正上游仍存在的連線、重新載入及更新問題。Aster 也能提供 VLESS／AnyTLS 入站與使用者管理，但這部分屬於選用功能。
比 Mihomo 快多少？
先講人話：Aster 把代理核心裡「每個封包都要重做一次」的雜工砍掉了。以下是在實際 OpenWrt 軟路由上，相同測試各跑三輪的中位數：
| 你會遇到的工作 | Aster 快多少 | 代表什麼 |
|---|---|---|
| TCP 核心轉送 | 約快 2% | 搬資料時少做一些無用工作，並消除每次轉送的記憶體配置 |
| AnyTLS 封包打包 | 快約 1.4–2.0 倍 | 高速傳輸或很多小封包時，打包成本更低 |
| UDP 新封包準備 | 快約 5.4 倍 | 遊戲、語音、QUIC 等大量 UDP 封包較少製造垃圾記憶體 |
| 被關掉的 debug log | 快約 101 倍 | 不需要的 log 不再先做好再丟掉 |
記憶體必須分開看：這些 hot path 已消除每次操作的 heap allocation，但完整核心以最小設定空載時，OpenWrt 測得 Aster 約 39.3 MiB、Mihomo 約 34.7 MiB，Aster 多約 4.6 MiB。2026-08-24 的 Windows 五輪中位數也顯示 Aster working set 多約 0.93 MiB。Aster 不能宣稱空載一定比較省 RAM；優勢是忙碌路徑少製造暫存垃圾，並為 cache／mapping／pool 加上界線。
改了什麼？
- 記憶體重複用： TCP、UDP 和 AnyTLS 用過的暫存空間收回再用，不再每個封包都重新申請。
- 少搶同一把鎖： 規則與代理清單改成讀取現成快照，多條連線不用排隊等全域鎖。
- UDP 少做重複工作： 不再反覆把位址轉成字串，也不再每個封包都重設 socket 計時器。
- AnyTLS 先算好： padding 規則只解析一次，傳資料時直接打包。
- 關掉的 log 真的不做： 確定不會顯示的 log，在組字串前就跳過。
- 流量統計更輕： 上下載數字直接累加，不為每次更新掃描所有連線。
IMPORTANT
這不代表 Speedtest 會快 5.4 倍。5.4 倍是「準備一個 UDP 封包」這個核心小步驟；最接近整體資料轉送的 TCP 測試約快 2%。測試用的 Ryzen 7 5825U 軟路由仍比許多家用路由器強，低階裝置的絕對速度會更低，不能直接套用。單核 25% CPU quota／512 MiB 實驗只證明優化在相同 x86 VM 的節流環境仍存在，不等於模擬 ARM、MIPS、cache 或記憶體頻寬；首頁保留較保守的未限速結果。
WARNING
「更接近 dae」不等於一定更快。實驗性 TC eBPF classifier 在一台實際 OpenWrt 路由器把同 server 測速由約 1,647 Mbps 降到 692 Mbps；推薦設定仍是 Kernel DIRECT 的 nftables backend 搭配 OpenWrt flow offload。詳見 OpenWrt 與 Nikki。
想看完整數字、三輪範圍與測試方法，可查看效能優化與基準。
從這裡開始
- 取得二進位檔：下載
- 第一次使用：建立第一份客戶端設定
- 已有 AnyTLS + REALITY 節點：AnyTLS + REALITY 設定
- 設定分流與 DNS：路由與 DNS
- 從 Mihomo 遷移：Aster 與 Mihomo 的差異
- 想查看 Aster 最近變更：更新紀錄（English）
- 想了解核心開銷：效能優化與基準
- 遇到連線問題：故障排查
欄位說明集中在設定參考，部署方式則整理在 Docker、Linux 與 OpenWrt／Nikki 頁面。