LxBox puts every Android proxy protocol inside a single VpnService

Android's single VPN slot is the constraint the app is built around

Start with the platform, because that is the problem LxBox solves. Android allows only one active VpnService, so a VLESS client, the Cloudflare WARP app and the Tailscale app cannot run together. Whichever starts last takes the tunnel, and the other two go dark.

LxBox resolves that by running everything inside one core. The README lists VLESS with REALITY, XHTTP and post-quantum ML-KEM-768, VMess, Trojan, Shadowsocks, Hysteria2, TUIC v5, AnyTLS, NaïveProxy, WireGuard, AmneziaWG, Cloudflare WARP and Tailscale, all in one app in a single VpnService, with routing rules deciding what goes where. The practical effect is that protocols which would normally fight over the one slot coexist, and a user does not have to choose between a working proxy and a working tailnet.

The client is written in Dart with a Flutter interface, and the interface is where most of the weight sits. The README describes multi-subscription management, rule-based routing, per-app split tunneling, full DNS control, detour chains and load balancing, along with no ads, no telemetry and no account, and an interface in English and Russian.

The application is also careful about the two things that make Android proxy apps unpleasant in daily use. The core suspends unreachable tunnels instead of retrying them in a loop, and subscription auto-update is gated against request spam. Both are battery decisions rather than features, and both matter more over months of daily use than the protocol list does.

The core is a fork, and the fork is where the differences live

L×Box ships its own core, sing-box-lx, described as a sing-box fork with AmneziaWG 2.0, native XHTTP and a MASQUE outbound. The README's comparison with the SagerNet reference client for Android, SFA, is explicit that SFA is the project where you hand it raw JSON, while LxBox provides a full interface for subscriptions, nodes, routing, DNS and diagnostics and ships the forked core that adds AmneziaWG 2.0, native XHTTP, a MASQUE outbound, a round-robin load balancer and idle-suspend. Raw JSON still works, because there is a config editor and config pinning.

That last point is what keeps this usable for people who already know the ecosystem. The interface is optional. If you have a working sing-box configuration, you can paste it in, pin it, and let the app run it, and the fork does not take that away from you.

The fork also means the app is not a thin wrapper. Anything the upstream client does not carry on the client side is something LxBox had to implement itself, and the README names three: Xray's XHTTP transport, AmneziaWG 2.0, and post-quantum VLESS using the mlkem768x25519plus key combination. That is the trade you accept by using a fork: you get transports the reference client does not have, and you take on the cost of tracking a fork that is not upstream.

Distribution follows the usual Android channels: release APKs on GitHub, an F-Droid listing under the package id com.leadaxe.lxbox, and a Google Play listing with the same id.

Chains and detours are two ways to express a multi-hop route

The routing model is where the app goes beyond running protocols side by side. Traffic can be sent out through your own VLESS server and then through Cloudflare WARP, so the destination site never sees your server address.

The README gives that arrangement two forms, and the distinction is worth understanding before you build anything. A chain is an explicit multi-hop route you assemble in the interface, where you say hop by hop what the path is. A detour is a single node set to go through another, so one endpoint is defined in terms of another.

Both forms are validated before the configuration is built, and the validation includes a cycle detector, so a detour that loops back on itself is refused rather than producing a configuration that hangs. The README also mentions per-hop latency diagnostics, which tells you which link in a chain is the slow one rather than only reporting that the whole route is slow.

The Tailscale side works the same way inside the core. A tailscale endpoint runs inside the app, with MagicDNS, exit nodes and device ping, so a phone can join a tailnet without the Tailscale application installed. Since it shares the core with the proxy outbounds, a route can be defined over both, which is exactly the case the single VpnService limit used to make impossible.

Subscription handling includes dedupe, rewrite rules and anti-spam gates

Most people running a proxy client maintain a list of servers that arrives as a subscription rather than as hand-typed nodes. LxBox treats that as a first-class workflow.

The README lists imports by URL, file, QR code or pasted link, with deduplication of nodes, the ability to disable individual servers, the ability to rewrite them with filter rules, and auto-update on six triggers with anti-spam gates. The set of link formats the node import accepts is long: VLESS, VMess, Trojan, Shadowsocks, Hysteria2, TUIC, AnyTLS, NaïveProxy, SSH, SOCKS, HTTP, WireGuard, AmneziaWG, MASQUE, Tailscale, plus Xray and sing-box JSON configurations.

The rewrite rules are the part that goes beyond simple importing. A subscription can contain nodes you do not want to see or cannot use, and filter rules let you strip or change them rather than scrolling past them on every update. Disable is the blunt version, filtering is the programmable version.

The auto-update triggers and the anti-spam gates are a specific answer to a specific failure mode. A subscription host that rate limits or blocks repeated automated fetches can lock you out of your own server list, and an update that fires on several triggers at once makes that more likely. The gates slow the update cycle down. The README also points at a public servers registry as a separate document, so there is a maintained list of subscription sources alongside the importer.

DPI countermeasures are configured per node, not globally

The README frames the project as a professional tool for network security, routing and network health checks, and states that use must comply with the law of the country where the tool is used. Against blocking, the feature set is listed per node.

REALITY and XHTTP are the transport options, along with TLS fragmentation, ECH, uTLS fingerprints, AmneziaWG 1.x and 2.0 obfuscation, and MASQUE over QUIC. The post-quantum option, ML-KEM-768 for VLESS, sits alongside the classical key exchange as one of the choices rather than as a separate product.

The per-node framing is the design decision that matters. Each server in your list can carry its own transport, fingerprint and obfuscation settings, so a list that mixes a REALITY server and a plain Shadowsocks server does not force one global setting on both. The README also names a built-in speed test and live statistics screens, which give you the measurements to decide which node deserves which setting.

Cloudflare WARP is handled inside the same app rather than by handing you off to another one. A single tap on Get WARP registers an account and generates the WireGuard or MASQUE keys on the device, the private key never leaves the phone, and WARP+ license keys are supported.

How the app differs from SFA, Hiddify, NekoBox and Karing

The README answers the comparison question directly, and the differences are worth reading in that form.

Against SFA, the reference client from the SagerNet team, the difference is the interface. SFA takes raw JSON, while LxBox provides screens for subscriptions, nodes, routing, DNS and diagnostics, and it ships the forked core with the extra transports and the round-robin load balancer and idle-suspend behaviour. Raw JSON configuration still works in LxBox through the config editor and config pinning.

Against Hiddify, NekoBox and Karing, the difference is underneath. Those are interfaces over the stock sing-box or mihomo core, so anything the stock core lacks on the client side is missing for their users too. LxBox ships its own fork, which is what makes XHTTP, AmneziaWG 2.0 and post-quantum VLESS available to it.

The alternative approach, then, is running a stock-core client and accepting the transport ceiling, or running a stock client alongside separate WARP and Tailscale applications and living with the one VpnService rule. Both work. The first is simpler and less capable, the second keeps your clients independent but forces you to choose which tunnel is live.

The documentation is organised as black-box feature specs

The unusual part of this repository is how it is documented. Every capability is described as a black-box specification in the feature catalogue under docs/spec/features, with each spec stating what it promises the user, what it takes and gives, and where it stops. The README says to start there for precise behaviour and treats its own sections as a tour.

The naming gives a sense of the coverage. There is a spec for subscriptions covering file and pasted sources, auto-update and per-node disable, and another for node import listing the share link formats and configuration types the app accepts. The rest of the catalogue follows the same pattern, with the feature table in the README pointing each area at its own directory and FEATURE.md file.

Around the code, the repository is organised as an application, a tool directory, scripts, fastlane metadata for store releases, and a set of public documentation files including a Russian readme, a changelog, release notes, a security policy and a licensing document. That last file is worth reading alongside the licence. The project is GPL-3.0, and the README states plainly that it is free and open source under that licence with no ads, no trackers, no analytics and no account required. If you intend to build on the code or redistribute a modified build, the copyleft obligations travel with it, which is a description of the terms rather than legal advice.

Maintenance is active by any measure available in the facts. The last push was on 2026-10-19 and the release v2.25.16 was published the same day, after v2.25.16-rc.1 on 2026-10-16 and v2.25.15 on 2026-10-14.

Editorial conclusion

Adopt LxBox if you are on Android and need a proxy protocol, Cloudflare WARP and a tailnet at the same time, because the single VpnService slot is a hard platform limit that separate apps cannot satisfy. Do not adopt it if you want a stock sing-box configuration, a client outside the fork, or a codebase you intend to ship inside a proprietary product without preparing for the GPL-3.0 obligations. Verify first by installing the release APK from GitHub and checking that the node types you actually use import correctly through the subscription and share link screens, since the fork adds transports the upstream core does not carry on the client side.

Frequently asked questions

Official sources

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