MikuBox for Android: a Mihomo-powered proxy client with a themed UI
MikuBox is based NekoBox with Miku UI and theme custom
At a glance
- What is it?
- MikuBox for Android is a Kotlin proxy client built on the Mihomo core, reaching it through a JNI bridge while Android owns the VPN TUN interface. It is a fork of NekoBox with a reworked interface and theme, and it ships light and night themes plus Clash configuration support.
- Who is it for?
- MikuBox suits an Android user who wants a Clash configuration, including policy groups and routing rules, honoured by a maintained proxy core while keeping a themed interface, and it is the practical choice over a bare core because the app handles the TUN plumbing. It does not suit anyone who needs a protocol outside what the bundled Mihomo commit supports.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 101 days ago.
- What is it written in?
- Mainly Kotlin, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 25, 2026, and from our analysis. They are not legal advice.
Editorial analysis
What MikuBox is and where it sits
MikuBox for Android is described as an Android universal proxy toolchain powered by Mihomo. The repository description says it is based on NekoBox with a Miku interface and theme customisation, and the README credits the Android UI work to the MikuRay project, to the shadowsocks-android project and to v2rayNG.
The technical base is the Mihomo core, and the README is specific about which one. MikuBox embeds the HSSkyBoy fork of Mihomo through a JNI bridge, and it links the Alpha branch of that fork. The credits list MetaCubeX's own mihomo separately as the second core entry, which reflects the lineage of the project rather than two cores running at once.
The division of labour is the interesting part. Android owns the VPN TUN interface, and Mihomo receives the file descriptor and parses the complete YAML configuration. That is the arrangement that lets a native Android application run a full Clash core, and it is why the app is a thin shell around a Go binary rather than a reimplementation of the protocol stack in Kotlin.
The project describes itself as a universal proxy toolchain, and the topic list backs that up: clash-meta, mihomo, sing-box, v2ray, xray, proxy, vpn and user-interface all appear. The homepage given for the project is mikuexpo.com, and the default branch is named Miku rather than main.
Two sibling projects exist in the same ecosystem, since the README refers to a sing-box edition. The distinction is important and is spelled out in the subscription section: the Clash edition keeps the whole configuration, while the sing-box edition only resolved nodes.
The protocol list and what the bundled core actually supports
The README groups the protocols into four tiers, and the grouping is a good guide to what each tier means in practice.
The standard tier covers SOCKS5, HTTP or HTTPS, and SSH. The established tier adds Shadowsocks, ShadowsocksR, VMess, VLESS and Trojan. The advanced tier covers AnyTLS, ShadowTLS as a Shadowsocks or Snell plugin, TUIC, Hysteria 1 and 2, WireGuard, Snell and Mieru. The policy groups tier covers select, url-test, fallback and load-balance, which are the grouping constructs rather than transports.
The README also states the limits precisely, and these are the parts that trip people up. Protocol support tracks the bundled HSSkyBoy Mihomo Alpha commit recorded in the Git submodule, so the feature set is whatever that commit contains rather than whatever upstream Mihomo has added since. ShadowTLS is available as a Shadowsocks or Snell transport or plugin, not as its own type with a shadowtls proxy node, so a configuration written for a different core has to be adjusted.
The second limit is a removal rather than an addition. The Alpha branch has removed the legacy relay proxy-group, and the README says to use a node's dialer-proxy option for chaining instead. That is a breaking change for an existing configuration, and the alternative it points to is the more expressive mechanism anyway, since dialer-proxy chains at the node level rather than at the group level.
The upshot is that a MikuBox user is running a specific commit of a specific fork of Mihomo, and the configuration has to be written for it.
Configuration and subscription handling
MikuBox natively consumes Mihomo, or Clash, configuration, with nodes, policy groups and rules included. The import options are a subscription URL or a local configuration file, so both a remote provider and a hand-maintained YAML work.
The README makes a point that distinguishes this edition from its sibling. Unlike the sing-box edition, which only resolved nodes, the Clash edition keeps the whole config, and proxy-groups and routing rules are honoured. The app only overrides a few fields, which it names as TUN, DNS and controller.
That is a narrow and sensible override list. The TUN field has to be overridden because the app is the one creating the VPN interface, the DNS settings have to match what the app configures for the tunnel, and the controller address has to point at the local core instance. Everything else, the proxies, the groups and the rules, is passed through untouched, so a configuration that works in a desktop Clash client works here.
The practical consequence is that the difficulty moves. A Clash configuration is powerful, and power in a routing system means that a misconfigured rule can send traffic somewhere unexpected, and the app is not going to stop that because the whole point of honouring the rules is that it does not second-guess them.
The interface, the themes and the build setup
The README leads with a banner and then a long screenshot section, which tells you the visual work is the point of the fork. There is a light theme, labelled both in English and in Chinese, and a night theme, with five screenshots each.
The underlying UI work is credited to MikuRay, to shadowsocks-android and to v2rayNG, and the web dashboard is credited to Yacd-meta, the MetaCubeX dashboard for Clash Meta. So the interface is not entirely new code, it is a retheme and rearrangement of an existing Android proxy interface, and the dashboard is the same one Clash users already know.
The repository layout is a standard multi-module Android project. There is an app/ directory and a core/ directory, a build.gradle.kts at the root with settings.gradle.kts beside it, a gradle.properties, the Gradle wrapper with gradlew and gradlew.bat, a .gitmodules file, and a .github/ directory. The core/ directory is where the JNI bridge to the Mihomo binary lives, and the .gitmodules file is what records the exact Mihomo commit, which is the same fact the README warns you about.
The build is a normal Gradle Kotlin DSL project with the wrapper committed, so a checkout builds with the gradlew script. The application targets Android API 24 and above, according to the badge in the README, which is Android 7.0. The Apache-2.0 licence is the one declared on the project, and the file is at the root of the repository.
Where MikuBox is the wrong choice
The first limitation is the coupling to a forked core on a branch that is explicitly Alpha. Protocol support follows the bundled commit rather than upstream Mihomo, and the branch has already removed a feature that existing configurations may use. A user who keeps a long-lived configuration will hit the drift, and the fix is to rewrite the configuration rather than to wait for a merge.
The second is the platform. Android owns the TUN interface, and that is where most of the friction of a mobile proxy lives, since the operating system can reclaim the tunnel, and battery management can kill the process. The README says nothing about how MikuBox handles either, so a user who has fought a similar fight on another client should expect to fight it here.
The third is the scope of the app itself. It is a themed shell around a core, and the themes are the visible differentiator. If you do not care about the interface, a client that exposes the same Mihomo core with a plainer interface does the same work, and the choice between them is a matter of taste rather than capability.
The fourth is the absence of documentation in the repository. The README covers protocols, configuration and the theme gallery, and then points outward, with a Telegram channel, a Chinese channel and a homepage. There is no install walkthrough, no configuration walkthrough and no troubleshooting section here, so the practical work of setting the app up happens outside the repository.
The fifth is that the Alpha branch's ShadowTLS limitation will bite a user with a config from elsewhere. A node declared as its own ShadowTLS type does not work, and the fix is to express it as a Shadowsocks or Snell plugin, which is a small change but one that has to be made before anything runs.
Licence, maintenance and the cost of the themed fork route
The project is under the Apache-2.0 licence, with the LICENSE file at the root of the repository and the licence stated on the project page. A permissive licence on the app does not change the terms of the components it bundles, and the credits section is the place to check those: Mihomo, the Android UI projects and the Yacd-meta dashboard each carry their own licences.
The repository is not archived and the last push was on 2026-07-16, so the fork is being worked on, though the release history is slower than that suggests. The listed releases are 1.4.3-UwU-2 in February 2026, 1.4.3-UwU-1 in January 2026 and 1.4.3-UwU in December 2025, and the version naming carries the UwU suffix throughout, which is a fork's way of keeping its own line distinct from the NekoBox version it started from.
That gap between the last commit and the last release is the operational fact worth planning around. A fork of a fast-moving core that ships on its own schedule means the bundled Mihomo commit can lag behind the upstream Alpha branch, and the protocol support the README describes is the support as of the bundled commit, not as of today.
The cost of running it is low in resources and higher in attention. The app is a normal Android application, and the core is a Go binary shipped inside it, so there is no separate service to run. The attention cost is the configuration maintenance that comes with honouring a full Clash config on a device where a misrouted rule is easy to miss, and the periodic work of rewriting configurations when the Alpha branch changes shape again.
Editorial conclusion
MikuBox suits an Android user who wants a Clash configuration, including policy groups and routing rules, honoured by a maintained proxy core while keeping a themed interface, and it is the practical choice over a bare core because the app handles the TUN plumbing. It does not suit anyone who needs a protocol outside what the bundled Mihomo commit supports. Verify the core version first, since the Alpha branch has removed the legacy relay proxy group and ShadowTLS only works as a transport, then import a subscription URL or a local YAML file.
Frequently asked questions
What is MikuBox for Android built on?
It embeds the HSSkyBoy fork of Mihomo through a JNI bridge, with Android owning the VPN TUN interface and Mihomo receiving the file descriptor and parsing the YAML configuration. The app itself is based on NekoBox, with a reworked interface and theme.
Which protocols does MikuBox support?
The README groups them into standard, covering SOCKS5, HTTP(S) and SSH, established, covering Shadowsocks, ShadowsocksR, VMess, VLESS and Trojan, advanced, covering AnyTLS, ShadowTLS, TUIC, Hysteria 1 and 2, WireGuard, Snell and Mieru, plus the policy groups select, url-test, fallback and load-balance. Support tracks the bundled Mihomo Alpha commit.
Does MikuBox honour proxy groups and routing rules?
Yes. The Clash edition keeps the whole configuration, so proxy-groups and routing rules are honoured, unlike the sing-box edition which only resolved nodes. The app overrides only a few fields, namely TUN, DNS and the controller.
How do I add a subscription or configuration to MikuBox?
The README lists two import routes, a subscription URL or a local configuration file, in Mihomo or ClashMeta YAML format. It also notes that the Alpha branch has removed the legacy relay proxy-group, so chaining should use a node's dialer-proxy option instead.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/hatsunemikuuwu-mikuboxforandroid)Was this useful?