sing-box is a configurable proxy platform that runs as a single binary, accepting traffic through inbounds, matching it against routing rules, and forwarding it through outbounds that can speak dozens of protocols.
sing-box is a universal proxy platform that handles the whole path of a connection inside one program. Inbounds accept traffic from the system or from other devices, the router evaluates rules against each connection, and outbounds forward it using whichever protocol you configured. Because every stage is configurable, the same program can act as a local client, a remote server, or a transparent gateway. The documentation covers each stage in depth, from DNS behaviour to transport settings, so tuning an existing setup is a matter of editing rules rather than swapping applications.
Compared with engines that grew from a single lineage, sing-box was written from scratch around the inbound-router-outbound model, and that shows in how configuration is organised. Rule sets can live in separate files and be loaded from a URL, so a shared blocklist or allowlist can be updated without touching the main configuration. DNS is treated as a first-class subsystem with its own servers and rules, including fake IP allocation for faster domain routing. Anyone who prefers a smaller, protocol-focused core with its own original protocols should also look at Xray-core, which takes a different approach to the same problem.
The practical benefit of sing-box is breadth without fragmentation. One deployment can serve Shadowsocks, Trojan, VLESS, Hysteria2, TUIC, and WireGuard connections at the same time, and endpoints extend that list to Tailscale, OpenConnect, and OpenVPN, so a migration does not require running two or three separate daemons. Routing is granular enough to split traffic by domain, address, process, or sniffed protocol, and selector and URL test outbounds let you keep a list of servers with automatic health checks instead of editing the configuration by hand. Rule sets loaded from files or URLs keep long blocklists out of the main file. The Clash-compatible and native APIs mean existing dashboards and automation keep working, which matters once more than one person administers the setup.
Key capabilities and highlights.
Every connection follows the same three stages, which makes configuration predictable: an inbound receives it, the router picks an outbound using your rules, and the outbound sends it onward. Understanding that path is enough to reason about almost any setup.
Outbounds and inbounds cover SOCKS, HTTP, Shadowsocks, VMess, Trojan, VLESS, Hysteria2, TUIC, ShadowTLS, AnyTLS, Snell, and WireGuard, among others, so a single binary can talk to nearly any server you already have instead of forcing a migration.
Group routing and DNS rules into separate rule sets that can be loaded from the local disk or a remote URL, including AdGuard filter lists and headless rule formats. Shared blocklists stay current without editing the main configuration file.
Define several DNS servers using different transports, match queries with DNS rules, and hand out fake IP addresses so routing decisions can be made before a real lookup happens. That keeps name resolution consistent with the routing policy instead of fighting it.
Selector outbounds group several servers so you can switch manually, while URL test outbounds probe them and pick the fastest or most reliable one automatically. Long server lists become manageable without editing addresses by hand.
WireGuard, Tailscale, OpenConnect, and OpenVPN endpoints are configured in sing-box alongside proxy outbounds, so private networks and commercial tunnels live in the same routing table. Traffic can move between them using the same rules that govern everything else.
TUN, redirect, and TProxy inbounds let the program capture traffic without per-application settings, which is how routers and shared gateways run it. Desktop users get the same behaviour through the graphical clients that wrap the core.
A Clash-compatible controller and a native API expose connection state, traffic statistics, and runtime control, which is what third-party dashboards and monitoring scripts connect to. Managing many nodes or users becomes scriptable rather than manual.
Browse historical releases and previous builds.
Common questions about sing-box.
It proxies network traffic according to rules you write. Typical uses are a desktop client that tunnels selected applications, a server that accepts connections from your devices, and a router or gateway that captures traffic for an entire network and routes it by policy.
It needs something to connect to when you use it as a client, but it can also run as the server that accepts those connections. Because inbound and outbound roles are both configurable, one installation can terminate connections from other devices while dialling out to a remote endpoint.
Through a JSON configuration file that describes DNS, inbounds, outbounds, route rules, and rule sets. The command-line program validates the file before starting, and the documentation describes every field, so a configuration can be reviewed, versioned, and reproduced across machines.
Yes. Inbounds and outbounds are defined independently, so a single instance can accept Shadowsocks, Trojan, VLESS, or Hysteria2 connections while dialling out through WireGuard or a different protocol. That makes gradual migrations practical, since old and new clients can be served from the same deployment.
They are standalone collections of routing or DNS rules that the main configuration references instead of embedding. A rule set can load from a local file or a URL, and formats such as AdGuard filters and headless rules are supported, so a large blocklist can be refreshed without editing the core configuration.
No, the sing-box core is a command-line program configured with a file. Separate desktop and mobile graphical clients wrap it for people who prefer a window, and they handle tasks such as importing a profile, toggling the connection, and reading traffic statistics.
Yes. sing-box rules can match on address, port, process name, sniffed protocol, and other fields, and they can also be grouped into rule sets. That makes it possible to send one application through a specific server while everything else follows a default path.
DNS is configured separately from routing, with its own servers and rules. You can mix transports such as encrypted lookups, define static mappings, or use fake IP allocation so that routing decisions happen before a real lookup, keeping resolution consistent with the tunnel policy.
sing-box is a configurable proxy platform that runs as a single binary, accepting traffic through inbounds, matching it against routing rules, and forwarding it through outbounds that can speak dozens of protocols.
v2rayN is a desktop GUI that drives Xray, sing-box, and other proxy cores, letting you import subscriptions, test server latency, choose routing rules, and enable system proxy or TUN mode from one window.
Pritunl Client is a VPN client that connects computers to OpenVPN and WireGuard servers, giving administrators and remote workers one interface for importing profiles, switching organizations, and keeping encrypted tunnels reliably connected.
Clash Verge Rev is a desktop GUI for the Mihomo rule-based proxy core, letting you import subscription profiles, switch nodes, edit rules visually, and route traffic through system proxy or TUN mode.
Surfshark is a VPN service that encrypts internet traffic, masks the user’s public IP address, and combines selective routing, tracker blocking, multi-server connections, and automatic protection for everyday privacy.
Comments