Throne for Android: a sing-box powered proxy client with a real GUI

From NekoBox for Android to Throne for Android

Throne for Android is an Android GUI proxy utility powered by sing-box, and the README's title line makes the history explicit: Throne for Android, formerly NekoBox for Android. The repository topics keep the old name too, with nekobox, nekobox-for-android and mieru among them, alongside the protocol and technology tags anytls, reality, vless, xhttp, sing-box, vpn and proxy.

The split from the core is the whole architecture. sing-box is the engine that actually implements the protocols and the routing; this project is the Android application around it, the thing with the dashboard, the tests, the widgets and the subscription management. That is why the feature list talks about a sing-box dashboard being built in and already connected to the running core, rather than about implementing a tunnel.

The language is Kotlin, the licence is GPL-3.0, and the badge states API 24 and later, so the floor is Android 7.0. The download route is the GitHub releases page, and the project home and documentation are at throneproj.github.io. Feedback goes through the issues tracker.

One migration note sits under the download instructions and is easy to miss. Version 1.7.0 is signed with a new key and starts with a fresh database, so older versions have to be uninstalled first and the subscriptions added again. That is the kind of detail that matters when a client stores credentials and server configurations locally, and it hints at the storage model the app uses: a local database, keyed to the signing identity of the installed build.

For an adopter, the name change is the visible part, but the substance is that the Android client is now trying to match what the desktop Throne application does.

The disclaimer limits what this project is

Before anything else, the README puts a notice in both Chinese and English, and the English version is unusually direct.

The project is intended solely for technical research and code learning purposes and does not provide any form of network proxy service. It must not be used for activities that violate local laws and regulations, and it must not be used in production environments. Users are fully responsible for any risks that arise from using it. If you download or reference the project, you are asked to delete all related content within 24 hours and to avoid long-term storage, distribution or dissemination of any part of it. And the author reserves the right to modify, update or remove any part of the project or its contents at any time without prior notice.

This is a legal and practical constraint, not a formality, and it should shape any evaluation.

The 24 hour deletion request and the right to remove the project without notice mean you cannot treat this as a dependency in the way you would treat a mainstream package. The prohibition on production use means there is no support commitment for a service running it. And the statement that no proxy service is provided clarifies the scope: the project distributes an application, not connectivity.

None of that makes the software worse. It describes a project whose purpose is to be read, studied and built on rather than depended upon. But for a team, the difference between a research client and a supported client is the difference between experimenting with it on a personal device and putting it on a fleet of corporate phones, and this README draws that line itself rather than leaving you to infer it.

Read the disclaimer as part of the feature set. It tells you the maintenance model, the support model and the intended lifetime of any configuration you put into the app.

Groups, subscriptions and the desktop feature set on a phone

The feature list opens with the subscription and group model, and it is where the desktop parity shows.

Groups and subscriptions work like the Throne desktop, with per-group subscription options: filters, clean-up, and a URL test after an update. So a subscription can be filtered as it arrives, stale entries can be removed, and the group can be re-tested for reachability whenever it changes rather than on a timer. There is a front and landing proxy, and HWID headers, which is the mechanism for binding a client to a device identity for servers that check it.

Scheduled updates come with change reports, so a subscription that changed overnight tells you what changed rather than silently rewriting itself.

Backups use the desktop's .thrbackup format and are restorable on either side, which means a configuration can be moved between the desktop and the phone rather than retyped. They can be saved, shared, or synced over WebDAV. The sync option is the interesting one for a phone, since it means the configuration follows the device without a manual export.

Auto selector profiles keep the best server of a group ranked and switch automatically, and route rules by Wi-Fi network, keyed on SSID or BSSID, so the routing can differ at the office and at home.

There are home screen widgets and server switching from the notification, which is a small design decision with a large effect on whether a proxy client is something you leave running or something you open deliberately. For a media or automation use, running in the background with a notification that switches servers is the difference between usable and annoying.

Tests, the embedded dashboard and the config editor

The client does not just connect, it measures and it exposes the core.

There are URL, IP or country and speed tests, with a bulk-test panel that shows live progress, a latency histogram, the fastest servers, and offers to sort, remove unavailable servers or connect to the fastest. A latency histogram rather than a single number is the right visualisation for choosing a server, because the tail is what you feel.

The sing-box dashboard is built in, with live traffic, connections and logs, and the README emphasises that it is already connected to the running core. That is the difference between a dashboard that shows you a picture of what the engine is doing and one that is actually reading it.

Xray configurations with geoip: and geosite: rules are supported, and the data files are downloaded when a configuration first needs them, rather than shipped in the app or fetched on every start.

The JSON editor does schema checking against sing-box, with completion and formatting. A schema-aware editor for a configuration format with a dozen protocol options is genuinely useful, because a typo in a key name is otherwise a silent failure at startup.

The in-app updater covers GitHub builds, on either the stable or the pre-release channel, and the README says the downloads are verified, which matters for a component that handles the traffic of a whole device.

Cloudflare WARP is also built in, with registration using either a WireGuard or a MASQUE identity, and a WARP mode for routing. That is a feature most competing clients leave to a separate application.

A long protocol list, and the XHTTP tuning knobs

The supported protocol list is the widest part of the README, and it is where a user decides whether the client can talk to their server at all.

SOCKS in versions 4, 4a and 5, HTTP and HTTPS, Shadowsocks, VMess, VLESS through both sing-box and Xray including XHTTP and REALITY, Trojan, Hysteria 1 and 2, TUIC, Juicity, AnyTLS, ShadowTLS, SSH, NaiveProxy, Mieru, Snell v4 and v6, WireGuard and AmneziaWG, TrustTunnel, MASQUE, OpenVPN, OpenConnect, proxy chaining, and custom JSON.

The XHTTP support is the newest and the most demanding, and the README ships a full example configuration for it, with the Extra TLS variant. The knobs it exposes are what make XHTTP usable in practice: the x_padding_bytes range for padding, the maximum bytes per post and the minimum interval between posts for the upload path, an xmux section with concurrency and connection counts and keep alive periods, and a TLS section with server name, ALPN and a uTLS fingerprint.

The fingerprint matters as much as the protocol. Setting the uTLS fingerprint to chrome, with the ALPN set to h2, is what makes the TLS handshake look like a browser, and the rest of the configuration is about how the transport behaves once the handshake is done.

The reason the README shows a full JSON example rather than a field reference is that this configuration format has too many interdependent fields to describe one at a time. A copyable example with a placeholder host name is more useful documentation than a table of every key, and it is the format people actually paste into the JSON editor.

Android TV support and the everyday Android surface

Two feature lines are specifically about living on a television or on a home screen rather than in a handheld session.

For Android TV there is a launcher banner, D-pad navigation, and previous and next server controls. A proxy client on a television is a plausible use, since a TV is often the device you cannot easily reconfigure, and without D-pad navigation a list of servers is unusable with a remote control.

For the phone there are home screen widgets, and server switching from the notification. The widgets are the more interesting half, because they let a user change servers or check state without opening the app, which is what makes a background proxy tolerable on a device that is also a phone.

The route rules by Wi-Fi network, keyed on SSID or BSSID, tie into the same idea. BSSID is the more precise of the two, since it identifies a specific access point rather than a network name, so two networks with the same name can be treated differently, and a venue that changes its SSID is not confused with the one you trust at home.

The practical limit of all of this is that the app is a front end. Everything it manages, from the protocols to the routing to the dashboards, is provided by the sing-box core underneath, and the app's own contribution is the interface, the subscription handling, the backups and the tests. That is a sensible division, and it also means the app's feature list is bounded by what the core supports at the version it ships with.

The build tree, and what a 2.0 release line looks like

The repository layout is a modern Android application with a couple of unusual entries.

At the root there are app/, build.gradle.kts, settings.gradle.kts, repositories.gradle.kts, gradle.properties, a buildSrc/ and a buildScript/ directory, the gradle wrapper with gradlew and gradlew.bat, and lint.xml. There is a nb4a.properties file, which is the configuration carried over from the NekoBox for Android name, and an openspec/ directory, which suggests the project now keeps its specifications alongside the code.

The .roo/ directory is also a marker of how the project is developed, since it holds the configuration for an AI coding assistant, and the tools/ directory and AUTHORS file are there as well.

The release history shows a project that has just changed its major line. v2.0.1 on 2026-10-01, v2.0.2 on 2026-10-10, and v2.0.3 on 2026-10-17, with the last push to the repository on 2026-10-19. Three releases in a fortnight, immediately after a 2.0 bump, is the pattern of a release that is settling into its new versioning rather than of a slow-moving project.

The licence is GPL-3.0, which is the one piece of the package that does not change with the disclaimer. It is a strong copyleft licence, so if you distribute a modified build of this application, the terms of the GPL apply to that distribution. For personal use on a device, it is unremarkable, and it is the same licence the rest of the open source proxy ecosystem uses.

The practical summary of this project is that it is a well-featured client with a research disclaimer, a recent rename, a fresh major version and a new signing key, which together mean that anyone upgrading from NekoBox for Android should expect to reinstall rather than upgrade in place.

Editorial conclusion

Throne for Android suits people who want the sing-box core with a full graphical client instead of a configuration file, particularly anyone moving from NekoBox for Android who wants the desktop feature set on a phone. It does not suit an organisation that needs a supported, guaranteed-stable proxy client, because the README states plainly that the project is for research and code learning, must not be used in production, and may be removed by its author at any time without notice. Check three things before you install it: that your subscription or configuration uses one of the protocols it supports, that you understand the app is not a service provider and provides no proxy service of its own, and that you have a migration plan for the 1.7.0 change, since that release was signed with a new key and starts from a fresh database. The newest release is v2.0.3 from 2026-10-17 and the last push to the repository was on 2026-10-19.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. Releases
5. throneproj/ThroneForAndroid on GitHub