# singbox-launcher puts a GUI and a fleet manager around sing-box > Leadaxe/singbox-launcher is a Go desktop client for sing-box that adds a visual configurator, subscription management, per-process traffic attribution, a local debug API and remote control of other machines over mutual TLS. It runs on two different execution engines behind one seam, and the interesting part of the design is that nothing above the seam knows which one is running. **Leadaxe/singbox-launcher** — GUI launcher for sing-box. Written in Go. - Repository: https://github.com/Leadaxe/singbox-launcher - Stars: 719 · Forks: 57 - Language: Go - License: GPL-3.0 - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/leadaxe-singbox-launcher ## The product is the surface around a proxy core, not the core The project describes itself as a desktop platform for network routing and traffic analysis, with 13 VPN protocols, configuration depth and an API at enterprise level. The execution engine is a fork, sing-box-lx, which is upstream sing-box plus the XHTTP transport and AmneziaWG 2.0, and it runs on every platform including the Windows 7 32-bit legacy build. What the launcher adds is everything around that core. The README is unusually clear that the launcher drives its own core and, over a mutually-authenticated channel, the cores of remote machines, a router or a VPS, each with its own config. So the model is not a client that talks to one server, it is a control surface that owns several cores at once. The four layers are how the product is organised. The user layer is one-button start and stop, a subscription URL turned into a working VPN flow, a server picker with ping, declarative rules via checkboxes, and a Traffic Profiler window with per-process attribution. The power layer is a Configurator with full sing-box rule semantics, covering CIDR, domain regex, process matching, sniff, and GeoIP and Geosite via SRS, with preset bundles that carry `if` and `if_or` conditions, and DNS server selection with conditional rules. The fleet layer is the Remote tab, which manages other machines running the core as a daemon, each with its own wizard profile and built config, its own Start and Stop and Deploy, its own traffic profiler and host telemetry window. The headless layer is a bearer-auth Debug API on 127.0.0.1 with around 30 local endpoints covering state read and write, action triggers, traffic capture control and a one-shot snapshot endpoint for support workflows. The project is Go, GPL-3.0 licensed, and the README carries a Go 1.25 or newer badge, with the module file requiring go 1.26.0. The last push was on 2026-10-18 and the releases are v2.4.0 from 2026-10-15, v2.3.10 from 2026-10-14 and v2.3.9 from 2026-10-13, which is a fast release cadence for a desktop application. ## Two engines behind one seam is the cleverest idea here The core engines section describes what is, in architectural terms, the most interesting decision in the project. Classic is the default and works on all platforms. It spawns and supervises `sing-box run` and talks to it over the Clash API. Daemon mode is macOS only. It drives the core inside a long-lived system service, `sing-box lxd`, over gRPC plus admin REST, the same in-process model the Android line uses. The key line is the last one of that entry. The UI, tray, shortcuts and the Debug API all go through the active engine, so nothing above the seam knows which one is running. That is a well-judged abstraction. The two engines differ enormously underneath, one is a supervised child process talking Clash API, the other is a system service with gRPC and a REST admin surface, and the difference is invisible above the seam. The daemon benefits explain why it exists. You sudo once, and the launcher prepares the install command for your own Terminal and never runs anything privileged itself, which is a good answer to the problem of a GUI that needs a service installed. The VPN keeps running after you quit the launcher, with an opt-out toggle. Config changes swap the core in place with subprocess validation and auto-rollback to the last working config. And there is richer observability, with live status, connections, core logs and a balancer pool view over gRPC. The auto-rollback is the detail that would matter most in daily use. A config change that breaks the core on a machine you are not sitting at is a bad afternoon, and swapping with validation and rollback makes that a non-event. The Go dependency list backs up the claim, with fyne.io/fyne for the UI and systray for the tray, google.golang.org/grpc and protobuf for the daemon channel, fsnotify for config watching, and pion/stun and txthinking/socks5 for the network side. There is a separate go.win7.mod and go.win7.sum for the legacy build, and app.win7.manifest beside app.manifest, so the Windows 7 target is a maintained build rather than an accident. ## Thirteen protocols, and two of them are unusual The connectivity feature list is long, and the count is 13 connection protocols: vless, vmess, trojan, shadowsocks, hysteria2, tuic, anytls, masque, ssh, socks and socks5, naive over https or quic, wireguard and AmneziaWG, plus Amnezia `vpn://` profiles. Two of them are worth a second look because they are the newer additions. XHTTP transport, where `type=xhttp` on vless, vmess and trojan nodes is parsed, generated into config.json and round-tripped back to share URIs, and the documentation notes it is no longer degraded to httpupgrade. It runs on the bundled sing-box-lx core, which matters, because the transport is the fork's reason for existing in part. AmneziaWG 2.0 is the other. The obfuscation parameters on wireguard endpoints, `jc`, `jmin`, `jmax`, `s1` to `s4`, `h1` to `h4`, plus CPS packets `i1` to `i5`, are parsed from both `wireguard://` and `awg://` URIs and emitted into `endpoints[]`. The `h1` to `h4` parameters accept AWG 2.0 randomization ranges in `lo-hi` form, and the core picks a fresh in-range value on every handshake, which requires core version `1.14.0-lx.1-rc.17` or newer. The AWG endpoint MTU is auto-clamped to 1280. That last detail, the MTU clamp, is a good sign. Obfuscation parameters that vary per handshake are useless if the packet size assumption breaks, so the driver constrains it. The Tailscale integration is a third unusual piece. The launcher joins your tailnet as a node, and Add server then Tailscale builds a `tailscale` endpoint from an auth key, control URL, hostname, ephemeral flag, accept routes and exit node setting. The node runs inside the core, so the Tailscale app is not needed, and the auth key is one-off, consumed at first login, after which the node identity lives in the node's state directory under `bin/tailscale/`, named after the tag. It requires a core built with `with_tailscale`, version `1.14.0-lx.31` or newer, and on an older core such a node is dropped with a warning in the build report rather than failing the whole config, which is the right failure mode. ## Subscription compatibility is treated as a protocol, not a list of providers The connectivity section contains a cluster of features that only make sense for people running a subscription panel, and they are the most practically important details in the list for that audience. Multiple sources per profile is the first. Subscription URLs and direct links, `vless://`, `vmess://` and so on, can be mixed in a single configuration, so you are not forced to choose between a panel and a hand-configured node. Subscription provider compatibility is stated as first-class support for HWID-binding panels, naming Marzban, Marzneshin, Remnawave, NashVPN and V2Board or Xboard, implemented through the canonical XTLS subscription-header protocol with `X-Hwid`, `X-Hwid-Limit`, `Announce` and `Subscription-Userinfo`. The important thing is the word canonical. The launcher speaks the headers rather than special-casing each panel, so a panel that implements the protocol works without a code change. The per-source raw cache is a small feature with a large effect. The last working subscription body is preserved on fetch failure, so a provider having a bad afternoon does not leave you with a broken config. Combined with the provider-neutral header support, that is what makes the tool usable as the front end for a subscription service rather than a one-off client. Then there is the TUN inbound, the system-wide VPN driver on Windows, macOS and Linux, with `auto-route`, `auto-redirect` and `find_process` enabled by default. `find_process` is the reason the per-process attribution in the Traffic Profiler can work at all, since the core needs to know which process a connection belongs to. The Amnezia import completes the picture. You can paste an Amnezia `vpn://` link, which is the content of the .vpn file, or the raw `[Interface]` and `[Peer]` text of a WireGuard or AmneziaWG .conf file straight into Sources, and the launcher decodes the profile or detects the conf blocks and imports them as regular WG or AWG endpoints. ## Remote machines pair with a one-time invite The remote machines feature is what separates this from a desktop proxy client, so it is worth looking at the mechanics. You pair a router, a VPS or another Mac over mutual TLS with a one-time invite, and the format of the invite is given explicitly as `address#fingerprint#code`. Each machine gets its own registry entry with a name and platform, and its own config. The channel is mutually authenticated, which matters because you are shipping configuration that controls how traffic leaves a machine. The Tailscale work extends this model rather than sitting beside it. A preset called Tailscale networks serves every Tailscale node in the config, subscription nodes included, and tailnet addresses go through the node while tailnet names are resolved by the node's own MagicDNS. A node is excluded with a Skip presets switch. The exit node model is also split. A node with `exit_node` set is an ordinary exit and can be picked in a Direction, while a node without it gives access to the tailnet only. A NETWORKS item, the last item of the group list on the Servers tab, lists the nodes without an exit and shows their state, starting, running, sign-in needed or stopped. The Network tab of the node window handles state, sign in and log out, the devices of the tailnet, the exit node choice with a Save choice button that writes into your own node, and the ping of a device with the path, direct or relay. And the local and remote cases differ. The NETWORKS commands work with the local daemon engine on macOS and with a connected Remote machine, where Save choice writes into that machine's own node and rebuilds its config, sent with Deploy config. The local classic engine has neither. The Go dependency list tells you where the effort went. The GUI is fyne.io/fyne with the systray package for the tray icon, a fyne-tooltip helper and a go-pretty-view integration, and fsnotify for watching the config directory. The networking side pulls in pion/stun for STUN and txthinking/socks5 for the local proxy, and godbus for Linux D-Bus. The remaining entries are indirect dependencies of the fyne stack, which pulls in OpenGL bindings, text rendering and typesetting libraries, and the go-i18n stack for the interface translations. ## Conclusion Adopt singbox-launcher if you run sing-box on more than one machine and want a single interface that can configure a laptop, a router and a VPS at once, since the remote layer is the part no other client offers. Skip it if you want a minimal command line tool, since this is a full desktop application with a tray, a wizard and a profiler, and skip it if you need a mainstream proxy protocol, because the 13 supported protocols are the sing-box set rather than the common ones. Verify first that you are comfortable with a custom sing-box fork as the execution engine, that your core is new enough for the features you want such as Tailscale requiring a specific build, and that the platform you want has a working daemon engine, since the long-lived service mode is described as macOS only. ## FAQ ### What does singbox-launcher add on top of sing-box? It adds a visual configurator with full sing-box rule semantics, multi-subscription management, per-server switching with ping, a Traffic Profiler with per-process attribution, declarative routing with preset bundles, a local bearer-auth Debug API with around 30 endpoints, and a Remote tab for driving the cores of other machines over mutual TLS. ### What is the difference between the classic and daemon core engines? Classic, the default on all platforms, spawns and supervises `sing-box run` and talks to it over the Clash API. Daemon mode, macOS only, drives the core inside a long-lived system service, `sing-box lxd`, over gRPC plus admin REST. The UI, tray, shortcuts and Debug API all go through the active engine, so nothing above the seam knows which one is running. ### How are remote machines added to singbox-launcher? You pair a router, VPS or another Mac over mutual TLS with a one-time invite in the form `address#fingerprint#code`. Each machine then gets its own registry entry, its own wizard profile and built config, its own Start, Stop and Deploy actions, and its own traffic profiler and host telemetry window. ## Sources - [Issues](https://github.com/Leadaxe/singbox-launcher/issues) - [Leadaxe/singbox-launcher on GitHub](https://github.com/Leadaxe/singbox-launcher) - [License: GPL-3.0](https://github.com/Leadaxe/singbox-launcher/blob/main/LICENSE) - [README](https://github.com/Leadaxe/singbox-launcher/blob/main/README.md) - [Releases](https://github.com/Leadaxe/singbox-launcher/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/leadaxe-singbox-launcher