sing-box is a universal proxy platform that runs as a client or server on desktops, servers, and mobile devices. It combines many proxy protocols, rule-based routing, and DNS control in one configurable engine.
sing-box is an open proxy platform that runs as both a client and a server, handling inbound and outbound traffic through a single configuration file. Instead of locking you to one protocol, it speaks Shadowsocks, VMess, VLESS, Trojan, Hysteria, TUIC, WireGuard, SSH, and more from the same engine. You define listeners, outbound endpoints, and routing rules, then let sing-box decide which connection path each request should take based on domain, IP, port, process, or sniffed protocol. A built-in TUN inbound can capture system-wide traffic for transparent proxying on desktop and mobile, while remote rule sets keep routing logic current without editing the config by hand.
Most people start with a desktop build, import a subscription link or a hand-written JSON profile, and switch it on. If you previously configured a classic client such as shadowsocks-windows, the syntax will feel different but the goal is the same: keep the traffic path stable and predictable. sing-box scales beyond that beginner stage because the same profile can be exported to phones, routers, or a headless Linux box, and the graphical clients for Android, Apple platforms, and desktop share the same core. Logs, connection statistics, Clash-compatible API endpoints, and a V2Ray statistics API make troubleshooting far easier than reading raw socket dumps.
sing-box earns its place by making one tool do the work of several. You get a single config format for client and server duties, so a rule you test locally can be reused on a VPS without rewriting anything. Protocol support is broad and current, covering modern transports like VLESS with Reality, Hysteria 2, TUIC, AnyTLS, ShadowTLS, and Snell alongside older standbys, which means migration between servers rarely forces a new client. Routing is the real strength: split traffic by domain, geo data, process name, Wi-Fi state, or protocol sniffing, send specific apps through specific exits, and keep DNS honest with FakeIP, per-server policies, and DoH, DoT, or QUIC resolvers. Remote rule sets and subscriptions keep everything updated through URLs rather than manual edits. The engine also runs lean as a service on routers and small servers, with a JSON schema for validation, plenty of logging, and stable APIs for dashboards. If you want one engine instead of a folder of utilities, sing-box is a strong choice.
Configure Shadowsocks, VMess, VLESS, Trojan, Hysteria, Hysteria 2, TUIC, ShadowTLS, AnyTLS, Snell, SOCKS, HTTP, WireGuard, SSH, and Tor endpoints from one profile. Because inbound listeners and outbound dialers share the same schema, you can accept traffic in one protocol and forward it through another, which is what makes local gateways and protocol bridges practical.
Route every connection by domain, domain suffix, keyword, regex, IP CIDR, GeoIP country, geosite category, port, network type, process or package name, and sniffed protocol. Rules run in order, and each can carry an action such as route, reject, hijack DNS, or resolve, giving you precise control over which apps use which exit without touching the application itself.
The TUN inbound creates a virtual network interface so applications that ignore proxy settings still travel through your rules, including games, terminals, and services without SOCKS support. Combined with auto-route and auto-redirect options, it delivers system-wide capture on desktop and mobile, while interface auto-detection helps avoid routing loops.
sing-box DNS servers accept UDP, TCP, DoH, DoT, QUIC, HTTP3, DHCP, or mDNS, and rules decide which resolver answers which query. FakeIP returns synthetic addresses so domain-based routing can happen earlier, while a hosts-style local mapping and DNS hijacking keep lookups from leaking outside the tunnel. That accuracy matters when split routing depends on the resolved name.
Import remote profiles through subscription URLs and pull routing, DNS, and rule-set data from remote sources that refresh on a schedule. AdGuard, Clash, and standard source formats are understood, so large community blocklists and geosite collections can be reused as-is. Updates land without manually editing JSON, which keeps long-running deployments consistent.
Expose a Clash-compatible control API plus a V2Ray statistics interface so existing dashboards, traffic meters, and connection viewers keep working. You can inspect active connections, read per-outbound traffic counters, switch selectors, and run latency tests from remote tooling. The cache file also preserves selector choices across restarts.
The same program that dials out through a proxy can also accept inbound connections and serve them, so a spare VPS becomes a working endpoint without installing a separate daemon. Server-side support covers the major proxy protocols, TLS and certificate provisioning including ACME, and shared transport options, which keeps the client and server configs symmetric and easier to reason about.
Group several servers behind a selector outbound so you can switch exits on demand, or behind a URLTest outbound that measures latency and automatically prefers the fastest reachable node. Health checks, fallback behavior, and per-group routing keep a broken server from taking the whole connection path down, which is useful when you rotate between multiple endpoints.
It is a proxy engine that routes traffic between your device and remote servers. You can run it as a client to send selected apps through a proxy, or as a server to provide that proxy. Typical uses include split-tunneling work and personal traffic, building a self-hosted proxy on a VPS, and experimenting with newer proxy protocols behind a single config format.
It is better described as a universal proxy platform. It speaks several proxy protocols and can run in TUN mode, where it captures traffic system-wide and behaves much like a VPN from the user's point of view. The difference is that it is not tied to one tunnel technology and lets you split traffic by rule rather than sending everything through a single tunnel.
Common options include Shadowsocks, VMess, VLESS, Trojan, Hysteria and Hysteria 2, TUIC, ShadowTLS, AnyTLS, Snell, SOCKS, HTTP, WireGuard, SSH, and Tor. Both inbound and outbound sides are covered, so it can also translate between protocols rather than only speaking one on each end.
Not necessarily. Graphical clients for Android, Apple platforms, and desktop provide import options for subscription links and local profiles, plus toggles for common settings. Hand-editing JSON remains the most flexible route for advanced routing, DNS, and rule-set work, and a published schema helps editors validate a sing-box profile before you run it.
Yes. Routing rules can match on process or package name, domain, GeoIP or geosite data, port, Wi-Fi state, and sniffed protocol, and each rule sends matching traffic to a chosen outbound. That makes setups like local direct traffic plus a proxy for specific services straightforward, provided your platform exposes the process information the rules need.
sing-box runs as a background service on Linux, including routers and small VPS instances, and works without a graphical interface. Configuration is read from a file, logging can go to stdout or a file, and remote APIs let dashboards control it, so headless deployments are a normal part of the platform.
It depends on the client. The Android, Apple, and desktop graphical apps hide most complexity behind imports and toggles, so casual use is realistic. The engine itself, however, expects a clear mental model of inbounds, outbounds, and routes, and most troubleshooting involves reading config and logs, so expect a learning curve if you write profiles yourself.
Comments