Affiliate disclosure - This article contains a Contabo affiliate link. If you order a VPS via our link, we earn a commission at no extra cost to you. The comparison below reflects the documented features of each project. Check the exact config syntax against each tool's official docs, since it changes between versions.
Short answer: want a focused, proven VLESS + REALITY anti-censorship setup with the largest pool of guides? Choose Xray. Want one binary that is both client and server and also speaks new QUIC protocols (Hysteria2, TUIC)? It also adds Shadowsocks, VMess, VLESS, Trojan and WireGuard, so choose sing-box. Both support REALITY. The real choice is a focused tool vs an all-in-one toolkit. New to these protocols? Start with our V2Ray / VMess / VLESS setup guide.
What is sing-box, and what is Xray?
- V2Ray (Project V) - the original multi-protocol proxy platform. It introduced VMess and later VLESS, with transports like TCP, WebSocket, HTTP/2, gRPC and QUIC. It is still the main reference, but its original core does not have REALITY.
- Xray - a fork of V2Ray that added XTLS Vision and REALITY. It is the core that gets worked on most for getting past censorship. Most "V2Ray" anti-GFW setups in 2026 in fact run Xray under the hood. (We cover a full setup in our V2Ray / VMess & VLESS guide.)
- sing-box - commonly written singbox in forums and search boxes, while the project itself spells it with the hyphen; the binary, the package and the config key are all
sing-box. It is a newer all-in-one platform (Go, single binary). It runs many protocols as both client and server: Shadowsocks, VMess, VLESS, Trojan, Hysteria/Hysteria2, TUIC, WireGuard, ShadowTLS and more. It adds TLS/REALITY and several transports. Apps exist for Android (SFA), iOS (SFI) and macOS (SFM).

Your VPN hides your IP. It does not hide your browser.
A correctly configured WireGuard tunnel replaces the address a site sees. It changes nothing about what your browser announces on its own: fonts, screen, time zone, graphics stack. That combination is often unique enough to follow you across sessions, tunnel or no tunnel.
Measure your own browser fingerprint, passive, no questions, no account, no email. It tells you how many browsers out of N look like yours, and which attribute makes you stand out.
Side-by-side comparison
| Criterion | Xray (V2Ray fork) | sing-box |
|---|---|---|
| Core focus | VLESS/VMess/Trojan + XTLS Vision + REALITY | Universal: many protocols, one binary |
| REALITY (anti-DPI) | Yes (introduced REALITY) | Yes |
| Modern QUIC protocols (Hysteria2, TUIC) | Not native | Yes, built in |
| WireGuard support | No (separate) | Yes (built in) |
| Client + server in one tool | Core is server-side focused; many separate clients | Yes, same binary both roles |
| Official mobile apps | Via third-party clients (v2rayNG, Shadowrocket…) | SFA (Android), SFI (iOS), SFM (macOS) |
| Tutorials / community size (VLESS+REALITY) | Largest | Growing fast |
| Config | JSON | JSON (unified) |
Which should you choose, sing-box or Xray?
- Choose Xray if your single goal is a tough VLESS + REALITY setup against heavy DPI (China's GFW, Iran, Russia) and you want the most-documented path. It does that one job very well.
- Choose sing-box if you want to bring it all into one tool: one binary for the server and all your devices, the freedom to test Hysteria2/TUIC (UDP/QUIC protocols that can run better on lossy or throttled networks), and built-in WireGuard. It is the better "Swiss-army" base if you expect to switch protocols.
- Not sure? Both run on a small VPS and both support REALITY, so neither is a wrong answer. Start with the one that matches the guide you'll actually follow. For VLESS + REALITY that's often Xray. For a multi-protocol lab that's sing-box.
Protocols and transports at a glance
The two cores overlap on the classic proxy protocols but diverge on newer ones. This is the clearest factual difference between them.
- Shared ground: both speak VLESS, VMess, Trojan and Shadowsocks, and both support REALITY and TLS. Both also offer common transports such as TCP, WebSocket, HTTP/2 and gRPC. So for a VLESS + REALITY tunnel, either core covers you.
- Xray's focus: the Xray core is built around the VLESS + XTLS Vision + REALITY stack. XTLS Vision is Xray's own flow-control design that reduces the "TLS-in-TLS" overhead of tunnelling TLS traffic inside a TLS proxy. This is the setup Xray is best known and most documented for.
- sing-box's extra protocols: sing-box adds newer QUIC/UDP-based protocols in the same binary, notably Hysteria/Hysteria2 and TUIC, plus WireGuard as a built-in inbound/outbound and ShadowTLS. That breadth is the main reason to reach for sing-box rather than Xray.
Which one resists deep packet inspection better?
Both projects treat REALITY as their front line against deep packet inspection. REALITY works by borrowing the real TLS handshake of a legitimate third-party site (a "steal-oneself's-handshake" design), so that to an observer the connection looks like ordinary HTTPS to that site rather than a proxy. Crucially, it is designed to survive active probing, where a censor connects to your server to see whether it behaves like a proxy: because REALITY forwards unexpected probes toward the genuine target site, a probe sees a normal TLS response instead of a tell-tale proxy.
Xray is the project where REALITY was introduced and where XTLS Vision reduces the double-encryption fingerprint of a TLS tunnel. sing-box implements REALITY too, and layers it on top of its wider protocol set, so you can pair REALITY with, say, a QUIC-based protocol on a separate endpoint. Neither approach is a guaranteed bypass: censorship systems change, and the honest position is that anti-DPI is an ongoing cat-and-mouse rather than a solved problem.
Design and governance
The projects come from different lineages, and that shapes how each is built.
- sing-box (SagerNet) is a single multi-purpose binary: the same executable is client and server, with routing rules, DNS handling and multiple inbounds/outbounds configured in one unified JSON file. It is the newer of the two and aims to be a universal platform rather than one protocol's reference.
- Xray (Project XTLS) is a community fork of V2Ray (Project V). It stays close to the proxy-core role: it is primarily the engine, with the client experience usually provided by separate third-party apps. Its identity is tied to XTLS Vision and REALITY, the anti-detection features it pioneered.
So the split is not only feature-by-feature. It is one all-in-one toolkit versus a focused proxy core with a large surrounding client ecosystem.
The licences are not the same, and comparisons keep leaving this out
Both projects are open source, and most side-by-side write-ups stop at that word. They are not under the same terms, and it is the kind of difference that matters if you ship something built on one of them.
Xray-core is Mozilla Public License 2.0. GitHub's API normalises it as MPL-2.0. It is a file-level copyleft: modify an MPL file and that file stays MPL, but you may combine it with code under other licences.
sing-box is GPL version 3 or later, plus a clause of its own. Its LICENSE file carries the standard GPLv3-or-later grant, then adds:
In addition, no derivative work may use the name or imply association with this application without prior consent.
That added sentence is why GitHub does not normalise it: the API reports Other / NOASSERTION rather than GPL-3.0, because the text is no longer the unmodified licence. (Both values read from the GitHub API on 20 August 2026, alongside 41,119 stars for Xray-core and 37,139 for sing-box.)
If you self-host for your own use, none of this reaches you, running software is not redistributing it. If you are building a product, a service or an appliance on one of these cores, "GPLv3-or-later with a naming restriction" and "MPL-2.0" are very different starting points, and that is a question for whoever handles your licensing rather than something to settle from a comparison article.
Which clients work with sing-box and Xray?
For everyday use, how you connect matters as much as the server core.
- Client apps: sing-box ships official companion apps - SFA (Android), SFI (iOS) and SFM (macOS) - that run the same core on the device. Xray does not ship its own consumer apps; instead it is embedded in popular third-party clients such as v2rayNG on Android and Shadowrocket on iOS, which many people already use.
- Configuration: both cores are configured with JSON. sing-box uses one unified schema covering inbounds, outbounds, DNS and routing rules in a single file, which suits an all-in-one setup. Xray's JSON is centred on the proxy inbound/outbound with its own routing block. Neither is trivial, and both schemas change between releases - the config, not the install, is where most setups go wrong.
"sing-box or v2rayN?" is the wrong comparison
This question comes up constantly, and it mixes two different kinds of software.
sing-box is a core. It speaks the protocols, terminates the tunnel and routes traffic. v2rayN is a client - a Windows desktop front-end that manages your profiles, imports subscription links and starts and stops the connection. It does not implement the protocols itself: it drives a core underneath. Depending on the build you install, that core is V2Ray, Xray or sing-box.
So the two are not alternatives. The honest way to phrase the decision is in two parts:
- Which core do you want handling the protocol and the DPI resistance - sing-box or Xray? That is the comparison this page makes above.
- Which client do you want driving it on your machine? On Windows, v2rayN is the common answer whichever core you pick. On Android the equivalent is v2rayNG, and sing-box also ships its own official apps (SFA, SFI, SFM).
If you already run v2rayN and are wondering whether to "switch to sing-box", what you are really considering is changing the core it launches - not replacing the application. Check which cores your v2rayN build supports before assuming either way, since that varies by release.
How do you migrate from Xray to sing-box?
A question that comes up once people have chosen: can you just convert the config file? Not by hand-editing it, no. A migration from V2Ray to sing-box re-creates the configuration rather than translating it, the two cores describe the same connection with different key names, so there is no find-and-replace that gets you there.
The shape of the difference, taking a VMess outbound as the example:
| What it is | Xray / V2Ray | sing-box |
|---|---|---|
| Protocol selector | protocol | type |
| Server host | address | server |
| Server port | port | server_port |
| User identifier | id | uuid |
| TLS and transport | inside streamSettings | separate tls and transport blocks |
Two practical notes on top of the renaming. Xray's current documentation shows the VMess outbound with address, port and id directly under settings, rather than the older vnext array many published examples still use, so even configs within the same lineage do not all look alike. And sing-box splits into tls and transport what Xray keeps together under streamSettings, which is where a mechanical field-by-field copy usually goes wrong.
The reliable route is therefore to write the sing-box outbound from the server parameters you already know (host, port, UUID, transport, TLS settings) rather than from the old file, then validate it before running anything: sing-box check -c config.json reports schema errors, and sing-box format -w -c config.json rewrites the file in canonical form. As the caveat below says, check field names against the current docs for the version you actually installed, because these schemas do change between releases.
If you use v2rayN on Windows, the migration is a different job. You are not rewriting a server config there, you are swapping which core the client drives, since v2rayN can run either the Xray core or the sing-box core underneath the same interface. That changes which options the GUI exposes and, more importantly, which component resolves DNS. We cover that switch and its one recurring trap in v2rayN with the sing-box core.
What server do you need to run either of them?
Whichever core you pick, the tunnel breaks the same way when the MTU is wrong: small requests succeed, large transfers stall, and the connection drops under load. That profile is routinely blamed on the provider. mtu-probe measures the largest packet your path actually carries, so you can set the interface MTU from a measurement rather than from a default, subtract 60 bytes for WireGuard over IPv4, 80 over IPv6.
Whichever core you pick, you self-host it on your own VPS. That's what keeps the setup private and under your control. A small instance is plenty for personal use; if you are still choosing a provider, see how Contabo, Hetzner and OVH compare for a self-hosted VPN.
One handy option is a Contabo VPS (Ubuntu 24.04). Pick a datacenter near your target region for lower latency. See Contabo VPS pricing →
What should make you hesitate?
Getting past censorship can break local law in some countries. This article explains the tech; it is not legal advice. Also, proxy-core config schemas change between releases. Treat any config snippet you find (even in guides) as a starting point. Check it against the current official docs for sing-box or Xray before you rely on it.
Related guides
- v2rayN explained: the Windows client for VLESS and VMess
- Hysteria2 masquerade: hiding the tunnel behind a plausible site
- V2Ray setup: VMess & VLESS for China, Iran, Russia
- Shadowsocks vs VPN: technical comparison
- Cloak: TLS obfuscation for self-hosted VPN
- Anti-DPI: bypassing deep packet inspection
- Russia's VPN crackdown in 2026: what's blocked and what still works
- v2rayN with the sing-box core: what changes, and the DNS trap
Both cores still need a server to run on. If that part is not settled yet, our cheapest-VPS comparison for WireGuard lists what each provider charges for the specs these setups actually need.
★ Nuremberg GDPR datacenter · ✓ Dedicated IPv4 included · 200+ Mbps guaranteed
A VPS you fully control for tunneling & obfuscation → ContaboRoot access · open any port · run your own stack→


